The Mina Mesa upgrade stopped transaction processing for about eight hours on September 3 as the layer-1 blockchain shifted mainnet to its Mesa release. Exchanges suspended MINA transfers, while deployed zkApps now need new verification keys before they can resume proof-authorized activity.
The process split into five hours when blocks continued without transactions and roughly three hours when the network produced no blocks. Mina reached its 10:00 UTC transaction cutoff, and upgraded block producers made empty blocks for 100 slots before block production halted at 15:00 UTC.
The official upgrade runbook now marks those milestones as completed. It also records the Mesa package release at 16:30 UTC and the first Mesa slot at 18:00 UTC as completed. Archive-node and manual node upgrades remained in progress this morning.
Mina instructed exchanges to disable MINA deposits and withdrawals from the 10:00 UTC stop-transaction slot until the Mesa network became operational. The first Mesa slot has since completed, although each exchange controls when its transfer support resumes.
Mina Mesa upgrade cuts slot times
The Mina Mesa upgrade also changes the network’s operating cadence. According to Mina’s feature explainer, the release halves slot time from three minutes to 90 seconds. It temporarily limits zkApp transactions to 12 per block after stress tests found memory spikes when developers tested removing the soft limit.
The harder compatibility requirement falls on deployed zkApps. Mesa changes protocol constants and circuit constraints, so proofs made against pre-upgrade verification keys no longer verify. A zkApp cannot process new proof-authorized transactions until its developer compiles a Mesa-compatible key with o1js 3.0 and updates the key stored on-chain.
This is an on-chain compatibility update, not a permanent failure of the deployed contract. Once the new key is recorded, the zkApp can again submit proof-authorized transactions under Mesa, subject to its restored permission rules.
Mina’s migration path temporarily lets verification-key permissions set to proof or impossible fall back to signature authorization. An access permission set to proof receives the same fallback, but an access permission set to impossible remains locked. After a successful key update, the account’s transaction version advances and its original verification-key permission rules return.
There is no fixed migration deadline: the fallback remains active until a zkApp updates its key. Until then, proof-authorized activity remains paused even though the chain has resumed.
