Announcing Granada

I’m not sure how I can communicate this effectively. If you increase a value, then 100% of it is more than it previously was. Baking and endorsing rewards plus the liquidity baking subsidy is more than just baking and endorsing rewards, since the liquidity baking subsidy is additional and is not subtracted from the baking and endorsing rewards (as in your graphic).

6 Likes

The liquidity baking subsidy is not meant to provide significant liquidity, it’s meant to incentivize liquidity providers in comparison to what they’d be paid in baking and endorsing rewards. You write, “even with only two years of subsidy there would be already around 1M of tez + 1k BTC,” but this is far from enough liquidity to be worth the inflation from the subsidy. Liquidity baking will provide ~200x that much liquidity fairly soon after it goes live.

7 Likes

I am not sure if I agree with the LB and tzBTC, but I guess it is an experiment and we will see how it works and affects the eco system in general so we will vote yes to the proposal.
It is better than doing nothing :wink:

5 Likes

100% agreed. It’s better to experiment and try new things than being conservative. If the net result benefits the whole ecosystem with faster finality and liquidity then I’m happy to vote yay

5 Likes

The KT1 contract address has no owner (tz1 manager) right?

There haven’t been managers in smart contracts since Babylon.

1 Like

ohhh i see. Never mind then ^^

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?
11 Likes

I’ve already up-voted Granada in the current form, here my reasoning and how I see this upgrade which I think is at the same level of awesomeness as Edo and probably will be H.

About LB feature, I read and follow this since January reading Andreas and Sophia posts, knowing the trade-off, mathematical calculations and risks we are assuming.

I didn’t however discuss about it with them because somehow I didn’t know that this will hit Granada, also because in part I agree with the intention of it.

I also found concerning some level of centralization in this kind of decisions, I think giving the option to chose with/without some feature is a must if this has issues/risks/caveats.

As is described in security considerations this are the main risks that we need to be sure we are going to take:

  1. While the codebase the CPMM is forked from has been formally verified against its functional specification and is currently being audited by Least Authority, a vulnerability was discovered in the previous version. The new version is a complete rewrite and we are confident that the increased attention from its use in liquidity baking will harden its security, noting that this is partly what led to the discovery of the vulnerability in the previous version.
  2. Although the tzBTC contract has already been audited once by Least Authority, another review of the contract is worthwhile.
  3. tzBTC, while controlled by multiple reputable institutions via a multisignature is not trustless, therefore the mechanism depends on the continuing availability of tzBTC portals. We note that large amounts of liquidity exist for the similar WBTC contract on Uniswap (an Ethereum-based CPMM).

But we need to manage this risk and the upside of having this at protocol level, this change has the potential to push us to Uniswap liquidity - QUICK -, we are talking on giving LP real deal incentive not some rug-pull token.

The math is sound, it doesn’t affect bakers rewards, at lower liquidity the yield of the pool will be so high, that will be fill up pretty nicely.

I think we can’t be “right” and be “successful” all the time, Tezos is perceived now as Clean or energy efficient blockchain and Bitcoin is the exact opposite of this and in my view represent what Tezos should never be, at technical and community level; but as is described in the proposal motivation:

Liquidity is a key component of a good store of value, and money is even sometimes defined as the most liquid means of exchange. Despite its widespread availability tez remains, to this day, one of the least liquid of the major cryptocurrencies.

We have to address this if we want to compete, and I think we don’t have the privilege to be fully politically correct and “win” the race at the same time, some trade-off and risk must be taken, at least for now while some other token get battle tested without the caveats of tzBTC.

Just my 2cents.

4 Likes

Clearly you do not.

It’s important to be precise. Your claims are grounded in a long collection of such half truths. The fact that there is an entire consortium matters and is directly germane to your point about benefiting one party. It’s in fact a consortium which has historically grown and accepted new members. This is information you could have obtained by just looking at the homepage of tzBTC but which didn’t fit your narrative. Presenting it as nitpicking is flippant, at best.

No, they are being paid a moderate amount (probably on the order of a few $100k for wrapping on the order of a few $100m of btc) which is well within the market to provide a useful service. It’s nonsense to present this as privilege. You have personally received a protocol invoice for service rendered, that does not make you “privileged” at the protocol level or somehow consolidate your “power” over it.

So I leave you with two questions:

  1. 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?

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

6 Likes

Maybe, if the trading volume exceed our expectations, we can even increase the trading fee from 0.01% to 0.02% to increase the burning rate and make it actually deflationary? Get liquidity and deflation, killing two birds with the same shot.

So we obviously have a problem here ladies and gentleman. Lets not pretend its not a big deal. Lets all figure out what the CORE of the issue is here and look for a solution.

I see Two sides to this story. Yaya and Nana.

Lets keep these discussions active even after the proposal period has ended. We need to continue engaging everyone involved with Tezos so we can all make a greater impact.

Totally agreed.

But I’m also in favor of proceeding just to push things forward and allow forces to align things as they should be in the future.

1 Like

The only thing i wish is, that these kind of discussions will happen constantly. The drama explodes every time AFTER or 1-2 Days before a protocol injection. People who have concerns should raise them constantly, right after they discovered/think they discovered it.

There is generally too less discussion about everything.

11 Likes

Great article from midl.dev on how Liquidity Baking works and should help people become more informed on this feature.

Something that should be pointed out from the article:

“This is an experiment: it is written in a way that will phase out in 6 months without any intervention. To continue the experiment, another protocol upgrade vote will be needed. There is also an escape hatch: bakers can raise a flag for the experiment to stop sooner. If enough bakers do, the 2.5 tez liquidity rewards per block will stop flowing”

This is actually a great way to experiment new features on the protocol level, so in my opinion, I think the community should be open to experimenting with this as there are contingencies in place if it doesn’t achieve the results that we hope for. If the experiment is a success then we enabled a massive amount of liquidity for Tezos and can continue to add new tokens in future protocol upgrades. This feature is cutting-edge and I am personally very excited to see the results of this if implemented.

11 Likes

My question regarding the choice for tzBTC is, why start with an asset that requires KYC to mint? I get that institutions will likely have no problem meeting or wanting to meet KYC requirements, and probably are the main targets from drawing liquidity onto Tezos, but I think it would be a mistake to disregard the power/value of retail traders, many of whom probably would prefer to avoid onerous KYC requirements. Otherwise they’d just be trading on centralized exchanges.

2 Likes

I think that Keefer’s intentions are good here and he has contributed a lot to the Tezos community so I found the responses to his concerns to be unnecessarily harsh. That said, I can also empathize with others who are frustrated with having this debate now when liquidity baking was discussed at great length in Agora over a couple of months, so it’s not like people didn’t know what was coming. Perfect is the enemy of good, and I believe that liquidity baking is a worthwhile experiment that may add great upside to Tezos. If people hate it once it’s live, then we make it better or kill it and move on. I vote yes.

7 Likes

implementing something is easier then rolling something back. The risks far outweigh the reward imho in this scenario. Putting aside the specifics of what token is being back for this proposal , no one is seeming to understand the ramifications of the perception of the economic model changing. Yes the “inflation” is offset with this burn and locked contract etc etc, but goodluck explaining that to the people we are hoping and trying to market it too. The intentions might be good, but the perception i believe will be damaged. Not everyone is as intelligent as you Arthur, and dont expect them to ever be. Dont assume people will understand what this proposal implies. All the “dumb” money will look at this as just an inflation increase and leave it at that. 1 step forward, 2 steps back my 2 cents. Learning how to build and innovate is one skill set which you are talented at Arthur, but knowing how to sell needs work.

Actually it looks very easy to roll back with the escape hatch.

Your logic is by far the dumbest reason to not implement a powerful feature for Tezos. When you care so much about the optics than the functionality then you should be involved with another project like Cardano.

4 Likes

Optics goes hand in hand with features. If the optics are not good, how do you expect onboarding to happen? Expecting for people to assume you are better just because you are is not how reality works. Dont mean to burst any bubbles, and if we are comparing, Cardano is actually outperforming us by a long shot. Numbers dont lie, People do.