The Ushuaia protocol upgrade will activate on Tezos mainnet at the end of cycle 1277, just before block 13857889 — current ETA is 29 June 2026 22:58 UTC. Please note that the exact time may drift by a few hours as bakers and node operators update their infrastructure ahead of the protocol upgrade.
Ushuaia continues Tezos’ progress along the Tezos X roadmap, with a focus on scalability, faster data availability, and laying the groundwork for staking flexibility and post-quantum security. To ensure a smooth transition, please review the changes below and test your setup ahead of mainnet activation.
What’s New in Ushuaia
Developed by Nomadic Labs, Trilitech and Functori, Ushuaia builds on the foundations of recent upgrades. The main active changes are:
-
DAL bandwidth increase to 10 MB/s: A ~15x increase (from ~0.66 MB/s) in Data Availability Layer bandwidth, achieved through batched and parallelized shard verification plus updated protocol parameters. Security guarantees (attestation thresholds, reward structure, redundancy factor) are unchanged.
-
Dynamic DAL attestation lag: DAL data is now marked available as soon as 66% of attesting power confirms it, rather than after a fixed window. This reduces the expected lag from ~11 blocks (66s) to ~2–3 blocks (12–18s) under normal conditions, speeding up features like fast withdrawals on Etherlink.
-
Rollup-aligned PVM upgrades: Decouples activation of rollup-specific PVM features from Layer 1 governance, letting bakers enable PVM features through Etherlink kernel governance.
Three further features ship behind feature flags and will not activate on mainnet: they are intended for community testing and evaluation ahead of potential later activation:
-
WASM PVM V6 (subject to Etherlink activation): Protocol-side groundwork for Etherlink’s storage migration to a faster backend, and a prerequisite for a future RISC-V migration.
-
Enshrined liquid staking — sTEZ (testnet only): A trustless, protocol-native liquid staking mechanism. Available on testnet for community review, with potential mainnet activation targeted for a later protocol.
-
Quantum-resistant user keys — tz5 (testnet only): A new ML-DSA-44 post-quantum signature scheme introduced via the tz5 account type — a first concrete step towards quantum readiness.
For full details, see the Ushuaia announcement and the protocol changelog.
Action items for bakers and node operators
To guarantee a seamless transition and prevent any potential network disruption, we encourage bakers and node operators to update their infrastructure well in advance of activation. You can use the checklist below as a quick reference for your upgrade preparations: the core step is upgrading to Octez v25.0, the release that adds support for Ushuaia (item 3).
1. Check updated hardware requirements
For most bakers (under ~2% of stake), existing hardware remains sufficient for a 10 MB/s DAL bandwidth. Larger bakers are encouraged to review the updated DAL hardware recommendations before activation.
2. Check potential breaking changes
Octez baker and node operators should be aware of the following breaking changes when preparing their infrastructure ahead of the upgrade.
a) Ubuntu APT repository renaming
Starting with Octez v25, the Octez APT repository names Ubuntu releases by their version number rather than by the adjective from their codenames:
-
ubuntu/jammybecomesubuntu/22.04. -
ubuntu/noblebecomesubuntu/24.04. -
ubuntu/26.04is newly supported.
If you have installed Octez v24 or earlier from the APT repository, apt-get update && apt-get upgrade will not upgrade your installation to v25 until you repoint the repository—it won’t report any available updates. You need to reset the release environment flag to your Ubuntu version number and re-add the repository, following the install instructions.
Note that Debian users are unaffected. See more details in the v25 release notes.
b) Remove the Adaptive Issuance toggle vote before upgrading
Octez v25 removes the --adaptive-issuance-vote CLI option and the adaptive_issuance_vote field from per_block_votes.json. Both were deprecated in v24, and they have no effect since the Paris protocol activated on mainnet.
If you are using a per_block_votes.json file and it still contains adaptive_issuance_vote, the v25.0 baker will reject it at startup. Don’t forget to remove that field before upgrading.
c) Changes to the Octez DAL node RPC server
Starting with Octez v25.0, the DAL node RPC server now binds by default to 127.0.0.1:10732 instead of 0.0.0.0:10732. Bakers and operators who need to expose the RPC interface publicly must explicitly pass --rpc-addr 0.0.0.0:10732 (or \[::\]:10732) on the command line or via their configuration files.
Note that a warning is now emitted, and a restrictive ACL is applied when the DAL node’s RPC server is bound to a non-loopback address, leaving only safe/read-only endpoints accessible. The ACL can be overridden per-bind-address via a new acl field in the DAL node config file, using the same policy syntax as the L1 node.
Please take some time to read carefully the breaking changes page and the v25.0 release notes for any further changes that might affect your setup.
3. Upgrade to Octez v25.0
Octez v25.0 adds protocol support for Ushuaia, and it is thus the minimal version required to keep baking through the protocol upgrade.
-
Release notes and update instructions: Version 25.0
-
Binaries and packages: Octez releases page
-
Announcement: Announcing Octez v25.0
4. Test ahead of mainnet activation
Bakers, node operators, and ecosystem teams are encouraged to test their infrastructure and tooling on the Ushuaianet and Bakingnet test networks. See teztnets.com for further information.
We are here to help
If you have questions or need support preparing for the upgrade, don’t hesitate to reach out to us on Tezos Discord.
Let’s go to Ushuaia!
