Upgrading Liquidity Baking — an open discussion to inform future proposals

Research and Development
1

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:

  1. Release core proposal amendments early instead of late in the Proposal period
  2. 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.

  1. Liquidity

  2. Volume

  3. Utility


(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.

3

I’d like to see some discussion around a migration plan, before even discussing what token is the right token (as I keep highlighting). If an approach is taken that means the existing subsidy is stopped and pointed to another token, this has a lot of implications to the end users who are invested already. They will need to be made aware of this change and given the tools to withdraw from one and migrate to another. This will require development effort on the side of wallets + dApps + indexers, who have integrated this feature. These teams need to be involved in these discussions.

To do this correctly, would mean that users would need to see some kind of a banner or notification of these changes inside these apps, with an explanation and possibly links to further info, as well as the functionality to migrate. There is a lot of work here.

Someone is also going to have to produce an article (way in advance of the actual change) that will answer users questions. A new standard for the network constants will most likely need to be agreed, if this is likely to change multiple times, developers would need an easier way to manage this, rather than pushing manual updates to point to a new token. App developers will also need time to do all this, and make sure they can get updates into the app stores in time.

Launching such a change without users being notified (twitter is not sufficient), understanding what it means, or anyway to act on it inside their apps, would be a PR disaster for Tezos that should be avoided at all costs

2 Likes
4

[Oof, this is ranty - didn’t realize I had it in me. Apologies ahead of time.]

+1 for Kevin and Simon - there’s a lot to do here at the meta-level in terms of establishing processes for 1) informally evaluating competing proposals before the formal amendment process, and 2) publicizing the discussions, the resulting decision, and the migration paths.

To critique Kevin’s framework, I’d add a “Cost” category as this was the main concern of the “no” voters (inflation = cost). I might also merge liquidity and volume (they should be tightly correlated).

Finally, I have three specific suggestions:

  1. We should run multiple LB experiments in parallel, for multiple pairs.
    1. At least one of those pairs should be a stablecoin. We need a liquid stablecoin to keep money in the DeFi ecosystem when traders want to sell - currently they have to do this via centralized exchanges and they get USD that isn’t Tezos-native. Relatedly, bonus points if that stablecoin has yield.
  2. We should dramatically increase the total LB subsidy across the pairs (I’d 10x it for starters).
  3. We should experiment with locking (bonding) liquidity deposits. When you lock you start to accrue rewards immediately, but it takes ~4 weeks to unbond, during which time you earn nothing.

I want to emphasize 3) because it’s non-obvious to some people: Prices are set at the margin where buyers meet sellers. (Relatedly, this is one reason the notion of total market cap (price * supply) is problematic). The purpose of bonding is to reduce the number of sellers, which tends to increase the spot price.

If you’ve been brainwashed by classical economics, you might assume everyone is a rational actor globally optimizing over an infinite time horizon, in which case bonding has little effect (the actors will just plan their unbondings ahead of time). This is not how real people act. Instead, traders tend to optimize greedily over short time horizons. This is why bonding works - it’s a trap for that greedy optimization process, because it is never short-term optimal to unbond. The result is way more people stay bonded than you’d expect if they were optimizing over long-term horizons, which means the spot price goes up.

As a case in point, consider Osmosis, the main Cosmos ecosystem DEX. They have ~100% inflation from rewards, which they use to incentivize liquidity in lots of different pools. As a result they had $4.5B in TVL last I checked. Crucially, liquidity providers must bond their contributions, which tends to trap Osmosis in the system, which is why the OSMO price can keep going up even though the inflation rate is stupid. (Also, their code is low-effort golang trash, unlike the beautifully architected Octez, which just goes to show how little technical competence matters in comparison to an understanding of human psychology.)

Notes in the frameworks:

Cost: Even if we doubled the effective inflation, it would be tiny compared to variations in the spot price. Many other cryptos have much higher inflation with little ill effect.

Liquidity / Volume: Obviously higher LB rewards means higher liquidity and probably higher volume.

1 Like
5

I agree that we should have the goal of liquidity baking multiple assets. Instead of trying to find the one. More bridges , more liquidity. The Lugh , USDtz, and tzBTC to start. Unless there is a good reason not to.
There is a good reason to settle this and move on to addressing other issues like Metcalfes law, development for iOS and android to increase user base, and interoperability.
Thanks.

PS
Roll ups have to happen soon as well.

6

Here’s an idea I’ve been playing with that has nothing to do changing/adding to the token pair:

What if: Instead of sending the LB fees to a burn account, we send it to a new [secondary] pool contract where it can provide 'Permanent Liquidity’

Currently, the 0.1% nominal trading fee for trading the liquidity baking contract is sent to a burn account. This is done to offset the subsidy in part or in full.

Let’s assume we can stimulate more volume for Liquidity Baking (whatever the token pair). If we look at Uniswap as an example of how much volume a full-scale AMM can provide we can see that the volume-liquidity ratio is strong, and therefore the fees can be quite significant.

With $20M in liquidity baking, assume we can achieve a tzBTC/XTZ pair that is comparable in its volume-liquidity ratio as is the WBTC/ETH pair on Uniswap. Volume/day is about ~8.5% based on an average of 7D volume.

image
image1796×804 127 KB

(One can argue an even more optimistic expectation for LB volume-liquidity ratio given the relatively minuscule gas fees of Tezos network, and given the low trading fee of 0.1%.)

If we factor in our trading fee of 0.1% to 8.5% of our 20M TVL for Liquidity Baking, we will have (.001*.085*20,000,000) = $1,700

Instead of burning this fee, if we added that liquidity to a new pool contract, that contract would accumulate over the course of a year (1,700*365)= $620,500 permanent liquidity after 1 year

Over time this would make for an excellent reservoir that cannot be depleted nor would it need to be incentivized with a subsidy as it would not necessitate liquidity providers at all. It could run without fees since no incentive is needed to keep it going, or its fees could go to subsidize other Tezos projects. Or it could be burned to deflate the supply. The latter I think is most interesting. Since there’s no rush to deflate the marginal supply increase from LB, we can set our sights on long-term deflation after the permanent contract really takes off. At that point we’d have a permanent deflationary mechanism in the protocol, without an inflationary subsidy whatsoever.

In practice, this pool can be aggregated with the original LB pool for user trades, which would bring trading fees down even more over time (assuming the fee for the permanent pool is lower than that of the original pool). That would keep LP participation in LB up and increasing.

Eventually, after some number of years the original contract subsidy could potentially end, and nonetheless it will have created a permanent pool which will serve us eternally and which will be offsetting the subsidies granted in the past (and then some!).

7

That’s a cool idea - Permanent Liquidity is both deflationary and keeps the tez around to provide liquidity.

Also, it’s equivalent to keeping the system we currently have, plus having the chain mint new tez to fund a new Permanent Liquidity pool. This begs the question - why not just have the chain directly mint new tez to fund the PL pool?

Also, where would you get the pair coin for the PL pool? E.g. if it’s tzBTC / XTZ, how would the pool be provided tzBTC? I suppose you could just dump tez into the pool and rely on arbitrage to fix the ratio, but you’d lose a lot of money to arbitrage.

8

I think this is a great idea. It would mean even if a new LB pair gets added or the pair gets changed, the more mature the pair is the less you would lose when trading between those two tokens which in hindsight seems like how it should work anyways, even after the pair has been removed from LB.

9

Yep, sacrificing one for another would be a problem. I think at this point we have to consider adding second pairing as I originally proposed doing anyway, as opposed to replacing one for another. After that original topic proposal received a considerable number of likes I asked the core developers behind liquidity baking what their thoughts were and if they could assist in adding the token.

One of them

  1. directed me to this article
  2. told me a token change needs to come from a community amendment proposal (not from the core development teams)

This was the only reason why we created a protocol injection that would replace one for another as opposed to our original plan of adding a second token. It was because that was the specific path in which we were were directed to ready made instructions. Tip toeing around Tezos politics, we wanted to commit the most ‘non-offensive’ action, given the fallout of Granada. We certainly didn’t want anyone in core development speaking against the proposal.

That doesn’t mean all LB advocates agreed with that specific action, but what could we do then,… hindsight is 20/20.

10

The more radical the change the harder it will be to push through a vote. Also the more numerous the changes, and the more numerous the variables, the harder it is to measure the impact of any specific one, in terms of data. I think we need to be very minimalist with our proposed changes with each proposal so we can isolate the data and do proper A/B testing.

Regarding 1, yeah I think adding a pair makes the most sense at this point. The question is do we split the subsidy, or leave the subsidy untouched for tzBTC, and add a separate subsidy for the other. The former may upset those that want to preserve tzBTC pairing as is. The latter would upset the subsidy hawks out there that can barely tolerate the current subsidy. If the latter, a strong case would have to be made that volume will be high enough to negate this added subsidy via the fee burning mechanism already a part of liquidity baking.

Regarding 2, I think this would cause a political firestorm 10x worse than Ithaca1-exploration period.

Regarding 3, This is an interesting option to offer. What would be the smallest experimental version of this?

11

Sounds good, the question is are we increasing the subsidy or capping the current subsidy and splitting it across the added pairs? The current subsidy for XTZ/tzBTC pairing is 2.5 tez per block, which is about ~0.3% added inflation a year (3 tenths of 1 percent added per year).

1 Like