NIST finalized the algorithm part years ago — FIPS 204 made Dilithium a standard, and NIST's transition guidance (https://csrc.nist.gov/pubs/ir/8547/ipd) now tells every product to plan the move. The algorithm was never the hard part. Everything downstream of it is.
Consider this the flight checklist we wish every chain ran before swapping signatures on a network that already has users.
The six pits
- Canonical encoding. Every signed payload sits on an encoding that wallets, indexers and bridges quietly assumed. Change the scheme and you re-negotiate that assumption ecosystem-wide.
- Replay protection & domain separation. Old and new signatures must coexist without opening a gap someone can replay through.
- Wallet & signer semantics. Key rotation means migrating keys users control — with no snapshot to roll back to.
- Transport & hardware. HSMs, firmware and embedded signers that cannot be patched overnight, in devices you do not own.
- The next migration. Whatever you ship today will itself need replacing. If migration hurts now, it compounds.
- Retirement semantics — the pit our community found for us: when algorithm A must be disabled, can funds still migrate and keys still rotate out of it? (Credit to @QbtcTech, who added this to our checklist within minutes of reading it.)
The pre-flight checklist
| Pit | Test to run before you ship | Our genesis answer |
|---|---|---|
| Encoding | Do two independent implementations decode the same signed payload byte-for-byte? | Frozen with the scheme, before any user key exists |
| Replay | Can a message valid under the old scheme be re-presented under the new one? | One scheme at genesis — no dual-scheme window |
| Wallet semantics | Does rotation require a migration of keys users hold? | No legacy user keys — rotation happens before launch |
| Transport & hardware | Can every signer in the path be patched, or do some predate you? | Signers designed against the frozen scheme |
| Next migration | Is today's choice itself replaceable without repeating all of the above? | Retirement checklist maintained from day one |
| Retirement | When the algorithm is deprecated, what happens to funds in flight? | Explicit answer required before mainnet, not after |
Why the consensus shape matters here
On a round-based BFT chain, every signed vote is part of the migration surface (see the CometBFT round steps: Propose → Prevote → Precommit). On our turn-based consensus there is no voting loop to preserve — the surface shrinks to block and transaction signatures. That is the structural argument behind our earlier piece on consensus shape.
Honest status
MSG Chain is not launched — mainnet is No-Go until an official announcement says otherwise. The checklist above is run against our local build and its evidence chain today; we present it as a method, not a completed prophecy.
Questions for the community
- Which pit have we still missed? (The list grew once already because a reader pushed back.)
- What is your experience of the dual-scheme window — survivable, or where migrations go to die?
- Should "retirement semantics" be a required section in every chain's documentation, like a license file?
Pressure-test it at qa.msgchain.org · mechanics at https://msgchain.org/whitepaper · argue live on Telegram: https://t.me/+OrceJ-S4iJIxMzU1
Follow @msgchain — we publish the checklists, credit the critics, and mark our own boundaries in the open.
Top comments (0)