I think LB is great. More liquidity reduces the cost of participation for huge actors. Inflation funding is great. Therefore, LB is great.
However, there has been a bit of a kerkuffle around it. As such, I’ll express my opinion for it. I am also soon releasing a no-LB proposal, so that people cannot undermine the arguments I’m bringing in good faith to this discussion.
By the way, this post is in my name only, and does not reflect the opinions of people working at Marigold and LigoLANG.
I’m usually more focused on dev matters. Specifically, my main job is to bring L2s to Tezos, which I believe is the best use of my time and the best way for me to contribute.
But as of right now, Ithaca might not pass. As such, I’m finding myself reluctantly pulled into what I consider to be an unnecessary debate about the benefits of LB, which to me are clear.
LB is obviously a strong net positive to Tezos. I don’t really think there is a need for a synthesis of the pro-LB and anti-LB positions. From my point of view, the anti-LB position is simply wrong.
Unfortunately, the right arguments are technical and not immediately obvious. While many, including Arthur, took it to heart to defend it through correct arguments, this approach is not always the most convincing one.
Meanwhile, detractors engaged in a giant gish gallop against LB: i.e. a huge pile of bad arguments. So, while you can refute all those arguments individually, to a non-technical observer, it looks like there is something when there is nothing. On top of this, it is good to remember that:
- Sometimes, “There is no smoke without fire”. Especially when some people are committed to create debates where there is nothing to be debated.
- “I’m just asking questions” is not a valid defense. Especially when the questions all point to the same direction, are rethorical, and there is no acknowledgement of them having been misguided when they get answered.
The best way to notice is this is the following: no one has any idea what the main counter-argument to LB is. There are various feelings and small counter-arguments involved, but no primary reason why it should not get voted. The closest thing to it would be the choice of tzBTC, but this has already been addressed numerous times, with the detractors not addressing the replies nor changing their stance whatsoever.
The worst thing is, the current discourse is not even about LB anymore! It’s about the lack of choice around LB.
From my point of view, the reason behind this is that the debate has moved on: people have seen that it does not really make sense to disagree with LB on its merits, so instead, to keep the debate going, the disagreement is now about the form. For instance, “TF should have asked core devs to offer a different pair on the behalf of some bakers!”, “TF should have asked core devs to offer a no-LB option on the behalf of some bakers!”, etc.
There are two components to Liquidity Baking: the first one is the “Liquidity” part, the second one is the “Baking” part.
The “Baking” part is very easy to understand: it is simply funding stuff with inflation. Many things can be funded with inflation:
- The honesty and expenses of the consensus participants (miners, bakers, etc.)
- The work of core teams
The Tezos whitepaper already mentioned non-standard inflation funding a long time ago. Most notably, inflation funding marketing by giving 100k$/week to various charities. (Coincidentally, this amounts to ~5mln$ per year, which is ~.15%/year of inflation, not that far from LB.)
So, let’s move to the “Liquidity” part. Here, we are talking about how much liquidity there is in a given “pair”, “swap”, “Dex”, “CFMM”, “AMM”: concretely, a smart-contract that allows exchanges between a pair of tokens. People can buy/sell one of the tokens of the pair, and the smart-contract will provide some of the other token of the pair at a rate computed automatically.
The liquidity is the amount of tokens that is locked in the contract, as it needs some tokens to satisfy the buy/sell orders.
Usually, liquidity is provided by Liquidity Providers (LP). People putting money in the smart-contract, and getting a fixed-cut (.2% for instance) of all buy and sell orders going through the exchange.
The goal of LB is to incentivize the liquidity of such a pair through inflation funding. Straightforward enough.
Now the question is: why would we want to do that? What is the benefit of having a lot of liquidity on a single pair?
This is where things usually become very technical very quickly. But basically: the more liquidity you have in a pair, the more stable its price is in the face of spikes in the order flow. This is the basic mechanism that underpins everything.
Another mechanism that is important to have in mind is that if you have one pair that lets you trade between A and B, and one pair between B and C, you have an indirect pair between A and C.
From this, you derive a lot of benefits:
- DEXes become more resilient to short-term shocks (someone buying/selling a lot, market manipulation, temporary bad buzz)
- It becomes possible to trade big amounts without having to go through a centralized exchange, which makes Defi possible
- It becomes possible to buy/sell large amounts of XTZ, or tokens on Tezos, much more cheaply
- This makes it much less risky for people to hold XTZ, as they can liquidate their position more easily. Which makes it a better store of value
- This makes it much less risky for people to come and arbitrage Tezos’ Defi ecosystem, which makes it much more efficient
The obvious concern here is inflation. But even an entire percent LB would be comparable to baker fees (not rewards!), and both would be absolutely dwarfed by typical moves in crypto markets.
As one might see, I’m a bit annoyed with the current situation. LB is a net positive, and completely plays to Tezos’ core strength of onchain governance.
To show that I am saying all of this in good faith, and that I am not trying to censor alternative proposals or whatever, I’ll just make a no-LB proposal. It is not one that removes the code of LB, it merely sets its sunset to right after the deployment of the new protocol, but that will work.