Proposal plans

At the time of writing, the current voting phase for the Ithaca amendment should end very soon. As there is a possibility that the amendment will not pass the current Exploration period, the next voting period may be a Proposal period.

We would like to take this opportunity to present a revised version of Ithaca that addresses technical matters around the performance of metadata RPCs and which fixes potentially buggy error messages in those RPCs.

This proposal will be made available very shortly, and we invite people who would like to inject variants of Ithaca to rebase their patch on this updated version.

We heard interesting proposals to improve the liquidity baking escape hatch mechanism, and we are keen to explore them for a future proposal, but these take time and consideration to implement safely.

As the Exploration period comes near its end, we thank the many bakers voicing support for this proposal.


I endorse this proposal, and my post is not about competing with it.


The escape mechanism should take into account the quorum, that’s like 50% of voters. If you require 33% of votes for an escape hatch, then that should be 15% of all bakers in reality.


So long as it provides a better measure of what bakers want, as opposed to complicating things further. Would it be possible to allow bakers signal in support of LB thus negating an equivalent amount of the escape hatch vote?

I thought that was already a thing @JarrodWoodard? Is it not?

Thank you for injecting the improvements!

Would you be open to sharing ideas about other signaling methods besides the escape hatch that you have explored? Also what kind of timelines we would be looking at to implement those methods(approximately of course). I understand reinventing the escape hatch is not simple, but communicating ideas would help people understand your end game and possibly spawn new ideas.

33% does seem rather high. How many hours of work does it take to inject various proposals at 25% and 22.5%? Then let people vote on which one they want?

I don’t agree that we need to reduce the escape hatch. As a means for bakers to cancel LB, 33 percent is not reasonable

But as a contingency/emergency escape hatch (which was how it was originally conceived), 33 percent is reasonable.

We already have 16 percent voting against LB. Just adding DLS and other big baker like everstake and we are almost at 33%. I am confident these 2 entities will vote to cancel LB if there are critical bugs.


Thank you @NomadicLabs. We will follow this directive accordingly. Our upcoming proposal injection (Ipanema Amendment) will reflect this updated version of Ithaca.


@NomadicLabs Why is it so difficult to offer several proposals? Clearly the contentious issue with Ithaca is LB. If you want Tenderbake, then provide a second option that disables LB and use the “escape hatch” in inverse (bakers signal they want to resume LB).

You guys have so much power yet offer so little choice. If you’re supposed to be impartial, then give us impartial choices.

1 Like

Thanks to the feedback we got in the Ithaca debate we see a drawback in the escape hatch mechanism as a tool for signaling a will to continue or stop the subsidy: it does not distinguish the bakers promoting liquidity baking from the ones relying on the default behavior. This comes mainly from the lack of symmetry between the options and the lack of a “pass” option.

Here is a summary of the changes I am implementing:

  • Rename the two available options to “on” and “off” to avoid confusion.
  • Add a third “pass” option. Pass votes are ignored in the computation of the exponential moving average.
  • Make this LB vote mandatory; that’s in fact not a protocol change. It is a change in the baker daemon that makes it refuse to start if no vote option is provided
  • Make the whole mechanism symmetric by resetting the escape threshold to 50% and making subsidy deactivation non-permanent.

For more details, see the following draft MR: Draft: Add a pass option to LB escape vote (!4201) · Merge requests · Tezos / tezos · GitLab

Also what kind of timelines we would be looking at to implement those methods(approximately of course).

It is probably a matter of weeks.

I understand reinventing the escape hatch is not simple, but communicating ideas would help people understand your end game and possibly spawn new ideas.

Thank you for opening this communication channel! I am very happy to get feedback on this. I shall soon write a TZIP draft to have this discussed a bit more formally.


This would solve many controversies around LB escape hatch mechanics.

My opinion:

  1. Escape hatch should remain for emergency.
  2. LB or No-LB should be put in conventional governance process, because its not emergency.

I was about to say what posdog just said
We asked NL to submit a no-LB proposal which is a minor change but not to spend your precious time to rework the hatch if it’s enough for ‘on’ to be activated by the supermajority during voting
unless you see other benefits ofc (more bakers involvement?)

1 Like

Sure an escape hatch should remain for emergencies, but that doesn’t mean you can’t also govern the feature using a similar signaling mechanism. The lack of reliance on such mechanisms is a common and valid criticism of Tezos’ governance system. I’ve talked repeatedly over the years of the importance of using fast signaling mechanisms to set economic parameters within safe range in the protocol, I invite you to hear those arguments.

When the escape hatch was implemented, it was built generically, on purpose, so that more signaling mechanisms could be grafted onto it to cover many more scenarios, such as gas instruction pricing for instance, cache size, etc. I have issues with the way this is implemented in Ethereum (yes, Ethereum has signaling-based governance of protocol constants) but this is primarily a matter of using better metrics, not an issue with the approach per se.

The original Tezos papers detail how the initial governance process is a kernel meant to give rise to a rich governance process. One of the main weakness of the current process is that it couples many things. It might seem, to you that making several proposals is enough, but this is because you only see two relevant options are LB or no LB. That is, however, not the case. There are dozens of economic changes and ideas embedded in Tenderbake for instance. A dozen different choices doesn’t mean a dozen different proposals, it means 2^12 = 4096 potential different proposals. To avoid the combinatorial explosion, we need concurrent, independent, processes.

It’s very hard to have concurrent governance processes for features in the protocol because code patches generally do not commute, but it is possible to have concurrent governance process for constants. This decoupling should be used whenever possible, and signaling mechanisms are probably the best way to achieve it.


Let’s just get rid of Liquidity Baking. This feature is a failure, from design to implementation.

Tezos holders are paying everyday for this mistake, because of inflation. This is one of the reason Tezos is doing poorly compared to other crypto.

Tezos would do much better without it.

1 Like

The amount of inflation from LB to date is a bit less than 0.15%. You are right that, all else equal, inflation reduces the purchasing power of a currency, but you seem to be missing that, all else equal, 0.15% inflation reduces the purchasing power by 0.15%.


When I put {“liquidity_baking_escape_vote”: false} in the voting file instead of “true” I got the message “Will vote to continue Liquidity Baking” upon running the baker. Not sure how it’s counted though.

Can anyone post the math that proves that the new escape hatch mechanism will also have the 80% super majority rule? To be trusted, it should have the same 80% super majority rule. That’s what we all sign up for, and it needs to be 80% specially for economics decisions…

No, you signed up for a network where protocol upgrades are decided by the governance rules of the current protocol.

For a self-proclaimed objectivist you seem to be a big fan of using the word “we” to speak for other people. So, in Ayn Rand’s words:

“It is the word by which the depraved steal the virtue of the good, by which the weak steal the might of the strong, by which the fools steal the wisdom of the sages.”

Indeed your depravity is patent to anyone who’s observed your behavior and character over these past weeks. Try intellectual honesty for a change, you might like it.


Sir Don’t Ayn Rand google quotes on me

Since now pass vote will exist with the escape hatch and pass votes won’t even be counted, there is no excuse to not set up the threshold like we have it now with the on-chain governance at 20% to veto stuff or even for an emergency. 50% is just crazy.

Fact 1, the quorum will be guaranteed 100%, because it is forced to vote in order to run baker, perfect good change.

Fact 2, pass votes won’t be counted for the nay/yay threshold, which is perfect too, like with the original 80% voting rule.

Fact 3, dispute vote between nay and yay voters have a threshold of 50%, that’s the problem.

Another rigged voting system that won’t respect the 80% supermajority rule…