Mina Mesa upgrade pauses zkApps until keys updated
Mina’s Mesa hard fork on Sept. 3 invalidated verification keys for deployed zkApps, halting proof-authorized transactions until developers compile o1js 3.0 keys and update them on-chain.
On Sept. 3 Mina completed the Mesa hard fork, which invalidated verification keys used by deployed zero-knowledge applications (zkApps). The change paused proof-authorized transactions on mainnet until developers compile Mesa-compatible keys with the o1js 3.0 toolchain and write them on-chain.
The network paused transaction processing for about eight hours. Mina reached a 10:00 UTC cutoff for transactions; upgraded block producers produced empty blocks for roughly five hours before block production halted around 15:00 UTC. The Mesa upgrade package was released at 16:30 UTC and the first Mesa slot occurred at 18:00 UTC. Archive-node and some manual node upgrades remained in progress the following morning.
Exchanges were instructed to disable MINA deposits and withdrawals starting at the 10:00 UTC stop-transaction slot. Each exchange decides when to reopen transfers once its infrastructure confirms the network is operational.
Mesa changes core protocol parameters. Slot time was shortened from three minutes to 90 seconds. The upgrade temporarily caps zkApp transactions at 12 per block after stress testing showed memory spikes when the soft limit was removed.
Because protocol constants and circuit constraints changed, proofs generated before the upgrade no longer verify against the updated chain. Developers must compile new verification keys with o1js 3.0 and submit the updated keys on-chain for each deployed zkApp. Until a new key is recorded, any transaction type that relied on proof authorization remains paused for that account.
Mina described the update as an on-chain compatibility change rather than a permanent contract failure. During migration, access permissions that previously required a proof will accept signature authorization as a temporary fallback. Permissions explicitly set to ‘impossible’ remain locked and cannot be bypassed. After a successful key update, the account’s transaction version advances and its original verification-key permission rules are restored. There is no fixed deadline for the update.
Node operators and developers are being asked to upgrade their software and recompile verification keys where needed. The temporary 12-per-block limit and the shorter slot cadence will affect application throughput until further adjustments or additional stress testing change those limits.








