ZKsync EraVM Deprecation Begins With 6-Month Timeline

Steady attention without excessive speculation.

The announcement arrived through the official @zksync thread at 10:05 UTC. In it, the team said all Boojum and EraVM chains will “begin deprecating the legacy execution environment.” Alongside that plan, ZKsync is hardening EraVM today so the stack stays safe during the transition.

Inside the ZKsync EraVM Deprecation Plan

The core message is simple. Over six months, chains running on the EraVM and Boojum stack will move off the legacy execution environment. There is no single network-wide cutover date.

Instead, each operator coordinates with ZKsync and publishes its own user steps. In practice, that means Era, Abstract, Lens, Sophon, and others will announce separate timelines. So the ZKsync EraVM deprecation looks more like a staged rollout than a hard switch.

Notably, the team also framed the move as “Retiring EraVM.” The named successor is ZKsync Atlas, and the thread confirmed that Atlas chains are unaffected. According to ZKsync, the team built Atlas from the ground up for a tougher security landscape.

Why ZKsync Is Retiring EraVM

The reasoning centers on security. ZKsync said EraVM chains secure real value, and that “AI has collapsed the cost of finding vulnerabilities for every protocol.” As a result, the team wants to shrink the attack surface before problems appear.

EraVM is ZKsync’s ZK-optimized register machine, and it is not the EVM. Native contracts compile to EraVM bytecode, while Boojum proves the results. That custom stack is powerful, yet it is also large and complex to audit.

The track record shows why the team is cautious. A circuit soundness bug surfaced in 2023, an unprovable batch hit Abstract in May 2025, and the team paused the proof system in July 2025. Each incident sits inside that EraVM and Boojum surface.

By contrast, the destination stack aims to simplify things. ZKsync’s official docs already state that ZKsync OS will replace EraVM. The new design proves a RISC-V program with Airbender and plugs in execution environments, starting with the EVM.

What Changes for Users and Developers

For most holders, the immediate answer is reassuring. ZKsync said holders need no action now for funds kept directly in externally owned accounts, or EOAs. Those hold just keys and balances, so they do not need a contract rewrite.

Smart contract users face a different path. According to the thread, funds held through multisigs, smart accounts, DEXs, and lending markets will need action in the coming months. Each chain will finalize its own transition plan first.

For those who prefer to prepare early, ZKsync offered an optional step. Holders unsure they can track updates may move funds to an EOA now. Still, the team stressed that no deadline applies today.

Developers should watch one detail closely. ZKsync OS does not support EraVM or native EraVM account abstraction. So apps that rely on native AA must migrate, though the stack supports ERC-4337 as the replacement path.

The Hardening Package: 24-Hour Delay and EraBender

While the ZKsync EraVM deprecation runs in the background, the team is patching the current stack. The hardening package includes an Instant Upgrades framework and a policy to publish code three months after each upgrade.

In addition, ZKsync recommended that public EraVM chains raise their execution delay from three hours to 24 hours. That change gives operators more time to freeze a buggy or malicious batch before withdrawals settle. Notably, it reverses a 2025 reduction that had cut the delay to three hours.

The team is also building EraBender, which it describes as a second prover still in development. A second prover reduces the chance that a single bug lets an attacker steal funds. Meanwhile, ZKsync suggested independent verification nodes to add outside checks.

How Chain Operators Responded

Elastic Network operators moved quickly to calm users. Abstract said it is implementing the recommended measures and that users need to take no action. Lens said its patches are in place and reported no anomalous batches.

GRVT is a special case. Because it is a permissioned ZK chain, the 24-hour delay recommendation does not apply to it. GRVT told users no action is needed now, and said it will migrate on its own timeline toward Airbender.

So far, the operator posts do not contradict the security-upgrade claim. Instead, they narrow the warning that “your action may soon be required” to “not you, and not today.” That nuance softened the official hook.

Market Reaction and the ZK Token

The market response has been muted. On 4 September, CoinGecko showed the ZK token near $0.009414, up about 3.8% on the day, with volume around $8.98 million. Much of that green print came from 3 September, before the announcement.

On-chain value looks stable too. DefiLlama put ZKsync Era DeFi TVL near $15.43 million, up 2.93% on the day. L2BEAT measured total value secured at roughly $227.98 million, a gap driven by different methods rather than a same-day move.

Social engagement stayed low as well. About an hour after publishing, the root post had roughly 48 likes and 15,000 views. For now, sentiment reads calm and reassured rather than clearly bullish or bearish.

What Comes Next for ZKsync

Two pieces remain unresolved. Researchers could not independently retrieve the full blog post body, and no chain has published a firm deadline yet. So the exact meaning of “legacy execution environment” still needs precise confirmation.

For readers, the practical steps are clear enough today. Follow only @zksync, the ZKsync blog, and the @TheZKNation forum, since the team warned it will never DM users or ask them to migrate via a link. EOA holders can wait, while smart contract users should watch their chain’s plan.

The next milestones to track are Era’s own timeline and any governance vote tied to the hardening measures. As each chain publishes its steps, the shape of the ZKsync EraVM deprecation will come into focus. This article is analysis, not financial advice, so always do your own research before acting.