With Seoul in the pipeline, to be deployed to prod in just a few days and the T protocol on the horizon, I was hoping this would be a good time to discuss the protocol changes that are coming up in T.
What caught my eye ( T Protocol Proposal is feature-complete · Milestones · Tezos / tezos · GitLab ) is a mention that the T protocol would lower the length of a cycle to 4 hours. I’m really curious to find out why the cycle is being lowered from 24 hours all the day down to 4. This does to go against our general practice of lowering these types parameters slowly over time. To be clear, I’m not against this change. For me it’s more of a matter of useful considerations to be aware of.
As a baker, 4 hour cycles will most likely move me toward paying delegators every X number of cycles instead of every cycle. That’s not going to be a problem in itself. The main issue here will be that people will no longer be able to easily reference their individual rewards on TzKT or using the Telegram bot because rewards be aggregated and that will cause confusion amongst delegators.
I’m sure there are great reasons to lower the cycle duration fast but this does have an effect on the bakers, users and probably on infra tooling providers.
I know this is probably too much to ask, but in general knowing what changes are coming before they’re actively being built would greatly help the stakeholders on Tezos have greater operational awareness and understanding of the strategy undertaken to materialize TezosX. It will also give the casual observers a window into the dev direction and show material artifacts that the vision is being worked on with feedback from the community at large or at least with bakers and tooling providers.
In general, the optics of someone looking up Gitlab, seeing a feature or change they don’t like or have concern with and posting about it here, as the first mention of said feature or change, are bad for the independent observer. It’s much better if the thread already exists here, that they can reply to.
What gets posted here for future protocols doesn’t have to be binding or extensive. Anything over what we have today helps toward strengthening the social cohesion aspect of decentralized tech, even if it’s just a few sentences about changes, steps and vision.
I agree with the concern raised here. The move to one-day cycles in Rio was a real improvement because it gave us both shorter waiting times and a clear, simple standard:
1 cycle = 1 day
That framing has been easy to work with for bakers, stakers, everyone.
The idea of making cycles any shorter at all (even to say 23 hours) misses the point. Cycles are not just a performance dial, they are a social clock. Once set to a clean 24-hour rhythm, they became a strong common unit of coordination across the ecosystem. That’s why we set it to 24 hours. Shaving that down further does not improve anyone’s experience, it only undermines the clarity we just gained. If other protocol processes need to run faster, their unit of measure should be handled with subdivisions of cycles, but the cycle itself should remain fixed at one day.
Thinking about why this suggestion surfaced, I suspect it reflects an engineering instinct that smaller numbers (or less time) is always better. That makes sense for most things, like reducing block times and latency, but not for units that serve as standardized measures. In this case, a round, predictable measure (1 day = 1 cycle) is the point of value here.
Looking ahead, I would suggest that proposals of this kind be opened as discussions before development work (or even studying its feasibility) is invested. That way, important core development time is not wasted on changes the community may ultimately reject.
I’m glad to hear that the details of T will be discussed soon on Agora; that’s a welcome step toward clarity. At the same time, I’d suggest we start opening conversations about U and beyond now, before those proposals are feature-complete.
Having early visibility into the roadmap doesn’t mean every idea is binding; even a lightweight outline of the intended direction would help bakers, tooling providers, and the broader community prepare. It also gives stakeholders a chance to highlight potential issues before engineering effort is committed, which strengthens the social and technical cohesion of the ecosystem.
Other open-source projects have benefitted from this style of forward-looking discussion. For example:
Ethereum: EIPs are often discussed in public forums well before they reach final draft. Even if not all proposals are adopted, the early conversation sets expectations and builds alignment.
Rust: Their RFC process explicitly invites community review and feedback at a conceptual stage, long before code lands in main.
Python: PEPs often spend months or years in the discussion phase, giving users and library maintainers time to prepare for changes.
Tezos could take inspiration from these processes without adding heavy bureaucracy. A few sentences about candidate features for U, V, and beyond, even with plenty of caveats, would give bakers and users a shared horizon to discuss. That kind of transparency not only improves operations but also makes the project feel more accessible to those who don’t follow GitLab daily.
Of course, I want to acknowledge that this kind of process is asking for extra work from the core devs, who already carry a heavy load. Opening up discussions earlier, fielding questions, and responding to concerns takes time away from the very hard engineering work they’re doing. For that reason, I share this suggestion with respect and gratitude. Hopefully, over time, this approach will actually make their jobs easier by reducing surprises later in the cycle and by giving them the certainty that the community is not only aware of the direction but also solidly behind them.
Looking forward to the upcoming T discussion, and hopefully seeing seeds of U and beyond planted here soon.
Full agreement that the development process and Gitlab are too opaque and this absolutely reflects on what brand of “open source” model your walking into. The governance processes and marketing is a very nice facade but the second one digs in to try and do anything it becomes extremely clear that Tezos is a source available project not an open source project.
Anyone can see the code and do whatever they want with it just don’t touch. You don’t have the context to be making changes that will be accepted. Well can we have some of that context? No, those all happen in private discussions, private Linear and Google design docs, and I hope private documentation because I wouldn’t wish the public documentation on anyone.
Absolutely necessary if there is ever to be a chance of anyone building here voluntarily. If anyone is budgeting a serious project, multiply your cost estimates by 10x vs any other chain because there’s simply no reliable references to use. Open Tezos feels like it’s been filtered though a focus group to be as useless as possible sometimes.
Institutional knowledge is called institutional knowledge for a reason, and it is centralized to a degree that I have never seen elsewhere outside of someones over engineered pet projects. You know the response you’ll get is “it works on our machines” because anyone who might try in earnest is going to stop when the official packaging 404’s and the scripts all fail because nothing’s portable.
Cut marketing trying to bring builders here to zero until any of this is sorted out. It is doing more harm than good because it’s brutally obvious no one cares. The perception that is being projected doesn’t survive first contact with the reality.
I think you’re being too diplomatic for how serious this problem is but I understand the need to with how defensive and protectionist everyone here can get but… that’s the cultural issue that needs confronting.
I’m saying this from the outside: whatever family intervention needs to happen to get this specifically moving in the right direction, needs to happen.
