Skip to main content

History of amendments

As presented in the Governance on-chain chapter, the Tezos blockchain is constantly evolving, through new amendments. In this chapter, we will present an overview of past proposals and the reasons for their approval or disapproval.

Athens (Pt24m4xiP)

Athens was autonomously activated in May 2019.

Athens was the first proposed protocol amendment for Tezos. Two proposals - Athens A and Athens B - were proposed by Nomadic Labs in February 2019.

Of the two proposals, Athens A sought to increase the gas limit and reduce the required roll size for baking from 10,000 tez to 8,000 tez. Athens B only sought to increase the gas limit. Athens A was voted with a Supermajority and was autonomously activated into the protocol in May 2019.

For a full list of changes, be sure to read this corresponding blog post from Nomadic Labs and reflections by Jacob Arluck, and the reference documentation.

Brest A (PtdRxBHv)

Brest A was the first proposed amendment rejected during the Exploration Period. Submitted in June 2019, it received only 0.35% of the votes during the Proposal Period. But as it had no competition, the system promoted it. The amendment was then rejected in the Exploration Period with only 0.26% of favorable votes. The 80% Supermajority was not reached, neither was the minimum Quorum required to validate it.

This proposal would have fixed a security breach linked to the rehashing push during the Athens protocol change. Moreover, it would have facilitated the amendment's invoice tracking. But the invoice for this proposal, 6,000 tez, was much higher than the usual cost.

Babylon (PsBABY5HQ)

Babylon was autonomously activated in October 2019.

The Babylon proposal was composed of two proposals made in July/August 2019: Babylon and Babylon 2. After receiving feedback on the first Babylon proposal, the core teams proposed a new tweaked version in the same proposal period.

Notable changes included a new variant of the consensus algorithm (Emmy+). There were new Michelson features and accounts rehaul to aid smart contract developers. The accounts rehaul enabled a clearer distinction between "tz" and "KT" addresses. Furthermore, there was a refinement of the quorum formula and the addition of the 5% threshold.

For a full list of changes, be sure to read the corresponding blog posts from Nomadic Labs, and Cryptium Labs (Metastate), and the reference documentation.

Carthage (PtCarthav)

Carthage was the first proposal to be rejected during the Proposal Period. Since the Babylon change, it now took a minimum of 5% approval to move to the Exploration Period and Carthage only obtained 3.5%.

The purpose of this proposal was to increase the gas limit per block and per operation by 30% to improve the accuracy of the existing formula used for calculating baking, attesting rewards, and to fix various minor issues.

Carthage 2.0 (PsCARTHAG)

Carthage 2.0 was autonomously activated in March 2020.

Notable changes included increasing the gas limit per block and per operation by 30%, improving the accuracy of the formula used to calculate baking and attesting rewards, as well as several minor improvements to Michelson. The main difference with Carthage was the new and more secure formula to calculate rewards.

For a full list of changes be sure to read the corresponding changelog and blog posts from Nomadic Labs and Cryptium Labs (Metastate). You may also check the reference documentation.

Delphi (PsDELPH1K)

Delphi was autonomously activated in November 2020.

Notable changes included improving the performance of the Michelson interpreter, improving gas costs by adjusting the gas model, reducing storage costs by 4 times, and various minor fixes.

For a full list of changes, be sure to read the corresponding changelog and blog post from Nomadic Labs. You may also check the reference documentation.

Edo (PtEdo2Zk)

Edo was autonomously activated in February 2021.

Edo added two major features to Tezos smart contracts:

  • Sapling[1] and BLS12-381[2] to enable privacy-preserving smart contracts

  • Tickets[3] for native on-chain permission and assets issuance.

Among other features, Edo also updated the Tezos amendment process by lowering period length to 5 cycles and by adding a 5th Adoption Period.

For more information check the reference documentation.

Florence (PsFLorena)

Florence was autonomously activated in May 2021.

Florence's notable bug fixes and improvements are the:

  • Increasing maximum operation size

  • Improved gas consumption for the execution of more complex smart contracts

  • Changing inter-contract calls to a depth-first search[4] ordering, as opposed to breadth-first search[5] ordering

  • The elimination of the test chain activation

Bakings Accounts[6] was also included in the feature set. However, ongoing testing uncovered some important and previously undocumented breaking changes in the proposal with Baking Accounts. Hence, the feature was postponed until a thorough audit of the functionality was completed or that an alternative implementation was produced. The version of Florence without Baking Accounts was considered a safer choice [7].

For more information, see the blog post from Nomadic Labs and Tarides, as well as the reference documentation.

Granada (PtGRANAD)

Granada was autonomously activated in August 2021.

Granada's main changes are:

  • Emmy*, a new consensus algorithm with reduced time between blocks (30s), and faster finality.

  • Liquidity Baking, increasing the liquidity of tez by minting some at every block into a CPMM (Constant Product Market Making smart-contract).

  • The reduction of gas consumption of smart contracts by a factor of three to six, through a number of performance improvements.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Hangzhou (PtHangz2)

Hanghzou was autonomously activated in December 2021.

Hangzhou's main changes are:

  • Timelock[8] encryption, a feature that helps smart contracts protect against Block Producer Extractable Value

  • Views, a new kind of entrypoints that gives easy access to some internal data to other smart contracts.

  • Caching of regularly accessed data, to lower the associated gas cost.

  • A global table of constants, where constant Michelson expressions can be registered and made available to all contracts.

  • Context flattening, an optimized rewrite of the protocol's database internals.

For more information, see the blog post from Marigold and the reference documentation.

Ithaca (Psithaca2)

Ithaca was autonomously activated in April 2022.

Along with numerous minor improvements, Ithaca contained two major updates to the protocol:

  • Tenderbake, a major update to the Tezos consensus algorithm, that brings fast deterministic finality to the Tezos protocol. It also includes important changes:

    • bakers now receive rewards depending on their current stake instead of the number of rolls they own
    • the minimum number of tokens required to be selected as a validator is reduced from 8,000 tez to 6,000 tez
    • a rework of baking and attestations rewards
    • a new security deposit mechanism requiring delegates to freeze 10% of their stake in advance, to obtain baking and attestation rights.
    • an increase of the number of attestation slots per block from 256 to 7,000
  • Precheck of operations: a new set of features that can be used by any Tezos shell, to avoid having to fully execute manager operations before gossiping them through the network

  • Adding approximately ten months to the liquidity baking sunset level.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Jakarta (PtJakart2)

Jakarta was autonomously activated in June 2022.

Jakarta's main changes are:

  • Transactional optimistic rollups (or TORU), an experimental implementation of optimistic rollups on Tezos. TORU provide a way to enable higher throughput (TPS) of transactions by moving their validation away from the main chain, to 'Layer 2'.

  • A new improved design for the integration of Sapling transactions into Smart Contracts. The Sapling protocol uses advanced cryptography to enable the protection of user's privacy and transparency with regard to regulators.

  • A redesign and renaming of the Liquidity Baking Escape Hatch mechanism, now called "Liquidity Baking Toggle Vote".

  • Various improvements to type safety and performance of the Michelson interpreter, including decreasing gas costs for parsing and unparsing scripts. Furthermore, Michelson now ignores annotations.

  • A new mechanism was introduced to explicitly track ownership of tickets in the protocol. This adds extra protection against attempts to forge tickets, and facilitates Layer 2 solutions that use tickets to represent assets that can be exchanged with the main chain.

  • The voting power of delegates is now defined directly by their stake expressed in mutez, and no more in terms of rolls. The minimal stake required to be assigned voting rights is kept at 6000 tez.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Kathmandu (PtKathman)

Kathmandu was autonomously activated in September 2022.

Kathmandu's main changes are:

  • Pipelined validation of manager operations, increasing throughput, without compromising the network’s safety. This ongoing project reduces the need to fully execute time-expensive operations (like smart contract calls), before they reach a baker, resulting in a faster propagation of new blocks and operations across the network.

  • Improved randomness with integration of Verifiable Delay Functions (VDF) into the protocol’s random seed generation, reinforcing the security of the rights allocation mechanism.

  • Event logging in Michelson smart contracts enabling DApps developers to send on-chain custom messages in order to trigger effects in off-chain applications (wallets, explorers, etc.).

  • A new operation for increasing paid storage of a smart contract allowing DApps developers to pay the storage fees on behalf of their users.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Lima (PtLimaPt)

Lima was autonomously activated in December 2022.

In addition to improvements to enable higher Layer 1 throughput, the main feature of Lima is:

  • Consensus keys: bakers can now create a dedicated key for signing blocks and consensus operations without changing the baker’s public address.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Mumbai (PtMumbai)

Mumbai was autonomously activated in March 2023.

Mumbai's main changes are:

  • Smart rollups: Tezos enshrined rollups are enabled and provide a powerful scaling solution allowing anyone to deploy a decentralized WebAssembly applications with dedicated computational and networking resources.
  • Minimal block time reduction from 30s to 15s.
  • Ticket transfers between user accounts.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Nairobi (PtNairob)

Nairobi was autonomously activated in June 2023.

Nairobi's main changes are:

  • Increased TPS thanks to a new gas model for signature verification.
  • Renaming endorsements to attestations to specify the behavior of these consensus operations.
  • Smart Rollups can now be aware of protocol updates happening on the L1.

For more information, see the blog post from Nomadic Labs and the reference documentation.

Oxford 2 (ProxfordY)

Oxford 2 was autonomously activated in February 2024, after a previous version was rejected in October 2024.

Oxford's main changes are:

  • Refinement of Tezos PoS, with changes to slashing and an automated auto-staking mechanism for bakers.
  • Re-activation of Timelocks with a new design that addresses security concerns.
  • Improvements of Smart Rollups, including the introduction of private Smart Rollups, and the simplification of the deployment of rollups.
  • Experimental (not activable) version of Adaptive Issuance, a new approach to tez issuance in the Tezos economic protocol, automatically adjusted based on the ratio of staked tez over the total supply.

For more information, see the blog post from Nomadic Labs and the reference documentation.

What have we learned so far?

In this chapter, we went through the past proposals' history and how and why they were approved or rejected.

In the next chapter, we will see the details of operation costs and various rewards calculations.

References

[1] https://z.cash/upgrade/sapling/

[2] https://electriccoin.co/blog/new-snark-curve/

[3] https://medium.com/tqtezos/tickets-on-tezos-part-1-a7cad8cc71cd

[4] https://en.wikipedia.org/wiki/Depth-first_search

[5] https://en.wikipedia.org/wiki/Breadth-first_search

[6] https://midl-dev.medium.com/tezos-in-favor-of-baking-accounts-3886effa370c

[7] https://research-development.nomadic-labs.com/baking-accounts-proposal-contains-unexpected-breaking-changes.html

[8] https://research-development.nomadic-labs.com/timelock-a-solution-to-minerblock-producer-extractable-value.html

https://wiki.tezosagora.org/learn/governance/past-tezos-amendments