How does Tezos upgrade itself without hard forks?

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	Ordinary node software releases
Economic protocol	Consensus rules, transaction semantics, Michelson, fees, rewards, governance itself	On-chain vote

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
Jakarta, Kathmandu, Lima	Transaction rollups (later removed), pipelining improvements
Mumbai	Smart rollups on mainnet
Nairobi, Oxford	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:

parameter int;
storage int;
code { UNPAIR ; ADD ; NIL operation ; PAIR }

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

1. Tezos separates the node shell from the economic protocol, and the protocol can be replaced by vote.
2. Upgrades pass through proposal, exploration, cooldown, promotion and adoption periods, needing quorum and an 80% supermajority in both votes.
3. Voting power follows stake. Bakers vote, and delegators influence them by choosing where to delegate.
4. Delegation keeps tez liquid and unslashable. Staking, since Paris, locks tez for higher rewards and slashing risk.
5. The result is predictable, non-splitting upgrades, at the cost of formalising governance around stake.