This is a joint post from Nomadic Labs, Trilitech, and Functori.
Following the successful activation of the Tallinn protocol upgrade, we are happy to introduce our next upgrade proposal. Destination: Ushuaia!
As usual, the “true” name of the proposal is its hash:
PsUshuai9QapM5TGj1JpuVGkdxz5GykdnEvS6Rh8SUVrARvZLCY
The command to inject or upvote the proposal via the Octez client is:
octez-client submit proposals for <baking_key> PsUshuai9QapM5TGj1JpuVGkdxz5GykdnEvS6Rh8SUVrARvZLCY
Bakers can also inject and/or upvote protocol proposals using TezGov.
The Ushuaia proposal is designed to advance Tezos’ scalability while laying the groundwork for improved staking flexibility and post-quantum cryptographic future-proofing.
The main changes are:
- DAL bandwidth increase to 10 MB/s: A 15x increase in Data Availability Layer bandwidth, unlocking the next generation of high-volume Tezos applications.
- Dynamic DAL attestation lag: Layer 1 confirmation of DAL data becomes faster, benefiting features like fast withdrawals on Etherlink.
- Rollup-aligned PVM upgrades: Decouples activation of rollup-specific PVM features from Layer 1 protocol upgrades, enabling bakers to enable PVM features via rollup governance.
Three additional features are included behind feature flags (won’t activate on mainnet), and are intended for community testing and evaluation ahead of potential later mainnet activation:
- WASM PVM V6 (subject to Etherlink activation): Protocol-side groundwork required to prepare Etherlink’s storage migration to a faster backend.
- Enshrined liquid staking (testnet only): A trustless, protocol-native liquid staking mechanism (sTEZ) for Tezos.
- Quantum-resistant user keys (testnet only): A new ML-DSA-44 post-quantum signature scheme is added with tz5 accounts, representing an early first step towards quantum readiness.
Below, we expand on the proposed changes. For more technical details and additional minor changes, see the Ushuaia proposal’s changelog. Note that the proposal also introduces breaking changes, listed here.
DAL bandwidth increase to 10 MB/s
The Data Availability Layer’s bandwidth is upgraded from ~0.66 MB/s to 10 MB/s, a 15x increase, through a combination of software-level optimizations (batched and parallelized shard verification) and updated protocol parameters.
Security guarantees remain unchanged: the same attestation thresholds, baker reward structures, and redundancy factor apply. For most bakers (under ~2% of stake), existing hardware remains sufficient. Larger bakers are encouraged to review the updated hardware recommendations.
Why it matters:
- Enables higher L2 throughput: 10 MB/s bandwidth enables Etherlink (and soon Tezos X) to support hundreds of thousands of transactions per second without publication becoming a bottleneck.
- Unlocks more data-intensive dApps: Tezos becomes a more attractive destination for games, high-frequency DeFi, and other demanding on-chain systems.
- A differentiated position: A fully decentralized, protocol-native 10 MB/s data availability solution is a meaningful differentiator in the broader market.
For more details, see this post.
Dynamic DAL attestation lag
The DAL currently operates with a fixed attestation lag: a mandatory delay before new data can be confirmed available on Layer 1.
While this does not affect regular rollup transactions, certain features rely on Layer 1 confirmation of data. One example is fast withdrawals on Etherlink, where the attestation lag impacts the speed of withdrawals.
In practice, data propagation often happens faster than the fixed window assumes, adding unnecessary latency to the features that depend on it.
With Ushuaia, the attestation lag becomes dynamic: each baker publishes their attestation as soon as they observe the data on the DAL network, and the data is marked available once 66% of attesting power has confirmed it, regardless of elapsed time.
This reduces the expected attestation lag from 11 blocks (66 seconds) to 2–3 blocks (12–18 seconds) under normal network conditions. Security and reward distribution rules remain unchanged.
Why it matters:
- Network-responsive behavior: DAL attestation now aligns with actual network conditions rather than initial conservative parameters.
- Fast withdrawals become faster: Reduced lag directly improves UX for any application benefitting from fast asset movement between Layer 1 and Layer 2.
For more details, see this post.
Rollup-aligned PVM upgrades
Smart rollups on Tezos are secured by the WASM PVM (WebAssembly Proof-generating Virtual Machine). It defines the shared execution environment for all rollups and ensures rollup computation is deterministic and verifiable on Layer 1 through refutation games.
Hence, the PVM has to reflect changes and new features introduced in Etherlink kernel upgrades. Despite the close alignment with rollup development, new PVM features are currently activated through Layer 1 governance, which slows iteration on rollup infrastructure. Even with Etherlink’s separate governance mechanism, some features can’t activate until a full Layer 1 governance cycle has passed.
Ushuaia introduces a change that decouples PVM feature activation from Layer 1 governance proposals, instead enabling bakers to activate PVM features as part of Etherlink kernel governance. When bakers approve a kernel upgrade for Etherlink (and potentially, in the future, Tezos X), the new kernel can signal Layer 1 to enable a PVM feature flag.
Because activation happens at the PVM level, it applies to all WASM PVM rollups. That is, while Etherlink governance can now be used to enable PVM-specific features, these features benefit any rollup being originated on Tezos L1.
Why it matters:
- Faster iteration on rollup infrastructure: PVM improvements can ship when they are ready, instead of having to wait for a full Layer 1 governance cycle.
- Baker-aligned activation: Feature activation is governed by bakers through the existing Etherlink governance process, preserving decentralization guarantees.
WASM PVM V6: Paving the way for faster storage (subject to Etherlink activation)
To further scale Etherlink and, consequently, Tezos X throughput, we have built a new storage backend with better read/write performance.
The process of migrating to the new storage backend must happen inside the rollup’s proof-generating virtual machine (PVM) in order to remain deterministic and verifiable.
For the purpose of community testing, Ushuaia includes a new WASM PVM version to accommodate a dual-backend architecture required for migration. It won’t activate automatically, but can be enabled when ready via Etherlink kernel governance, as described above. This avoids requiring two full Layer 1 governance cycles.
Why it matters:
- Faster rollup execution (once migrated): Migrating to the new storage directly improves Etherlink and Tezos X throughput.
- Foundation for RISC-V: Migrating to the new storage is a prerequisite for WASM-to-RISC-V PVM morphing in a later protocol proposal.
Enshrined liquid staking (testnet only)
The Tezos protocol currently offers only direct staking (illiquid, but trustless), while third parties offer liquid staking (liquid, but introducing centralization and custodial risks). Ushuaia introduces a third option with enshrined liquid staking: a protocol-native mechanism that enables trustless liquid staking.
Users deposit XTZ into a protocol-recognized smart contract and receive sTEZ, an FA2.1 token whose value accrues relative to XTZ as staking rewards accumulate. The system is fully trustless (no admin key, no privileged operator) and stake is distributed automatically and fairly across participating bakers.
In Ushuaia, enshrined liquid staking is kept behind a feature flag on mainnet. It is available on testnet for community review and refinement, with potential mainnet activation targeted for Protocol V.
Why it matters:
- In-protocol optionality: Stakers who want liquidity no longer have to rely on centralized intermediaries.
- Governance-neutral: Liquid stake carries no voting power in on-chain governance, preserving the integrity of the amendment process.
- DeFi-ready: sTEZ uses a simple accrual model, making it straightforward to integrate into DeFi applications, DEXs, and on Layer 2.
Notes on the Ushuaia version (testnet scope):
The current sTEZ implementation is an initial version intended for community evaluation and co-design. Some aspects are placeholders or not yet fully implemented:
- Stake allocation: The current mechanism for allocating enshrined liquid stake across participating bakers is a placeholder. The final mechanism is intended to be co-designed with the community.
- Baker fees: Fees currently follow the values set by bakers at registration time. A globalized mechanism is planned, as outlined in the documentation.
- Slashing: Slashing is only partially implemented. In particular, slashing of redeemed (but unfinalized) funds is not yet supported.
- Quality-of-life features: Some UX improvements are not yet implemented, such as automatic finalization of existing redemption requests when initiating a new one.
- Protocol constants: sTEZ-related protocol constants and parameters, described in the feature’s documentation, are not yet fully defined or integrated.
Additional resources:
Quantum-resistant user keys (testnet only)
Advances in quantum computing pose a long-term risk to the cryptographic foundations of public blockchains. Early preparation carries few downsides, while acting late could have severe consequences for users who fail to migrate before a cryptographic break.
For this reason, a first concrete step towards quantum readiness for Tezos is now taken by integrating the post-quantum signature scheme ML-DSA-44 through a new account type, tz5.
In the Ushuaia proposal, tz5 accounts are kept behind a feature flag on mainnet, and will only be active on testnet. The purpose is to give wallets, custodians, and tool providers time to adapt before any real user adoption begins. User operations are fully supported, while baking support will follow later.
Why it matters:
- Future-proof security: The ecosystem can begin preparing for a post-quantum world before any urgency arises.
- Gradual migration: No disruption to existing accounts or signing schemes, which remain fully supported.
- Foundation for key rotation: A later step is to enable stateful addresses which allow for key rotation while preserving an account’s address and history.
For more details, see this post.
Next steps
We encourage developers, bakers, and ecosystem teams to test their applications and tools on the dedicated test network, Ushuaianet, which will be announced soon.
A release candidate for Octez v25.0, which contains the Ushuaia protocol as well as general improvements, will be published shortly.
The proposal period started on April 20 and ends on May 4. Don’t forget to vote! If adopted, the Ushuaia proposal would activate in late June or early July.
The changes in Ushuaia continue the trajectory set out in recent upgrades, advancing Tezos along the Tezos X roadmap while preserving core principles like decentralization, user autonomy, and long-term security.
We are happy to answer questions and receive feedback in the Tezos Blockchain Discord.
Let’s go to Ushuaia!