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.