Announcing Granada

This is a joint post from Nomadic Labs, Marigold, TQ, Tarides, and DaiLambda.

We were proud to see Florence go live on the chain on 11th May 2021. In keeping with our policy of proposing upgrades on a regularly scheduled basis, we’re happy to announce our latest Tezos protocol proposal, Granada.

(As is usual, Granada’s “true name” is its hash, which is PtGRANADsDU8R9daYKAgWnQYAJ64omN1o3KMGVCykShA97vQbvV).

Granada contains several major improvements to the protocol, as well as numerous bug fixes and minor improvements. Below we discuss some of the most interesting and important changes:

  • Emmy*: The current Tezos consensus algorithm is Emmy+ and we propose to replace it with Emmy*. As described in this blog post, if Granada is adopted, Emmy* will generally halve the time between blocks, from 60 seconds to 30 seconds, and allow transactions to achieve significantly faster finality than under the current consensus algorithm. (We expect several significant further improvements to our consensus algorithm and reductions in block times in coming proposals.)

  • Liquidity Baking: The availability of low-slippage exchange of tez into other currencies and vice-versa is key to allow the widespread use of Tezos. Liquidity Baking addresses this directly by piggybacking off the liquidity and global availability of Bitcoin, and incentivizing large amounts of decentralized liquidity provision between tez and wrapped bitcoins.

  • Gas improvements: A number of substantial improvements to performance have been made, which in turn result in dramatic reductions in gas consumption. We have generally observed a decrease of a factor of three to six in the gas consumed in the execution of already deployed contracts. For some contracts, the improvement has been almost a factor of eight. This reduction in gas consumption, the latest in a series we began with Delphi, will enable developers to deploy richer, more complicated, and more interesting applications on Tezos at reasonable real-world cost.

Granada contains numerous other bug fixes and small improvements, and we encourage you to look at the changelog for a full description of the contents of the proposal.

We strongly encourage you to test your own Tezos-based applications to check for compatibility problems with Granada. Granada, and the configuration for its test network Granadanet, are included in version 9.2 of the Tezos node.

If Granada is adopted, the next proposal (which likely will have a name starting with the letter “H”) should be proposed and enter the Tezos amendment process this summer.

We hope that “H” will introduce a new consensus algorithm that, if adopted, will bring fast finality to Tezos.

Over the course of the coming months, our team also intends to continue to develop and propose amendments to increase performance, lower gas consumption, reduce block times, and increase Tezos’ throughput (as measured, for example, in transactions per seconds, or smart contract invocations per second).


This proposal is providing free xtz (2.5) each block to a KT1 contract with no oversight. The explanation behind this is literally 1 sentence (ie: ‘Summary’). There is so much jargon used on the draft page.

Can someone please write up an in-depth, fully-explained (start to finish) post on why this is a good thing and how it will be used?


So if blocktime is halved, tps is doubled right?


Speaking of tps, would this be correct if we just calculate tps for basic transactions for Tezos currently? “For Delphi, basic transactions need ~1427 in gas. This doesn’t just decrease transaction costs, it also increases the max amount of transactions per minute (tps) on Tezos. Every block will have a 10,400,000 gas limit, which means that the max tps comes down to 121 tps.”


In the Granada documentation, found at Protocol Granada — Tezos (master branch, 2021/05/31 13:32) documentation, it says (regarding rewards for a priority 0 block/endorse):

" The baking and endorsing rewards are updated as follows:

  • The reward producing a block at priority 0 is updated from e * 1.25 tez to e * 0.078125 tez, and for producing a block at priority 1 or higher, is updated from e * 0.1875 tez to e * 0.011719 tez, where e is the endorsing power of the endorsements contained in the block.
  • The reward for endorsing a block of priority 0 is updated from 1.25 tez to 0.078125 tez per endorsement slot, and for endorsing a block at priority 1 or higher is updated from 0.833333 tez to 0.052083 tez per endorsement slot."

So, if I understand this right, the rewards for priority 0 block in Granada will be 20 tez? Considering that the block time will be 30 seconds, so the income for bakers remains the same, right?


In practice, I support the ideas behind liquidity baking. I am concerned, however, in the way this protocol is being presented.

As far as I understand, the intent here is to produce one proposal for G which tightly couples an asset (TzBTC), asset issuer (Bitcoin Suisse), and exchange (Dexter) to a number of common sense improvements (faster consensus, lower gas). This effectively means that if the community wishes to uptake common sense improvements we must also decide to crown TzBTC, Bitcoin Suisse, and Dexter as “first class” assets, teams, and products in the protocol. This is bad.

By accepting a single choice for Protocol G, the bakers and users of the network effectively cede a broad range of powers to the Core Devs (Marigold, Nomadic, DaiLambda) to pick and choose winning and losers at the asset (TzBTC vs wBTC), team (Bitcoin Suisse vs Bender Labs), and product (Dexter vs Quipuswap) levels. This should not be the job of the core protocol teams and it creates a bad precedent and slippery slope for future proposals.

Tezos clearly defines bakers (validators who have been given voting power by users of the network) as the stewards of network’s well being. By coupling Liquidity Baking to common sense improvements, the Core Development teams erode the purpose of bakers and give the development teams undue influence. Instead, if core development teams think that Liquidity baking is in fact a useful feature, they should present a variety of protocols [1] and let the bakers choose.

The precedent being set here is extremely important to how future protocol and product development on Tezos happens . As with Baking Accounts, I’d expect/hope that a number of proposals are injected and Bakers can decide on the right asset. I’d suggest we inject the following:

  • TzBTC, backed by Bitcoin Suisse
  • wBTC, backed by Bender Labs
  • EthTZ, backed by StableTech
  • Granada with no liquidity baking

The bakers, as stewards of the network, should be able to choose if they want first class assets, and if so, what that asset should be. Perhaps TzBTC is, in fact, the obvious choice. If so, it should be no problem to let the baker community make that decision. I am happy to lend my time to work on creating / injecting these other protocol upgrades if there is broad support from bakers.

To be clear, I have no moral oppositions to liquidity baking (it’s a neat feature) but I have grave concerns with how the asset is chosen. I sincerely hope that the teams working on this will make the right (but harder) choice of presenting a slate of options.

[1] To their credit, Florence contained a few options for Baking Accounts and equally controversial feature. I commend the core development teams for their efforts here.


Thank you for speaking my mind!


Great post and i fully agree with you. Thankyou for writing this up!


I believe there’s no difference between using a dexter or quipuswap contract for that matter especially when it’s not even marketed as Dexter’s but rather a dex contract that’s not tied to any exchange and is verified/audited etc etc. But we can vote on that of course

I’m more concerned about an asset choise, as I said on the LB agora topic a stablecoin fit better

As I mentioned earlier I’m all in favour of subsidizing an xtz / stablecoin pair instead of tzbtc.
Not only it seems reasonable to have liquidity to be able to hedge or trade against a low volatile to fiat asset, it also gives an opportunity to drive adoption to our native assets, whereas tzbtc is a custodial asset which I’m not a big fan of

@keefertaylor 's modesty didn’t let him suggest an xtz / kUSD pair but personally I’d love to see a building block of tezos defi subsidized with LB instead of a custodial wrapped version of btc


Has there never been Multiple Proposals ever made before?

I am also upset with the Liquidity baking. I wish i could inject my own proposal, i was actually trying my best to make one last week but i kept failing.

Theres no step-by-step guide for “any baker to inject a proposal”

It feel like an idiot for upvoting it after i saw it was injected. I tried to vote NO and it wouldnt let me, so i thought my only choice was to upvote and then vote NO in the next phase when NO votes are allowed.

Personally I just want the damn baking bonds lowered. I dont care about anything else right now.

So tomorrow when im nice and rested im going to give it another shot, ill fork florence, reduce bonds by 6% and then inject it.

Wish me luck.


I think @NomadicLabs should consider doing a TezosAgora AMA before injecting each new proposal. So that the bakers and the rest of the community can prepare for it and ask all the relevant questions regarding the proposal before its actually injected for a vote. It could avoid potential disagreements like we can see now regarding the specifics for Liquidity Baking.


I don’t believe this was poorly intended on Nomadic’s part, and I thank Nomadic for inviting such commentary and for reading this feedback. That’s why it’s good we have these discussions. To clarify what needs to be made apparent. That’s the beauty of on-chain governance that makes me thankful for Tezos.

On the issue, by including this one company’s 3rd party dApp into the upgrade, even if it’s just the example token, it venerates that single actor - it anoints them with a status of legitimacy that is anti-competitive, and it’s antithetical to what we’ve all come to know as Tezonian values, or even Blockchain community values for that matter.

Furthermore, and not to distract from the point, but unlike this company, there are also plenty of entities (yes, obviously that includes mine) that have been highly proactive in engaging the Tezos community that have not even been consulted nor considered for inclusion. This would also be a slap in the face to all of us as well in the favor of a financial institution that has had nothing to do with Tezos for all this time. I am not advocating that our nor any entity’s 3rd party token be ‘added’ to the list of what’s included in this measure. Rather, I am arguing that no 3rd party entity’s token should be baked into a protocol upgrade.

Even if you disagree, you have to admit…it comes off a bit odd, no?


I think I like Keefer’s approach to let bakers vote on the type of asset for initial support. I also voiced this in the Liquidity Baking post that a more appropriate route would be to focus on stablecoins, but I also recognize that our ecosystem as a whole lags in deep liquidity pools. So agree with moving forward with this proposal, but also allowing bakers to vote on the type of asset!


I agree with Keefer in that bakers should be given a choice in which pair to support. Let’s see which pair wins based on merit rather than lack of choice.

Going forward it’s going to be hard to please the quorum so you will be forced to put multiple option proposals together, might as well start now.


Multiple proposals have been made before.

We need to see a good faith effort from the devs to adhere to the ethos of “every baker can insert” a proposal not just well informed core devs from Nomadic Labs (and those influenced by the former) can insert a proposal and bakers have no say in what features are included.

We need to see a concerted effort to bring more people into core dev and more importantly into ADVERSARIAL core dev in case someone, a large group of bakers want to put forward their own proposals to modify the variables.

I suggest making a dev available to work with any large team of bakers who agree to modify some feature and want to see if they can get to quorum. That would go with the spirit of openness we promote as fact.


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.

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.

It’s even more bizarre to claim that using a codebase loosely based on the dexter contract is somehow “annoiting” Dexter as opposed to Quipuswap. Because it’s also based on Uniswap, would you also argue it’s picking Uniswap over Bancor as a winner? This is a bit of code that computes a mathematical function to swap two tokens, not a “project”.


Thanks for clarifying that, we will vote yay for Liquidity Baking.

The power of freeing up 7.2mm tez for liquidity will be a game changer for DeFi and even price discovery.

I don’t see the issue with tzBTC since Bitcoin is the most liquid cryptocurrency and tzBTC has been one of the first wrapped assets for Tezos.


I rather have faster finality and liquidity at once. We need to move faster in this space and become the best blockchain for DeFi and NFTs.


I’m glad you didn’t go further and suggest four more where x * y = k is computed using code inspired by different code bases.

Creating alternative proposals takes quite bit of work and time, and it’s always a tradeoff. It happens at the expense of features, or additional reviews. Even with several versions, choices have to be made.

Given that liquidity baking has an escape hatch for instance, the last proposal seems superfluous: the feature can be turned off by the very bakers who would vote on the proposal.

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.

Besides the point of principle you’re making, it would be useful if you laid out what you personally think of the suitability of the different options you described. Not the pros and cons, but your unfiltered opinion as to how good of a choice these would be in your eyes.