A Trust-Minimized Re-Genesis

Block time — how often a chain seals a new block — is one of the few settings baked into genesis that a running chain can’t change after it launches. If you ever did want to change it — say, drop it from two seconds to 500 milliseconds — there’s only one honest way to do it: stop the chain, and start a new one that picks up exactly where the old one left off.

That maneuver has a name — re-genesis — and it raises a question much scarier than block time. When the new chain boots, everyone’s balances are simply declared in its genesis. So how does anyone know those balances are the real ones? How do you know that whoever ran the migration didn’t quietly add a zero to their own account on the way through?

We built the whole thing on a live testbed and recorded it. This post is how it works — and, more importantly, how it’s built so that you don’t have to trust us to believe it.

A 60-second primer

If you already know what a state root is, skip ahead. If not, five ideas carry the whole post.

• Genesis is a chain’s first block — block zero. It’s not mined; it’s a file everyone agrees on that declares the starting state (who owns what, what the rules are). Every chain begins from one.
• State is the ledger: every account and its balance, plus the chain’s settings. It changes with every block.
• The state root is a single short fingerprint — a hash — of that entire state. Change one balance by one unit and the fingerprint changes completely. Every block header carries the state root, so the chain is constantly committing to “here is the exact ledger right now.”
• Validators are the known machines that run the network and take turns producing blocks. On a permissioned chain this set is small and identified.
• The authority set is which validators are currently in charge — and, crucially, it’s part of the state. The ledger itself records who the validators are.

Hold onto the third one. The state root is the hinge the whole design turns on.

What re-genesis actually is

Re-genesis is a deliberate, planned restart. You freeze the chain at a chosen block, take a snapshot of its state, and write that state into the genesis of a new chain that runs different rules. The new chain’s block zero is the old chain’s final ledger. Nothing is lost; only the rules change.

1. 1
   Haltthe chain stops at block #100 — a known, final, frozen ledger
2. 2
   Snapshotexport every balance, plus the state root — the ledger’s fingerprint
3. 3
   Sign≥2⁄3 of the validators sign the checkpoint: halt-hash · state-root
4. 4
   Verifyrecompute the root, check the signatures — tampered state or too few signers → refuse
5. 5
   Relaunchnew genesis boots from the inherited state at 500 ms — balances carry over exactly

Stages 1, 2, and 5 are mechanical — stop, copy, boot. The entire trust problem lives in stages 3 and 4. Get those right and re-genesis is safe. Skip them and you’ve just asked the world to trust a spreadsheet.

The problem: a snapshot is just a file

Here’s the naive version. Halt the chain, dump the state to a file, paste it into the new genesis, launch. It works perfectly — and it’s completely unsafe.

A snapshot is just a file. Between “export” and “relaunch” it passes through someone’s hands. That someone could open it, change one number, and hand it on. The new chain would boot happily from the altered ledger, because a fresh chain has no memory of what the balances should have been. Everyone would have to simply trust that the file wasn’t touched.

For a chain that’s supposed to remove middlemen, “trust the person who ran the migration” is the wrong answer. So we need two checks: one that makes tampering detectable, and one that makes the honest snapshot authoritative.

Check 1 — the state root catches any tampering

This is where the fingerprint earns its keep. The old chain already committed to its exact ledger: block #100’s header contains the state root. In our run that root was 0xacd8…6fae.

So the new chain doesn’t have to trust the snapshot file. It re-computes the root from the file itself and compares. If the snapshot is honest, the numbers match. If anyone changed even a single balance by a single unit, the recomputed fingerprint is wildly different and the mismatch is obvious.

We tested exactly this: take the verified snapshot, flip one byte in one balance, and run it back through. The verifier refuses.

Notice what this check does not need: it doesn’t need to trust anyone. It’s pure arithmetic. Re-hash, compare. This part is genuinely trustless.

Check 2 — but who says that’s the real root?

Check 1 proves the snapshot matches a root. It doesn’t prove that root is the right one. A dishonest operator could build a fake ledger, hash it, and present a matching fake root. The recompute would pass — it’s internally consistent — it’s just not the real chain.

So the real root has to come from an authority you already trust. On this chain, that authority is the validator set. At the halt, the validators sign a small checkpoint: the halt block’s hash bound together with its state root. The new chain accepts the root only if enough of them signed it.

How many is enough? The same threshold the chain already runs on: more than two-thirds. That’s not an arbitrary number — it’s the exact honest-majority assumption the chain’s finality already depends on, block after block. If you trust the chain to produce blocks at all, you already trust two-thirds of its validators to be honest. Re-genesis asks for nothing more.

And the list of which validators count isn’t taken on faith either — remember the authority set lives in the state. So we read the valid signers straight out of the snapshot that Check 1 already proved honest. The two checks lock into each other.

In our three-validator run, Alice and Bob sign — two of three, which clears the bar. Then we show the failure mode on purpose: a checkpoint carrying only one signature is rejected, because one of three is below two-thirds. The threshold isn’t decoration; it’s enforced.

The run, end to end

With both checks in place, the migration itself is almost anticlimactic — which is the point. Halt the two-second chain at #100 and take the snapshot:

Then build the new genesis from the verified snapshot — same balances, same validators, one changed rule: a 500-millisecond block time. Boot it, and confirm every account arrives with the balance it had at #100.

That’s the full arc: a running chain, stopped, verified, and relaunched under new rules with its ledger provably intact. If you’d rather watch it uncut, the complete recording is here.

So is this trustless?

No — and it’s worth being precise about why, because the honest answer is more useful than a slogan.

Check 1 is trustless. Tampering is caught by arithmetic; no one has to be believed. Check 2 is trust-minimized. Deciding which root is legitimate rests on an honest two-thirds of the validator set. If two-thirds of them colluded, they could sign a false root — but two-thirds colluding could already rewrite the live chain, so re-genesis adds no new trust. It inherits exactly the assumption the chain already makes.

For a permissioned chain, that’s the right bar: the migration is as trustworthy as the chain itself, no more and no less. The word for that is trust-minimized, not trustless — and the difference matters.

• ◇Validity proofThe sequel
  trust only math

  A zk proof that the new genesis is the correct continuation of the old chain. Even a fully malicious validator set can’t forge it. Genuinely trustless — and the subject of the next post.

• ✓Signed checkpointThis post
  trust an honest ⅔ of validators

  Recompute the root so the data can’t be tampered with, then require ⅔ of the old validators to sign it. That’s the same honest-supermajority the chain already runs on — no new trust. Trust-minimized.

• ✗Copy & hopeNaive
  trust whoever ran the migration

  Just carry the state over and relaunch. Anyone handling the snapshot could quietly edit a balance and no one could tell. Too much trust in one party.

The frontier: removing trust in our own validators

There’s one rung left to climb. What if you didn’t have to trust the validators at all — not even a two-thirds majority?

That’s what a validity proof buys you. Instead of validators attesting that the new genesis correctly continues the old chain, you attach a zero-knowledge proof that it does — a compact piece of cryptography that anyone can check in milliseconds and that not even a fully malicious validator set could forge. The trust in the operators drops to zero; all that remains is trust in the math.

That’s a genuinely harder build, and it’s the subject of the next post. For now, the result stands on its own: we halted a live chain, changed a rule that’s supposed to be unchangeable, and relaunched it with its entire ledger provably carried over — without asking anyone to trust the people who ran the migration.

That’s re-genesis. It’s how a chain can evolve its own rules without ever asking its users for a leap of faith.