The Granada protocol upgrade, activated on Tezos Mainnet in August 2021, is a critical historical reference point for economic analysts and staking providers. It represents the first major departure from the static inflation model, introducing Liquidity Baking, a mechanism that mints a small amount of tez each block and sends it to a dedicated smart contract to incentivize liquidity on a decentralized exchange.
Protocols
Granada Protocol Upgrade
Historical economic impact page documenting the introduction of Liquidity Baking, the reduction in block time to 30 seconds, and the change from the Emmy+ to the Emmy* consensus curve. A key reference for economic analysts and staking providers studying the evolution of Tezos incentives and supply dynamics.
introduction
ECONOMIC PARADIGM SHIFT
Introduction
Granada introduced Liquidity Baking, reduced block times, and altered the consensus curve, marking a foundational shift in Tezos economic policy.
Beyond the new monetary policy, Granada delivered two significant operational changes for bakers and infrastructure providers. The minimal block time was reduced from 60 to 30 seconds, immediately doubling the network's transaction throughput. This was achieved by replacing the Emmy+ consensus algorithm with *Emmy, which flattened the priority-based baking curve, making block production rights more predictable and reducing the advantage of large, highly-optimized baking operations.
For teams modeling Tezos supply dynamics or auditing the evolution of staking rewards, Granada is the genesis of the protocol's modern economic design. Understanding its parameters is essential for contextualizing later changes like Adaptive Issuance. Chainscore Labs helps staking providers and exchanges model the impact of such economic shifts and review integration logic for new protocol-specific smart contracts like the Liquidity Baking CPMM.
GRANADA PROTOCOL UPGRADE
Quick Facts
Key technical and economic changes introduced by the Granada protocol upgrade for impact assessment by operators and economic analysts.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Consensus Algorithm | Introduction of Liquidity Baking, a small subsidy for the tzBTC/XTZ pair on Dexter, creating a new inflation source. | Bakers, staking providers, economic analysts | Review updated inflation and reward distribution models to assess impact on staking yield. |
Block Time | Reduction in block time from 60 seconds to 30 seconds. | Bakers, node operators, indexers, DApp developers | Verify infrastructure can handle the increased block production rate and reduced time for attestation propagation. |
Consensus Curve | Change to the consensus curve parameters to maintain security with the faster block time. | Bakers, security auditors | Review new consensus parameters to understand finality guarantees and fork probabilities under the new model. |
Economic Model | Introduction of a new, continuous inflation source via Liquidity Baking, altering the protocol's supply dynamics. | Stakers, exchanges, economic analysts | Update supply schedule models to account for the new subsidy and its interaction with standard baking rewards. |
Client Software | New protocol environment requires an updated Octez client version for Mainnet participation. | Bakers, node operators | Upgrade to the mandatory Octez client release before the protocol activation to avoid missing endorsements or baking slots. |
DApp Integration | New Michelson operations or changes to existing ones may have been introduced. | DApp developers, wallet providers, auditors | Verify smart contract compatibility against the Granada protocol specification and test on a pre-activation testnet. |
technical-context
LIQUIDITY BAKING AND CONSENSUS TUNING
Technical Mechanism
How Granada altered Tezos block production economics and introduced a protocol-level subsidy for a decentralized exchange.
The Granada protocol upgrade activated on Tezos Mainnet in August 2021, introducing two core technical changes: a reduction in block time from 60 to 30 seconds and the implementation of Liquidity Baking. The block time reduction was achieved by halving the number of endorsement slots per block from 32 to 16, while keeping the minimal delay function constant. This directly increased the throughput of the chain, allowing bakers to produce twice as many blocks per cycle and proportionally reducing the time to finality under the Emmy+ consensus algorithm.
Liquidity Baking was a novel economic mechanism that diverted a small portion of baking rewards—specifically 2.5 tez per block—to a subsidized tzBTC/XTZ liquidity pool on the Dexter decentralized exchange. The protocol minted this subsidy as part of the baking reward and deposited it directly into a dedicated CPMM (Constant Product Market Maker) smart contract. The goal was to bootstrap deep, protocol-owned liquidity for a wrapped Bitcoin asset, reducing slippage for users and establishing a public good liquidity layer. The mechanism was designed to be temporary, with a sunset provision requiring a future governance vote to continue or halt the subsidy.
For bakers and infrastructure operators, the block time reduction required careful performance tuning. The halved block interval meant that baking and endorsement operations had a tighter window for propagation and inclusion, increasing the risk of missed endorsements for under-provisioned nodes. Bakers needed to ensure their hardware and network latency could handle the new cadence. The Liquidity Baking subsidy also introduced a new, permanent protocol-level interaction with a specific smart contract, creating a dependency that indexers, auditors, and economic modelers had to account for when tracking supply inflation and reward distribution.
GRANADA UPGRADE IMPACT
Affected Actors
Bakers and Staking Providers
Granada directly altered the economic incentives for bakers and those who delegate to them. The introduction of Liquidity Baking minted a small amount of tez each block and deposited it into a constant-product market-making contract, effectively diverting a portion of block rewards away from bakers to subsidize liquidity.
Simultaneously, the block time was reduced from 60 to 30 seconds. While this doubled the number of blocks per cycle, the per-block reward was halved to keep total issuance roughly constant. Bakers needed to ensure their infrastructure could handle the increased frequency of block production and attestations without performance degradation.
Action Steps:
- Re-evaluate staking yield models to account for the subsidy siphoned to Liquidity Baking.
- Audit infrastructure to confirm it can reliably bake and attest at a 30-second cadence.
- Monitor the economic sustainability of baking operations under the new reward curve.
implementation-impact
GRANADA UPGRADE
Implementation Impact
Granada introduced three tightly coupled economic changes: Liquidity Baking, a halved block time, and a flattened consensus curve. These altered baker incentives, supply dynamics, and validator hardware requirements.
02
Block Time Reduction
Block time was cut from 60 to 30 seconds, doubling the frequency of balance updates, reorg windows, and RPC polling requirements. Indexers and data pipelines must validate that their ingestion logic handles the increased throughput without race conditions, while wallets and explorers need to confirm UI responsiveness under the faster block cadence.
03
Consensus Curve Flattening
The shift to Emmy* reduced the advantage of large bakers by lowering the threshold for optimal block production. Staking providers and baker operations teams should reassess their expected endorsement frequency and payout models, as the new curve distributes rewards more evenly across delegates, altering competitive dynamics and delegation ROI projections.
04
Baker Configuration Changes
Bakers must update their Octez client to a Granada-compatible version and verify that their daemon correctly handles the new consensus parameters. Failure to upgrade before activation results in missed blocks and endorsements. Operations teams should run a testnet dry-run to confirm mempool behavior and hardware resource usage under the 30-second block target.
GRANADA PROTOCOL UPGRADE
Risk and Compatibility Matrix
Operational and economic risk assessment for bakers, staking providers, and integration teams evaluating the impact of Liquidity Baking, block time reduction, and the consensus curve change.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Consensus | Block time reduced from 60 to 30 seconds | Bakers, node operators, indexers | Verify infrastructure can handle double the block processing load and storage growth |
Consensus | New consensus curve for baking rights | Bakers, staking providers | Re-evaluate baking frequency and hardware requirements for attestation timing |
Economic | Introduction of Liquidity Baking subsidy (2.5 XTZ/block) | Bakers, liquidity providers, economic analysts | Model new issuance impact on supply and staking yield; verify subsidy distribution mechanism |
Economic | Liquidity Baking CPMM contract deployed | DEX integrators, arbitrageurs, wallet teams | Audit contract interaction patterns and ensure correct token allowance handling |
Smart Contract | New Michelson opcodes for CPMM interaction | DApp developers, smart contract auditors | Review new opcode behavior and gas costs for secure integration |
Operations | Faster block propagation requirements | Bakers, node operators | Upgrade network connectivity and validate peer count to avoid missed baking slots |
Integration | Indexer and block explorer schema updates | Data teams, analytics providers, exchange engineers | Update ingestion pipelines for new block cadence and Liquidity Baking operations |
Governance | Liquidity Baking subsidy is a protocol-level parameter | Governance delegates, economic analysts | Monitor for future amendment proposals that could adjust or sunset the subsidy |
GRANADA UPGRADE
Post-Activation Verification Checklist
Operational steps for bakers, staking providers, and integration engineers to confirm a successful transition to the Granada protocol. This checklist focuses on verifying the new consensus curve, the reduced block time, and the activation of the Liquidity Baking subsidy.
Granada reduced the minimal block time from 60 seconds to 30 seconds. This is the most immediate operational signal of a successful activation.
What to check:
- Monitor the timestamp delta between consecutive blocks at the tip of your node's chain.
- Confirm that the median interval has dropped to approximately 30 seconds, not 60.
Why it matters:
- A faster block time changes the cadence of baking and endorsement rights. Staking reward calculations, exchange deposit confirmation counts, and DApp frontend polling intervals must all be recalibrated.
Confirmation signal:
- Your node's
/chains/main/blocksRPC endpoint shows a consistent stream of blocks with a ~30-second gap. If the interval remains at 60 seconds, the node may still be following a pre-activation branch or the activation block has not yet been reached.
resource-links
CANONICAL REFERENCES
Source Resources
Use these sources to verify Granada protocol behavior, governance history, implementation details, and historical chain effects before relying on secondary summaries or economic models.
04
Liquidity Baking Evidence Pack
For Liquidity Baking analysis, collect primary evidence beyond the upgrade summary: protocol code, the on-chain contract state, subsidy accounting, pool reserves, and any wallet or baker opt-out behavior relevant to the period being studied. Risk teams should model Liquidity Baking as an economic mechanism introduced by Granada, not as a generic DEX launch. Validate whether your indexer records the subsidy flow and contract interactions correctly before using the data for inflation, yield, or treasury-exposure analysis.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
GRANADA UPGRADE FAQ
Frequently Asked Questions
Operational and economic questions for bakers, staking providers, and analysts assessing the impact of the Granada protocol upgrade's Liquidity Baking, block time reduction, and consensus changes.
Liquidity Baking is a protocol-level mechanism that mints a small amount of tez (XTZ) each block and deposits it directly into a specific decentralized exchange contract (initially Dexter, later Quipuswap). This subsidizes liquidity provision, replacing direct inflationary rewards to liquidity providers with a protocol-enforced distribution.
Impact for bakers and stakers:
- The total block reward is slightly increased to account for the Liquidity Baking subsidy.
- This does not reduce existing baking or endorsement rewards but adds a new, earmarked inflation component.
- Staking providers should update their reward calculation models to distinguish between standard baking rewards and the Liquidity Baking subsidy, which does not accrue to bakers.
Verification:
- Monitor the
liquidity_baking_toggle_emaand related constants in the protocol parameters. - Confirm the target DEX contract address in the activated protocol's constants.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.