ZKsync co-sponsors SODA's 2026 "Tokenization at Investment Banks" Report
ZKsync co-sponsored SODA's 2026 "Tokenization at Investment Banks" report, surveying 16 of the world's largest sell-side institutions on wholesale tokenization.
ZKsync Blog > Hardening EraVM: New Security ...
Published Sep 4, 2026
Hardening EraVM: New Security Measures and the Transition Ahead
TL;DR
- Today we are announcing five security measures for EraVM chains. Some are underway, some require chain-operator adoption, and EraBender remains subject to testing, audit, and production readiness
- Within the next six months, EraVM chains will begin a transition: the EraVM execution environment is going to be retired
- Whether you need to act: funds in regular wallets (EOAs) require nothing at this time; funds in smart contracts will require action, with exact steps and dates shared in the coming weeks
Today we are announcing new security measures for ZKsync chains running EraVM:
- Longer Execution Delay
- Independent Verification Nodes
- Delayed Publication of Era Code
- Security Council Instant Upgrades Enacted
- A Second Proving System
ZK chains running this software must decide on their own whether to adopt some of these changes, such as the longer execution delay and independent verification nodes, but we are strongly recommending all of them.
Within the next six months, chains running EraVM will begin a transition: the EraVM execution environment is going to be retired. No action is required at this time for funds held directly in regular wallets (EOAs). Funds held in smart contracts, such as multisigs, smart accounts, or deposits in onchain protocols such as DEXs and lending markets, will require action, and exact steps and dates will be published in the coming weeks on our official channels: @zksync on X, the ZKsync blog, and the ZK Nation forum. Users who wish to prepare can move funds held in smart contracts they control to an EOA now.
If your funds are held by an application or exchange rather than in a wallet or contract you control yourself, no action is needed from you at this time; follow that team's official channels for any steps. Chains coordinating their transition directly with ZKsync, including permissioned chains such as GRVT, will communicate any required steps to their users directly.
The EraVM transition described above does not apply to ZK chains running Atlas. Atlas chains use a separate architecture designed with these security considerations in mind and remain under active development.
Why now
AI has changed the cybersecurity landscape to the point where practices we relied on for years are no longer sufficient. Google fixed more security bugs in its last two Chrome releases than in the previous twenty-three combined. Those bugs were always there. It's just that the cost of finding them changed.
Permissionless blockchain protocols are exposed to even higher risk. The properties that make them worth using are the same ones that make them worth attacking: public code, open access, and irreversible settlement. Anyone can feed code to an agent, have it craft an exploit, test it, and even execute autonomously.
The ZKsync Security Council (ZKSC) has published a record of the Instant Upgraes executed on EraVM chains, and will be reporting each one classified under the new framework described in section 4 below. Note that when it comes to disclosing instant upgrades, the ZKSC will inform the community of when they occur but will withhold any details that they deem a security risk.
EraVM is a widely used protocol and continues to secure material value. As the security of our chains and partners is our top priority, we are implementing the following security features to harden EraVM chains against the growing risks of AI-led attacks:
1. Longer execution delay
In March 2023, with the Alpha release of ZKsync Era, we introduced the execution delay. This mechanism enforces a minimum period during which blocks must remain settled onchain before they reach finalization and the state becomes irreversible (e.g., withdrawals may be claimed on Ethereum mainnet).
Today we recommend that public EraVM chains increase their execution delay from 3 hours to 24 hours. This provides additional time to detect and respond to a potential exploit before finalization. A proposal related to this recommendation is expected to be submitted onchain in the coming days.
This is not change we are forcing on anyone. It is up to each and every ZK chain to decide for themselves, and some will weigh the cost to their users differently. We are recommending it to all public chains, as short delays limit what anyone can do in response to an attack. Twenty-four hours is in line with other major chains and we think it is a reasonable trade for the security it buys.
Permissioned deployments operate under a different access model and this recommendation is not directed at them.
2. Independent verification nodes
We are working with every active EraVM chain to run an independent second node that confirms each executed batch.
The point is to change what an attack requires. Without a verification node, an attacker exploiting a flaw in the ZK circuits would need to compromise the production environment and swap the sequencer for a modified build.
With a second independent node required to confirm every batch, they would need to compromise two or more independently hosted infrastructures at the same time. That is a materially different and harder attack surface to exploit.
3. Delayed publication of Era code
Access to source code is one of the largest factors in how quickly an attack can be found. Current models are good at spotting logical gaps in code they can read, and much weaker against software they cannot.
That pits two of our commitments against each other. We believe in open source and we are committed to it. However being open source today also hands attackers a disproportionate advantage on frozen code.
Under the new policy, covered Era protocol code will be published three months after the corresponding upgrade ships. That gives the team room to resolve an issue quickly and then build the complete fix properly, without racing agents that are reading the commits as they land.
This does not mean unsupervised upgrades. Independent auditors will keep continuous access to the source, including so they can confirm the authenticity and reproducibility of the verification keys running in production.
The bug bounty program stays open, and its dynamics change: researchers will be working against published code that may not match what is running. That is closer to how bug bounties work in most other industries than to how ours has worked until now.
4. Emergency Upgrades are now Instant Upgrades
The governance framework provides an expedited process for security-sensitive fixes where public disclosure or the standard timelock could increase risk. Public discussion and a timelock would disclose the vulnerability before the fix is deployed, and in other cases the time the process takes is itself the risk.
On 24 August the Token Assembly approved GAP-5, a ZKSC proposal that renames Emergency Upgrades to Instant Upgrades and sorts each one into two categories:
- A Security Patch is a vulnerability fixed before anyone exploited it, with no evidence of active exploitation at the time the upgrade is approved.
- An Emergency Response is a reaction to an active security event. The authority of the Emergency Upgrade Board, the approval thresholds and the execution procedures are unchanged.
The distinction matters because both have been reported under one label. A risk team reading "Emergency Upgrade" had no way to tell whether the protocol was under attack or had fixed something before anyone found it prior to this update.
Under GAP-5 each Instant Upgrade carries a notice on the ZK Nation forums after it ships, covering practical impact: deposits, withdrawals, finalization, anything requiring action, and a Report will be published provided the Security Council believes further disclosure doesn’t create a security risk.
Expect Instant Upgrades more frequently than Emergency Upgrades in the past. This is a proactive measure to find and fix any bugs in the system prior to anyone exploiting them, hardening overall security for every chain reliant on EraVM.
5. A second proving system
Matter Labs is developing EraBender, an Airbender-based prover for the EraVM state transition function, as a potential second proving system. Subject to testing, audit, and production-readiness requirements, we intend to deploy it gradually alongside Boojum.
EraVM chains will keep settling real value through the transition, and every batch settled needs to be safe. EraBender is built on Airbender, the same proving technology powering Atlas. This addition will harden the security systems of EraVM as an exploitable flaw would have to exist in two independently built proving systems at the same time.
EraBender will be rolled out gradually and we will give updates as we have them.
Looking after EraVM
When EraVM was built in 2020, it was a highly custom stack: its own virtual machine, compiler, protocol, and proving system. That was the only way to bring a functional zkEVM to production on Ethereum, and in 2023 we were the first to do it.
Since then we've learned a lot and have built EraVM's successor, ZKsync Atlas. Atlas runs EVM natively, follows Ethereum's protocol rules, works with mainstream compilers, and runs on a proving system that is under active development. Atlas is the future of ZKsync, and all new protocol development happens there.
For EraVM, that means security maintenance: chains running it keep receiving security work through the transition, while new protocol capabilities ship on Atlas. Where we have publicly committed to building something for EraVM that no longer clears that bar, we will re-scope it in the open rather than leave it standing.
This maintenance phase runs through the transition announced at the top of this post. Each chain running EraVM will set and communicate its own path on its own timeline. We are designing the transition to be as smooth as possible, and the guidance on funds is the same everywhere: EOAs do not require any action at this time, and exact steps and dates for funds held in smart contracts will be published in the coming weeks.
That work is ongoing, not a one-time hardening. Beyond the five measures above, we are also adding new monitoring layers, conducting continuous internal security reviews , building tooling to assert safety properties, and updating our own processes to keep pace with how security research is changing.
We will not always publish at the moment we act. Technical details may be temporarily withheld where disclosure creates a material security risk, subject to applicable legal, contractual, and governance requirements. Operational notices and later reports will follow the applicable governance framework.
None of this makes EraVM risk-free. No security work does that. What these security updates do is harden EraVM and shorten the distance between a problem appearing and our being able to act on it.
Share the article
More from ZKsyncView all
Prividium Now Extends to Hyperledger Besu
Matter Labs brings Prividium to Hyperledger Besu: institutions gain ZK-proven privacy and Ethereum interoperability without replacing existing infrastructure.
Build Sovereign Infrastructure. Then Ask If It Can Talk to Anyone.
When Washington forced Anthropic to cut off its top models worldwide, banks relearned an old lesson, and why sovereignty and interoperability stop being a trade-off.