Hard Fork Automation

MIPs (Mina Improvement Proposals)
1

Hello Mina Community! :waving_hand:I’m Christian, a Protocol Engineer and Tech Lead at o1Labs. I’m here to share a new MIP proposal that’s part of the upcoming Mesa Upgrade.

This proposal introduces a fully automated hard fork mechanism for the Mina daemon. Instead of relying on manual steps and carefully timed coordination, the daemon would prepare migrated ledgers in advance and then generate the post-fork configuration automatically at the fork point. The goal is to make protocol upgrades smoother, less manual, and less error-prone.

What’s Changing?

  • Today, hard forks require manual steps and side-channel ledger distribution.

  • A new --hardfork-handling option will let operators choose between the current manual flow or the automated path.

  • In the automated mode, nodes continuously keep both old and migrated ledgers in sync.

  • At the point of hard fork, the node will automatically generate the required post-fork configuration and transition to the upgraded chain, seamlessly.

Why Does This Matter?

  • Simpler operations: Reduces complexity for node operators.

  • More secure: Removes side-channel distribution risks and reduces human error from manual upgrades.

  • Faster and more predictable timing: Resource-heavy migrations are done in advance, so the actual transition takes seconds rather than minutes.

  • More decentralized: Each node generates what it needs locally, no external dependencies.

How YOU Can Get Involved:

We’d love to hear your input and questions on this proposal:

  • Github

  • Mina Research (reply below)

Thanks all,
Christian

3 Likes
2

Hi everyone, we also collected some questions that we think may be raised:

  1. How do we know that nodes will generate the fork configuration correctly before the hard fork happens?
    Nodes running in automation mode will continuously maintain both the original and migrated ledgers while they operate.They will follow the same mechanism that we used in Berkeley hard fork which makes blockchain operate for 100 slots without transactions or SNARK work being included into blocks. This mechanism ensures that with almost absolute confidence, we don’t expect any forks at depth, and there is an established consensus over the last non-empty block. To bridge “almost absolute confidence” to full confidence, o1Labs team will employ monitoring at the time of HF transition with preparedness for manual intervention in the extremely unlikely case that consensus over the last non-empty block wasn’t automatically established, following the methods we prepared in anticipation of the Berkeley HF rollout. On top of that, the o1Labs team will run full dry runs and QA before the Mesa Upgrade to confirm that the configs are generated as expected.

  2. What are the “vesting parameter updates” mentioned in the proposal?
    When slot times are reduced, vesting schedules need to be adjusted so that the timing of token unlocks stays consistent in real-world time. These vesting/locked account updates don’t change balances or ownership — they simply make sure that accounts vest according to the same calendar as before, even though slots move faster. More details on this can be found in MIP-0006: Slot Reduction.

  3. Will block producers or validators need to keep running their nodes during the fork window even if they aren’t producing blocks or earning rewards?
    Yes, nodes should remain online until the chain stop slot. During the short “freeze” window, block producers won’t be including transactions, snark work, or coinbase fees — so they won’t earn rewards at that point. The purpose is to ensure all nodes converge on the same fork state. After the chain stop slot, most block producers can restart in the new network. To support any nodes that need to catch up, a few seed nodes and supporting nodes (including some run by o1Labs) will remain online in legacy mode to serve old data.

3

What’s the likely timing for stop_tx_end and slot_chain_end - 100 blocks like Berkeley?

Also the gap between slot_chain_end and when the new network starts slot delta. This is more applicable here if anyone tries to do this manually, how much time are they looking at? I can’t recall Berkeley now but want to say it was 12 hours?

Overall this seems a very welcome improvement. Presumably we can lower slot_delta as BPs don’t need to perform the actual upgrade during the downtime. Albeit if actually want manual migrations to be possible slot_delta can’t be a trivially small number.

4

I don’t think this should a MIP in the sense it should be voted on by token holders. While an important improvement for block producers rather than handling the process manually, this is entirely optional, if implemented, and is done so on only one implementation (ocaml node), and does not need to be implemented by others.

While there should be a consensus among block producers on this before implementing, this can happen outside of the formal MIP process.