It is my understanding that this proposal has been injected in Operation oo1SPm..TB7b on tzkt.io. This proposal was injected by baker TezosRus and written by an anonymous protocol developer, based on ideas I have presented.
As I’ve stated before, I think it’s important that bakers have the final say in what features they want to uptake this proposal period. I would like to see an additional asset presented for liquidity baking consideration as well (and have outlined that here). I am open to helping interested developers put forth a proposal.
On a personal level I’m proud of the community for rallying to give ourselves choice and I now think it is up the bakers of Tezos to decide the upgrade path. Competing ideologies and options truly produce a digital commonwealth.
Importantly, as an individual, I have advocated for options around liquidity baking. I will remain neutral on whether I think this proposal, the previously injected Granada, or protocols injected in the future are a good option for the foreseeable future as I am advocating for process, not politics.
I’m going to attach a brief description of how I see the proposal here, as I do not know, but do not suspect we will hear from the protocol author again. I know others will have opinions too - please feel free to respectfully weight in.
Fundamentally, this proposal represents and upgrade path to Granada for users who wish to uptake common sense improvements (Emmy* and gas improvements) while removing the liquidity baking functionality. Essentially, non-controversial and controversial features are decoupled and able to be accepted a la carte.
To accomplish this, the protocol code makes a simple change to a global constant. Liquidity Baking has a built in block height where it will turn off defined as a constant. This proposal removes liquidity baking by setting this height to 0, meaning that liquidity baking will technically be in the protocol, but off by default. While not the most elegant, the author of this protocol seemed to value simplicity, safety and review-ability. The author helpfully included options to spin up a sandbox to prove the protocol worked.
There have been many discussions on liquidity baking (mostly here). Some concerns that have been raised:
- Concerns TzBTC was an asset selected for liquidity baking, while other assets were not considered, and that TzBTC will now have a privileged position in the Tezos protocol.
- Concerns that there are no “official” alternative proposals, suggesting that Bakers are simply a rubber stamp for core developers
- Economic concerns over the implementation of the feature
- Concerns over Tezos Foundation’s relationship with Bitcoin Suisse and Taurus, part of the consortium that issues TzBTC
- Concerns that acceptance of Liquidity Baking was tied to several other features that users wanted, forcing them to choose between no upgrade and adopting a controversial feature.
I agree with some of these concerns and disagree with others. I am sure I am also poorly summarizing some of the multitude of opinions presented, and invite discussion.
A vote for this proposal does not necessarily mean that a baker does not support Liquidity Baking. It could also represent an objection to the processes used for asset selection or protocol formation. It could also represent a vote to slow the pace of Liquidity Baking and re-examine asset selection, economics and to re-propose this feature in protocol H. It will fall to bakers to liaise with their delegates about the best path forward, and for delegates to align themselves with bakers who represent their views.
Most importantly, this proposal elevates bakers from rubber stamps to being having options for new protocols and makes them the true stewards of the network, rather than relying on decisions from core developer teams or RFCs with poor participation . In that role, Bakers will have to weight the tradeoffs, precedents set, and risks they are willing to accept for the benefit of the network.
 I think there is both a visibility problem and participation problem we need to discuss here as a community, but at current time it is obvious that there was a fair amount of the community who did not participate in the RFC/TZIP process and who have feelings.
(Edit 1: Fix missing link, baker name and grammar)
(Edit 2: Clarify Bitcoin Suisse is part of a consortium)