How does Tezos upgrade itself without hard forks? · Jumpstart Blockchain
How does Tezos upgrade itself without hard forks?
Tezos bakers vote on protocol upgrades on-chain, weighted by stake, through proposal, exploration, cooldown, promotion and adoption periods. Once approved, every node switches automatically, so the chain doesn't split.
Tezos treats the protocol itself as something the chain can vote on. The rules that validate blocks live in a replaceable economic protocol, separate from the node's networking and storage layer. When bakers approve a new protocol through an on-chain vote, every node switches to it at a known block, automatically. There is no coordinated software release where half the network might refuse to upgrade, so the chain doesn't split. This is called self-amendment, and Tezos has used it for every upgrade since 2019.
The shell and the protocol
A Tezos node (Octez) has two parts:
Part
Responsibility
Changes via
Shell
Peer-to-peer networking, storage, validation pipeline, the mempool
The node ships with the code for upcoming protocols and can also fetch a proposed protocol's source over the network. Because the voting rules are part of the protocol, the governance process can amend itself too, and it has several times.
The five governance periods
An amendment moves through five periods. Each lasts a fixed number of blocks (a matter of weeks, so a successful upgrade takes a few months end to end). If a vote fails at any stage, the process drops back to a new proposal period.
Period
What happens
Passes when
Proposal
Bakers submit protocol proposals (by hash) and upvote any they support
The top proposal clears a minimum share of voting power, roughly 5%
Exploration
Bakers vote yay, nay or pass on the winning proposal
Participation meets the quorum and yay is at least 80% of yay + nay
Cooldown
No voting. Time for testing, audits and community review
Always proceeds
Promotion
A second, final vote with the same ballot choices
Same quorum and 80% supermajority
Adoption
No voting. Node operators, indexers, wallets and exchanges prepare
The new protocol activates at the end of the period
Two details matter:
Voting power is proportional to stake. A baker's vote counts according to the tez it has baking rights on, including delegated funds.
The quorum adapts. It tracks an exponential moving average of past participation and is bounded between a floor and a ceiling (20% and 70% in current rules), so low turnout doesn't let a small group force a change, and high expectations don't block governance forever.
pass counts toward the quorum but not toward the supermajority. It lets a baker say "I participated" without taking a side.
From the command line, a baker interacts with governance like this:
# Where are we in the governance cycle?
octez-client show voting period
# During the proposal period: submit or upvote a proposal
octez-client submit proposals for my_baker <proposal_hash>
# During exploration or promotion: cast a ballot
octez-client submit ballot for my_baker <proposal_hash> yay
Protocols are named alphabetically
Each adopted protocol gets a city name, in alphabetical order, which makes the upgrade history easy to follow:
Protocol
Notable change
Athens (2019)
First self-amendment; lowered the baking roll size
Babylon
Emmy+ consensus, Michelson entrypoints
Carthage, Delphi, Edo
Gas and storage cost changes; Edo added the adoption period and Sapling
Florence, Granada
Larger operation limits; Granada introduced Liquid Baking and faster blocks
Hangzhou, Ithaca
Ithaca replaced Emmy* with Tenderbake, giving deterministic finality
Throughput work; Oxford began the new staking mechanism's groundwork
Paris (2024)
Adaptive issuance and staking enabled; data availability layer
Quebec (2025)
Faster blocks and staking parameter changes
Later protocols, such as Rio, continued the sequence. Check a block explorer for the protocol currently active, since a new one may have been adopted since this was written.
Liquid proof of stake: baking, delegation and staking
Tezos consensus is liquid proof of stake. Block producers are called bakers. They need a minimum own stake (a few thousand tez), run a node, and sign blocks and consensus operations.
Holders who don't want to run infrastructure can delegate. Delegation points your account's baking rights at a baker without moving your tez. You keep custody, can spend at any time, and can change baker with one operation:
octez-client set delegate for my_account to my_baker
Delegated tez is never at risk if the baker misbehaves. That's the "liquid" part: no lock-up, no custody transfer.
The Paris protocol added a second option, staking. Staked tez is locked with a chosen baker, counts more heavily toward that baker's rights than delegated tez, earns a larger share of rewards, and is slashable if the baker double-signs. Unstaking has a delay of several cycles. Bakers set how much external stake they accept and what fee they charge. Quebec and later protocols have adjusted the weightings and limits, so check current documentation for exact figures. The key distinction holds: delegation is free of lock-up and slashing, while staking earns more in exchange for both.
Consensus since Ithaca is Tenderbake, a BFT-style algorithm. A block is final once two further blocks are built on it, so Tezos doesn't need Bitcoin-style probabilistic confirmation counts.
Smart contracts: Michelson and friends
On-chain code runs in Michelson, a strongly typed, stack-based language designed so contracts can be formally verified. A minimal contract that adds its parameter to its storage:
Every contract takes a (parameter, storage) pair and returns a (list operation, storage) pair. Few people write Michelson by hand. The common high-level options are:
SmartPy: Python syntax, with a built-in testing framework.
LIGO: JsLIGO (TypeScript-like) and CameLIGO (OCaml-like) syntaxes.
Archetype: a higher-level language focused on business logic and verification.
All of these compile to Michelson. Self-amendment also covers the language: new instructions and cheaper gas arrive through protocol upgrades, not a separate VM release.
Trade-offs vs social-consensus upgrades
Bitcoin and Ethereum upgrade by social consensus. Developers ship new client software, operators choose to run it, and miners or validators signal readiness. A contested change can produce a chain split, as Ethereum Classic and Bitcoin Cash did.
Tezos self-amendment
Bitcoin / Ethereum
Who decides
Bakers, weighted by stake
Developers, node operators, miners or validators, users, exchanges
How it activates
Automatically after the adoption period
Coordinated client release and activation height
Chain split risk
Low: nodes follow the voted protocol
Possible if a significant group refuses
Upgrade frequency
Regular, several per year historically
Infrequent, carefully batched
Main criticism
Governance power follows capital; large bakers and exchanges carry weight
Slow, opaque, and dependent on informal influence
Self-amendment doesn't remove politics. It moves the decision into a formal, auditable vote. Bakers who delegate from exchanges hold a lot of voting power, turnout matters, and a determined minority can still fork off with modified software. The mechanism makes the default path clear and non-splitting, which is why Tezos has shipped a long run of upgrades without a contentious fork.
Summary
Tezos separates the node shell from the economic protocol, and the protocol can be replaced by vote.
Upgrades pass through proposal, exploration, cooldown, promotion and adoption periods, needing quorum and an 80% supermajority in both votes.
Voting power follows stake. Bakers vote, and delegators influence them by choosing where to delegate.
Delegation keeps tez liquid and unslashable. Staking, since Paris, locks tez for higher rewards and slashing risk.
The result is predictable, non-splitting upgrades, at the cost of formalising governance around stake.
