Thank you for the spirited discussion - both from the protocol devs and from the community. There’s a lot to parse through here. I am currently traveling so I will not have time to respond to each person individually.
There’s a lot of interesting ideas about the merits of Liquidity Baking - I do believe the time for that discussion was on the Agora thread / RFCs. As a community, we need to do better at making folks aware of this mechanism. I think this is an action item for everyone participating in this discussion.
That said, at current time I am not going to weigh in on the merits or Liquidity Baking.
I do continue to be concerned that we are picking winners and losers at the protocol level, and that these decisions are made opaquely. I have not yet heard rationale or a compelling argument for why this is.
I particularly align with this sentiment from @jzay:
“Liquidity Baking seems like a fantastic idea but the way it’s proposed to be implemented sounds like a top down business decision from someone high up at the Tezos foundation.”
Along those lines, I also would like to amplify @jdsika’s message:
It has also not been made clear if there are any conflicts of interests.
Does anyone associated with TF e.g. own a stake in one of the companies? Are there any other business relationships?
Surely, if we are deciding to bake a company / consortium / entity into the protocol this is a fair question to ask.
I continue to think that coupling a controversial proposal (and at current time, this looks controversial) to common sense improvements creates bad incentives and produces a poison pill that cedes complete power to core development teams.
I believe that this proposal consolidates power into the hands of a few and sets a precedent that the Tezos community will accept that. Injecting the liquidity baking options presented above is a great way to avoid that precedent. It’s also easy (IIUC - I’m not a core dev) as simple as originating the CFMM contract, changing a constant in the code, recompiling and injecting the protocol.
If one wanted to present Granada without liquidity baking, an ugly kludge would be to originate a CFMM for an asset which has a supply of zero or one token., such that liquidity was never able to be provided. This presents a viable path for the community to accept Liquidity Baking, and core developers to not be required to re-write code. In time, the community can reach consensus about Liquidity Baking and the assets they want to support, and enable those assets.
There are collectively many engineers working on protocols at Tezos, both employed as core developers and ad -hoc. I believe there are posters on this thread who are capable enough to do this. I do not think this is a heavy lift. Core developers can weigh in and correct me if I’m wrong.
Lastly, I’m going to respond to a few points (quoted for brevity) from @murbard who is the user who has most directly responded to my concerns.
tzBTC is not issued by Bitcoin Suisse, they’re one of the members of a consortium of custodians who hold BTC against it.
What you’re calling an exchange is also not an exchange but a smart contract that allows swapping, and it is only loosely based on the code of the smart contract used in Dexter.
I admit I misspoke and that it is in fact a consortium.
It is important to not get lost in the weeds and to nit pick. My concern is that we are choosing a “thing” made by an “entity” to have higher privileges than other “things” or “entities”, and the way this decision is made / presented to the community without alternatives.
We are making this consortium have more privileges than other companies, consortiums or entities, regardless of what class of entity Bitcoin Suisse is. Likewise, we are choosing a smart contract to have more privileges than other AMMs / CFMMs or Smart Contracts, regardless of what we specifically refer to this contract as. Debating over names and roles doesn’t change this fact.
There’s a natural reason to pick tzBTC over wBTC, it’s been around for much longer. TzBTC is not a bitcoin Suisse product and bitcoin Suisse, or the association is in no-way “winning” anything for this.
and
Regarding the other assets, tzBTC carries the benefit of being far more neutral, in terms of benefitting a specific party or project which seems to be a concern of yours. It’s also been around for a long time and its participants involve an actual bank. It’s the conservative choice.
If the reason is natural, it surely would not hurt to originate the exchange contract for wWBTC, change a constant in the protocol, recompile and re-inject. If it is truly obvious then it will naturally win.
The other conclusion here is that the core developers injecting the protocol don’t think that the bakers on the network are capable of choosing correctly so it is better to present no options than to let them choose the wrong one. If we truly can’t rely on a baker community we have far bigger problems.
This [The asset powered by liquidity baking] can literally be updated just 10 weeks after if and when better suited assets are available.
I agree in spirit and I think this is a useful point.
My concern is about who will choose this asset? Will it also come from the core developers? Will age also be the primary criteria? Will several assets be presented or will it be like this proposal, where only one is chosen? Will this change also be coupled to coupled to non-controversial features like gas-reductions and faster blocks?
A few last practical questions, that are orthogonal to my concerns above, and the concerns about the merits of liquidity baking:
- The new contracts for a CFMM exist, but is there a UI or product that uses them? If so, who is going to create and maintain that UI? If not, does that mean that only users that are comfortable on the CLI can benefit from this proposal
- I haven’t seen a public disclosure of a security audit or formal verification of the new CFMM contracts. Are there any artifacts here which we can share with the community before we bake this contract into the protocol?
