Mina's Mesa Upgrade Halted Transactions for Eight Hours and Left zkApps Needing New Keys

Mina's mainnet stopped processing transactions for roughly eight hours on 3 September as the layer-1 blockchain moved to its Mesa release, according to CryptoSlate.

Exchanges suspended MINA deposits and withdrawals during the switch, and applications already deployed on the network, known as zkApps, must install fresh verification keys before any proof-authorised activity can restart.

How the switchover unfolded

The halt came in two stages. For about five hours the chain kept producing blocks but carried no transactions. For roughly three hours after that it produced no blocks at all.

Mina reached its transaction cutoff at 10:00 UTC. Upgraded block producers then created empty blocks for 100 slots before block production stopped at 15:00 UTC.

Mina's official upgrade runbook lists those steps as done. It also shows the Mesa package was released at 16:30 UTC, with the opening Mesa slot following at 18:00 UTC. Upgrades to archive nodes and manually operated nodes were still in progress the following morning.

Mina asked exchanges to switch off deposits and withdrawals of MINA once the 10:00 UTC cutoff arrived, and to keep them off until Mesa was up and running. The first Mesa slot has since been completed, but each exchange chooses when to switch transfers back on.

Users may therefore see support return at different times on different platforms, whatever the state of the chain itself.

Faster slots, capped zkApp throughput

Mesa also changes the network's rhythm. According to Mina's feature explainer, slot time is halved from three minutes to 90 seconds.

The release temporarily caps zkApp transactions at 12 per block. Stress tests found memory spikes when developers tried removing the soft limit, so the cap stays in place for now.

Why zkApps went dark

The more demanding change falls on deployed applications. Mesa alters protocol constants and circuit constraints, so proofs generated against verification keys from before the upgrade no longer verify.

In a zero-knowledge system, a verification key is the public parameter the network uses to check that a proof was correctly produced by a particular program. When the underlying circuit rules change, old keys no longer fit, and proofs that depend on them fail.

Before a zkApp can handle new proof-authorised transactions again, its developer has to build a key that works with Mesa, using version 3.0 of o1js, and then replace the key held on-chain. CryptoSlate described this as a compatibility update rather than a permanent failure.

To keep accounts from being stranded during the migration, Mesa includes fallback rules. Where the permission governing an account's verification key required a proof, or was marked impossible, a signature is now accepted instead. Access permissions that required a proof are relaxed in the same way, while access permissions marked impossible stay locked.

Once a key update succeeds, the account's transaction version advances and its original permission rules return.

There is no fixed deadline. The fallback stays active until each zkApp updates its key.

That is a pragmatic way to let developers migrate at their own pace. It also means some accounts temporarily accept a signature where they previously required a proof, which shifts more weight onto the security of the keys that can sign.

What to watch

The near-term questions are practical:

• When individual exchanges re-enable MINA deposits and withdrawals.
• How quickly zkApp developers compile and publish Mesa-compatible keys.
• Whether the 12-transaction-per-block cap on zkApps is lifted once the memory issues are resolved.
• Completion of the outstanding archive-node and manual node upgrades.

The outage itself was planned and followed the published runbook. The longer-running effect will depend on how many zkApps remain on fallback permissions, and for how long.