Heads Up: Enshrined Liquid Staking On Tezos

Research and Development
41

This is how it should be in the general pool, but you are trying to complicate something that does not need to be complicated. In reality, no baker will set parameters less than the maximum you specify in the protocol.

What will motivate a baker to set the fees parameter lower than the others?
Will he get a larger share from the liquid staking pool?

There should be no competition in liquid staking, as it should be considered a complement to conventional staking, which is competitive.

Сonventional staking should be considered by the bakers as a priority for attracting external stakers, liquid staking should simply fill the free capacity, but with a limitation, let’s say no more than 20% of the total capacity.

42

I understand where that approach is coming from. Currently several bakers offer low or no fees at all for delegation and/or stake to attract more delegators/stakers.

1 Like
43

But how will this work in a shared pool?
I believe that liquid staking shouldn’t be competitive, competition in conventional staking is sufficient.

In short, it’s pointless to suggest anything here, NL has already decided everything and started writing the code a month ago. We were simply notified about it.

This attitude suggests that there are problems with decentralization in the Tezos network. I suspect that a group of large bakers depends on TF money and they will vote as they are told.

It’s impossible to talk about decentralization if the development vector is determined by a handful of companies dependent on a single source of funding. The rest are simply forced to comply because they don’t understand the protocol code.

The choice of the Ocaml language for the protocol already suggests that decentralization was not given much thought, as the language’s popularity is extremely low.

44

I don’t know how it works or if it’s a good idea or not.

But I see these recent threads evolve into addressing how communication needs to change. And that is a good and long overdue thing! It does not help much to accuse the core-devs of ignorance. We need to find a common ground of understanding each other. I think this is the root of many issues we have.

What I see is a huge gap in communication which I don’t believe is intended. From my own experience I can say, communication with the engineers at NL and TT is on a completely different level — almost a different universe.. A while ago when I made some explanation videos about Tezos tech I found their communication really hard to understand and likewise had the impression they did not understand what i was saying. I think the cause lies within the assumptions on all sides what the other side should understand without explanation. It was like we were communication in completely different languages.

I think we need a translator who is close to the community and understands the complex ecosystem as well as the deep technical considerations of core development – someone who is able to bridge that communication gap between community and engineering.

45

On the timeline: once we enter the stabilization phase (which is keeping many of us busy right now), a whitepaper describing the model will be published.

A UX/design document explaining the mechanics of the system should also land during stabilization, together with a description of the parameter space.

It is not yet fully clear whether the dedicated testnet for this feature will be available immediately after the U proposal release, as we want to avoid overlapping with the purpose of Unet during the on-chain governance period.

Regarding the broader point about implementation appearing before design documentation:

While I understand the desire to share designs early for discussion, in practice, we often need to implement the critical pieces of a mechanism before we can present a coherent design externally. Some protocol ideas only become fully understandable once the mechanics exist in code and edge cases have been worked through. Implementing those primitives helps clarify accounting models, allocation behavior, and operational constraints (feasibility and risk).

That said, the presence of code does not mean the design is fixed. Code can still be modified, refactored, or even removed based on feedback during the stabilization and governance phases, before any activation decision. This is part of the cost we accept to make the mechanism concrete and testable early.

The staged rollout is meant to reflect that process. In proposal U, the mechanism is introduced behind a feature flag so that it can be exercised on a dedicated testnet and evaluated by the community. The goal during that phase is precisely to gather feedback, test allocation behavior, and refine parameters (for example by testing alternatives such as the one suggested by @KDprogs).

Activation with finalized parameters would only happen in a later proposal (V), once those aspects have been evaluated through experimentation and discussion.

If there are specific thoughts on the allocation mechanism, parameter bounds, or test scenarios, those can be explored during the experimentation phase, once further documentation is shared.

3 Likes
46

Presenting ideas before prototyping begins or specifics are finalized still provides value. A follow-up on the findings—providing evidence of non-feasibility or confirming that a proposal is forthcoming—would also be helpful.

2 Likes
47

Guys, you could share your idea of ​​creating liquid staking with the public from the very beginning, even before writing the code, listen to all the suggestions, and then proceed with the implementation, reporting what is feasible and what is not due to technical issues.

It can be difficult to abandon something that’s already been written. A defensive reaction to change anything will kick in, and you’ll begin trying to convince everyone that your original idea is perfect and doesn’t require any changes.

1 Like
48

It doesn’t have to be complicated. Something like this would go a long way:

“Hey, we want to implement liquid staking. We don’t know exactly how it’s going to work yet, but we should have more next month. We’ll post a summary of our progress every couple of weeks here so the community can weigh in on design decisions as they take shape.”

That’s it. That’s the whole ask. A few sentences, posted early, with a commitment to periodic updates. No whitepaper needed up front. No formal RFC process. Just visibility into what’s being considered and a channel for input before the code is merged. This back-and-forth interaction would help know what considerations to address in any kind of modeling and such.

Maybe one day we can even get to the point where bakers could suggest features or pick from a list of low-effort improvements that help the everyday Tezonian’s experience. That’s what real collaboration looks like. We’re not there yet, but this would be a meaningful step.

2 Likes
50

Hi everyone,

Thanks for the thoughtful discussion so far. It’s very useful to see these questions and perspectives raised.

The concerns mentioned here are all legitimate, and it’s precisely for that reason that the idea was proposed behind a feature flag. The intention is to make it possible to explore and evaluate such a mechanism in a controlled way, before the governance process decides whether it should ever be activated.

Many of the points raised in this thread (such as protocol neutrality, potential ecosystem effects, or staking dynamics…) are important considerations, and discussions like this help clarify them. This helps move the discussion forward.

Out of curiosity, would you be interested in exploring such a mechanism experimentally (under a feature flag) in order to better understand its implications in practice? Curious to hear what you think.

2 Likes
51

You still haven’t described in detail how it will work. I asked specific questions, but they weren’t answered.

52

It’s fine to test it out under a feature flag just like we can vote liquidity baking on/off/pass.

The most important thing is that the feature does not take away opportunities for developers in the ecosystem as that’s important for potential future users. The best way to implement this in my opinion is in a way that can work together with existing contracts so that it doesn’t compete, but complements.

1 Like
53

Hi StorryTV, and thanks for your message.

Here, “feature flag” means that the feature would only be activated on testnet, not on mainnet, if protocol upgrade proposal U is accepted. There would therefore be no “on/off/pass” vote switch to activate it on mainnet.

If the tests are satisfactory and depending on feedback, we are considering proposing its activation on mainnet with protocol upgrade proposal V.

54

Why are you ignoring my questions? You yourself don’t know how this will work?

How can you talk about testing if you still can’t describe how it will work, taking into account my questions

55

Hi KDProgs,
Sorry for the delay. Your question has not been ignored. I’m just looking into how to provide a more complete answer than what is currently available in the initial post and the replies in this thread.

56

The general ideas laid out for sTEZ are interesting. I might need to reread the post a couple of times to fully grasp all the points raised, though.

Here are some initial questions and thoughts on this:

1. Protocol-Level Fee Mechanism for Governance Testing

Introduce a global protocol constant (e.g., 1–10%) that directs a portion of all distributed sTEZ rewards to a baker-controlled treasury contract.

Could this distribution fee be implemented as a mandatory protocol constant or an optional Octez node feature flag?

2. Alternative Consensus Power for sTEZ Bakers

If customized baker parameters don’t grant consensus/voting power, could sTEZ bakers gain alternative governance mechanisms?

Could sTEZ bakers gain voting power over the treasury contract mentioned above, separate from protocol consensus?

Would it be feasible to create a parallel governance layer where sTEZ bakers have “economic governance weight” proportional to their sTEZ stake?

Could this create a testing ground where sTEZ bakers vote on experimental parameters before they’re considered for broader protocol adoption?

3. Liquidity Baking Integration with sTEZ

If sTEZ becomes a thing, could the protocol automatically convert a portion of Liquidity Baking tez into sTEZ-based pairs on both L1 and Etherlink?

Is it technically feasible to mint sTEZ directly from LB rewards via smart rollup tickets?
What percentage split would make sense?

I feel like these could help keep some projects, such as Stacy, TED/Tezos Domains DAO, and Youves, in a competitive protocol-based check.

57

The short answer is yes for our current design: allocation follows competitiveness.

Bakers declare parameters (including fees and capacity), and the protocol allocates liquid stake subject to those constraints. Lower fees make a baker more attractive, so—within capacity limits—they are expected to receive a larger share of the allocated liquid stake.

This creates a market dynamic similar to delegation today, but applied to liquid stake allocation:

  • lower fees → more attractive → more allocated stake

  • higher fees → less attractive → lower allocation

Importantly, this is bounded by protocol guardrails (e.g., caps, eligibility conditions), so competition improves efficiency without allowing excessive concentration or instability.

1 Like
58

(1) Protocol-level fee / treasury mechanism

Introducing a protocol-level fee redirected to a treasury would change the nature of the mechanism.

The current design keeps:

  • reward distribution proportional and directly tied to stake,

  • no additional protocol-controlled redistribution layer.

Adding such a mechanism would introduce governance over redistribution and move away from a neutral protocol primitive toward a policy-driven system.

This may be explored separately, but it is out of scope for the initial design.

2) Alternative governance for sTEZ bakers

The design intentionally avoids introducing:

  • additional voting rights,

  • or parallel governance layers tied specifically to sTEZ.

The guiding principle is:

liquid staking increases economically committed stake participating in consensus, without introducing new governance rights.

In practice:

  • sTEZ contributes to consensus through the underlying stake allocated to bakers,

  • but it does not create a separate source of voting power or governance influence beyond what that stake already represents.

Introducing governance rights tied specifically to sTEZ (or to sTEZ bakers) would:

  • duplicate or distort existing governance mechanisms,

  • and reintroduce risks of governance concentration through liquid staking.

So the current design keeps a strict separation:

  • economic participation in consensus → increased via sTEZ

  • governance rights → unchanged and governed by existing mechanisms

This separation is intentional for the initial design and helps keep the mechanism predictable and neutral. Whether additional coordination or governance surfaces around sTEZ make sense could be revisited in later iterations, once the core mechanism has been exercised and evaluated.

(3) Liquidity Baking integration

This sits at the intersection of protocol economics and application-level integration.

While some mechanisms (e.g., minting via tickets, rollup interactions) are technically feasible, embedding such integrations directly in the protocol would introduce tight coupling between otherwise independent components.

The current approach is therefore to:

  • define sTEZ as a protocol primitive,

  • and allow integrations (e.g., AMMs, rollups) to build on top of it.

1 Like
59

For those interested in going deeper:

These provide a more detailed view of the model and the expected user and baker flows.

Questions and feedback are welcome — we may not always respond immediately during stabilization, but they are taken into account as the design evolves.

1 Like