Until now the conversation about Liquidity Baking has been very polarizing — truly.
A. One polarity wanted Liquidity Baking gone altogether and criticized every aspect of it.
B. The other polarity defended every aspect of the LB status quo, including aspects for which in a non-polarized atmosphere they may have suggested improvements.
With the most recent Proposal period (that which elevated Psithaca2), these polarities were able to take their dispute to the pools in which a pseudo-referendum on liquidity baking took place, with (yes) Liquidity Baking ultimately prevailing. Hopefully, now that that referendum has been had, a new (more nuanced) conversation can take place regarding how to improve liquidity baking.
Furthermore, over the last 3 cycles, we have all tended to get in the heat of discussion about Liquidity Baking during the Proposal period itself. This is not optimal. During the Proposal period, the readied code proposal for the upgrade is injected and it’s really just a matter of voting, and there are only roughly 2 weeks to do it.
There is no time, realistically, during the Proposal period to deliberate and come up with new ideas to factor into a new-new-new proposal — to then code that proposal, test/debug, and inject it, let alone rally the votes to overtake what had already been accumulating votes since the Proposal period began.
Let’s use this time and this space to discuss Liquidity Baking with cool heads and with a common goal of doing what’s best for the Tezos ecosystem as a whole.
On our end, at StableTech, we now have full-time labor dedicated to core proposal amendments. So, now we can:
- Release core proposal amendments early instead of late in the Proposal period
- Customize the amendments a bit better (in the past it’s been more surgical, and we strictly followed this document alone)
However, we don’t it to be a walled garden. We want everyone’s voice involved in the process.
Areas of liquidity baking to address (to keep the same, or to propose changes):
- The subsidy rate
- The tokens pairings subsidized
- The number of pairings subsidized
- The nominal swap fee
- The escape hatch threshold
- The sunset period
Suggested framework for proposing a change:Having had this discussion many times, I believe a strong and inclusive rubric of what should be satiated by a change in Liquidity Baking. Ideally, it would optimize 3 areas. Feel free to use this or not use this. It's merely a suggestion that I think organizes things pretty well.
That is, in making a case for amending LB using any of those areas listed above, it would be helpful to use the following as context for what the proposed change would improve about LB.
(This list **does not mean** that these 3 factors are of equal importance, nor is this an order of importance. It's merely a way to provide structure to assessing the goals of liquidity baking)
Liquidity: How would the proposed change render more optimal levels of liquidity for liquidity baking? After all, the intention of ‘Liquidity Baking’ is to bring about liquidity, which if inadequately achieved, the other aspects wouldn’t matter so much anyway.
Volume: How would the proposed change render stronger daily volume/activity on the swap side of liquidity baking? (If the small subsidy LB creates is nonetheless a concern to you, the subsidy is offset as a function of volume. In fact, it is possible that the volume can be high enough to offset the subsidy completely.)
Utility: How would the proposed change render better utility of Liquidity Baking for the Tezos ecosystem? Will it provide for more usable/actionable liquidity that will trickle and multiply into better commerce and DeFi on Tezos? If the amount of liquidity is adequate, and the amount of volume is adequate, is the project nonetheless justified by adding true actionable value to the ecosystem.
Let’s be civil, respectful, and show the world an example of how great Tezos on-chain governance is.