Mina's Mesa Fork Leaves Every zkApp Verification Key Out of Date

Mina ran a hard fork called Mesa on 3 September, and the zero-knowledge applications built on it cannot process proof-authorized transactions until their developers rebuild a key. The upgrade moved protocol constants and circuit constraints. Proofs made against the verification keys that were on chain before the fork no longer verify. Mina is a layer-1 that uses zero-knowledge proofs to hold the chain at a fixed size instead of storing its full history, which puts those keys at the centre of how anything on it works. The chain itself restarted on schedule.

Eight hours, or three

The clock is not in dispute. Transactions submitted after 10:00 UTC on 3 September were not included. Block production stopped at 15:00. The Mesa packages went out at 16:30, and the first Mesa slot was filled at 18:00. Exchanges paused MINA deposits and withdrawals across the window while their order books kept trading, since a trade inside an exchange never touches the chain.

How long the network was actually down reads two ways. CryptoSlate describes an eight-hour pause, counting five hours of transaction-free blocks from 10:00 and then roughly three hours with no blocks at all. CryptoTicker sets the three-hour and eight-hour figures side by side and picks neither. The two counts measure different things and do not reconcile. Delegators earned nothing for as long as no filled blocks were produced.

The key that has to be rebuilt

A verification key is the on-chain fingerprint of an application's circuit, and every proof that application submits is checked against it. Mesa moved the constants those circuits compile against, so a stored key now describes something the chain does not recognise. CryptoSlate reported that a developer has to compile a fresh key with version 3.0 of o1js, Mina's application framework, then update the copy held on chain. No other located account names the version. The same outlet put a temporary ceiling of 12 zkApp transactions per block on the restarted network and said fallback authorization stays available, with no migration deadline set. Those details rest on one account.

Proving performance has been the busy edge of this work elsewhere. Zakura's libraries cut Zcash wallet proof times on mobile without any fork at all.

What the fork was for

Mesa bundles four Mina Improvement Proposals. Slot time drops to 90 seconds from three minutes. On-chain state fields go from 8 to 32. Event and action emission limits rise, and a single zkApp transaction may now carry more account updates. Cryptowisser adds a fifth item outside the proposals, automation for running future hard forks, and dates the devnet release to 20 August. Mina's own blog describes the package without the slot figure.

A planned restart is a different animal from an emergency one. Cronos restarted its chain with an exploit rolled back at the end of August, under no schedule anyone had agreed in advance. Mesa ran to a published timetable and hit every mark on it. The cost landed on the applications instead.

Nobody has counted the apps

Neither account gives a number. No located report says how many applications are affected, names one that went dark, or puts a figure on the value sitting behind a stale key. MINA traded at about $0.0724 on Friday afternoon, down under 1% on the day and up close to 16% on the week, on a market capitalisation near $94 million. That is a week's move, not a reaction to the fork. The measure worth watching is the count of keys that get replaced, and no one is publishing it.