Just to answer @murbard in good faith:
Clearly you do not.
I am not arguing against liquidity baking. I am arguing against the parameters chosen. I work on smart contracts on Tezos that need liquidity. It’s a neat concept and a great experiment. I commend the team on their work, and I think the feature is well thought out (from escape hatches to economics). I am, personally, thrilled to see the care and thought that went into this feature.It may seem trivial, but the engineering work from the protocol to the smart contracts is well done and thought out.
I take issue with the fact that (1) the asset is chosen in a top down way and (2) a controversial feature is tightly coupled to improvements that will obviously pass with an overwhelming majority (everyone wants fasters blocks and cheaper gas). This is the core concern I have. I’m simply surprised to see it coupled tightly in a way that we have to uptake it, and I’m worried about the precedent being set that a slate of assets aren’t being presented.
I don’t think the folks who are debating economics and implementation details of liquidity baking are in the right here. The specs for liquidity baking were finalized prior to this. However, the actual asset (just like the experiment length, amount of votes needed to shut it down etc) are simple constants in code and readily interchangeable. I’m surprised (and now somewhat concerned based on the pushback) that we don’t think options here are useful. Especially since it seems like the current governance period is explicitly build for this sort of debate.
Happy to answer your questions:
- If you care so much about alternative proposals and think they add value, why don’t you inject them? Why does someone else have to do it for you?
I think it’s poor form (and would be rather disrespectful to the hard work of the core protocol devs) to inject things without forming a broad consensus (even though we are in a permissionless space). In software, often agreeing on the path forward takes longer than actually writing the code to get there, and that’s why we’re here having this discussion. If we can agree on the path forward, I’m happy to write the code (and I did state in the original post that I was happy to lend a hand to make this happen).
I do think that it’s important that this injection comes from (or at least with the blessing of) the same team(s) who injected the original proposal, since the point I’m making is that the core dev team shouldn’t be in charge of choosing winners and losers. I feel relying on the community to offer counter proposals to a controversial proposal with no alternatives states that team’s position that they should be in charge of choosing. That’s not a great look, IMO.
With that point articulated, I have looked into how we could provide bakers with alternative assets or a non-liquidity baking upgrade. I have identified the following:
To change the asset that is subject to LB, we simply need to update the token contract here :
To remove Liquidity Baking (uncleanly, but successfully) we could just set sunset level to 0. This effectively means liquidity baking exists, but is never turned on. We’d update that constant here:
Both of these changes are non-invasive and one line changes.
I still have some outstanding questions (feel free to chime in!):
- I’m not sure the exact steps to compile from protocol alpha to proto_010
- I’m not sure if the asset can be an FA2 token, or if we’re limited to FA1.2 only
I’d welcome help from folks closer to core dev in answering these questions or if there are cleaner / easier ways. Both of these could be used to offer a la carte proposal offerings to bakers and let them decide the outcome.
Lastly, I just want to state loudly: It strikes me as worrying that the powers that be don’t trust the bakers (who are the ones securing the whole multi billion dollar network) to make this decision correctly. If we truly cannot trust that bakers are able to correctly choose from a slate of options, we have bigger problems the second a malicious actor gets enough rolls.
- You refuse to engage on the object level, but pragmatism matters. What do you personally think of the proposals you outlined, on a scale of one to ten. I get that you’re trying to make a meta point, but I think the object level is relevant in shedding some light into what is actually at stake.
The question I am trying to answer is solely: “Do / should the core Tezos developers get to pick winners and loser that receive first class support”.
I think the answer to this question, especially from the bakers, should be a resounding “No” because it sets a bad precedent and makes it okay to do this again in the future. Worse, accepting this with zero pushback makes it clear that there’s more room for more flexibility in the future and that future proposals can continue to push the boundaries. Where is the line?
My opinion is that Bakers should be presented with an option which doesn’t contain a tight coupling of controversial features [1] to common sense ones and that other assets should have the option to elect different assets, and that that power lies with the validators of the network alone. Giving people choice in a decentralized, permissionless network shouldn’t be controversial.
The specific question you are asking is orthogonal and isn’t relevant to the discussion. It feels as if you’d like me to critique assets and then the debate gets shifted away from “Do the core Tezos developers get to pick winners and loser that are baked into the protocol” to “What is the merit of asset X”. If TzBTC is clearly the best choice (which I take no opinion on) it should be easy to articulate that to bakers and the community. If we truly think a super majority of bakers may pass a proposal for a suboptimal asset, perhaps we should recalibrate what we’re optimizing for. I think there’s a zero chance that bakers pass $meme-coin for liquidity baking, and I think that bakers will make largely the right choice - they just need to be given the right choice.
After a protocol G is passed (or voted down), I am happy to offer you opinions on these assets, and how Tessellated Geometry would vote if my proposed slate of assets were presented. If there’s interest from more than a few folks, I can write up a response, and post the hash here and reveal after the dust has settled, as Arthur did with Babylon’s hard fork.
I’d also like to note that it seems that the narrative seems to be “go ahead and pass this, it’s an experiment, we can always change the asset and turn it off later”, and at the same time this question suggests there’s a lot at stake. I’m having trouble squaring those statements in my mind.
I also want to make it really clear that I have a tremendous amount of respect for Arthur, the Core Developers and the community. My opinions offered here are in good faith, and I just want to make it really clear that I do not have interest in delaying protocol G. The broad strokes of a useful protocol are here - we simply need to iron out the details. I’m actively presenting options to get us to a place where bakers can decide the flavor we are going to uptake.Unfortunately, it is my opinion that this proposal represents a poor precedent to set at current time but I would love to see us do some reasonable leg work here so I can support it.
Lastly, I want to re-iterate my questions above which I don’t think have been answered by the project docs, blog posts or this thread. I think these are basic pre-requisites to accepting this sort of a change, and they should be by and large be soft-ball questions to the Tezos Foundation and core devs. They represent easy wins to provide reassurance to folks who may uptake this proposal.
- Does anyone at Tezos Foundation or associated entities have an ownership stake or business relationship with a company in Bitcoin Suisse? Presumably the Tezos Foundation has a custody agreement and grants with the entity (CMIIW). Can we state, in good faith, that there are no conflicts of interest?
- Is there a UI for the new CFMM contract? Who will maintain it? Or is this feature only available to users who can work on a CLI?
- I understand that the fork of the Dexter contracts were audited and formally verified. The contracts being presented on chain are forks of those contracts. Are the contracts that are about to be presented on chain also security audited / verified?
[1] And at this point we have 83+ Agora Posts, reddit / twitter chatter, and alternative proposals being injected. LB is a controversial feature - regardless of how little or much the community made that known.
(Edit: Tag Arthur by username to avoid confusion / increase visibility)
