From 26c1a6477a26c0ec2a3b220191c10771eb6fde81 Mon Sep 17 00:00:00 2001 From: bdchatham Date: Fri, 28 Aug 2026 19:19:43 -0700 Subject: [PATCH] docs(registry): commit arctic-1 alongside pacific-1 and atlantic-2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit arctic-1 was excluded because it can be re-genesised. It can, but we control that and intend not to, and the exclusion cost more than the risk. Supplying the file from a deployment instead lets anyone who can edit that source point a run at a contract of their choosing, and the code-hash check cannot catch it: the check proves the address holds the code the file recorded, not that the code is ours. Committing removes that exposure and puts every address change through review. Two corrections to what the section claimed about a re-genesis. It does not break a run. Resolve returns "deploy" when the chain key does not match, with no error, so a run whose committed entries have gone stale deploys its own contracts — which is what every run did before this directory held a file. Recovery is a pull request here at whatever pace suits. What does not degrade quietly is a recorded address whose code has changed: Verify fails and the run stops at startup. It also omitted the requirement that makes committing work at all. The registry keys on genesisHash, so a profile that omits it matches nothing, and a run that omits it on a chain the registry describes already fails at startup with that explanation. Any profile reading a committed entry has to carry it. Co-Authored-By: Claude Opus 5 (1M context) --- registry/chains/README.md | 52 +++++++++++++++++++++++++-------------- 1 file changed, 33 insertions(+), 19 deletions(-) diff --git a/registry/chains/README.md b/registry/chains/README.md index 40ddf05..85dd0d2 100644 --- a/registry/chains/README.md +++ b/registry/chains/README.md @@ -63,25 +63,39 @@ recorded nowhere. ## Which chains belong here -Split by how long the chain lives, not by convenience. - -**Commit here: pacific-1 and atlantic-2.** They are never re-genesised, so a -recorded address stays true. Committing puts the address in a reviewed pull -request and in a signed image, next to the bindings that encode against it. - -**Supply by `--chain-file` instead: arctic-1, and every devnet.** arctic-1 is -re-genesised on a devnet cadence, and each re-genesis changes its genesis hash -and invalidates a committed entry. Recovering from that here means a sei-load -pull request, a CI build, and a hand-edited image pin in each cell — where the -three canary cells are pinned independently on purpose. A file the deployment -supplies recovers with one reconcile. - -The cost of supplying it is real and worth stating: anyone who can edit that -source can point a run at a contract of their choosing, and the code-hash check -cannot catch it — the check proves the address holds the code the *file* -recorded, not that the code is ours. The canary mounts a funded key, so the loss -is bounded by that key's balance. That bound is the reason this is acceptable for -arctic-1 and not for pacific-1. +Split by whether a recorded address stays true, not by what we call the chain. + +**Commit here: pacific-1, atlantic-2 and arctic-1.** A recorded address stays +true for as long as the chain does. Committing puts it in a reviewed pull request +and in a signed image, beside the bindings that encode against it. + +arctic-1 differs from the other two in one way. It is ours, so we can +re-genesise it. Committing it anyway is a decision rather than an oversight. We +control that re-genesis and intend not to do it, and the alternative costs more +than the risk. + +That alternative is supplying the file from a deployment. Anyone who can edit +that source then points a run at a contract of their choosing. The code-hash +check cannot catch it: the check proves the address holds the code the *file* +recorded, not that the code is ours. Committing removes that exposure. It also +puts every address change through review. + +A re-genesis changes the chain's genesis hash, and the committed entries stop +matching. A run then deploys its own contracts, which is what every run did +before this directory held a file. Recovery is therefore a pull request here, at +whatever pace suits, rather than an outage. + +One case does not degrade quietly. A recorded address whose code has changed +fails Verify, and the run stops at startup rather than binding something else. + +A profile that reads a committed entry has to name the chain's `genesisHash`. The +registry keys on it, so a profile that omits it matches nothing. A run that omits +it, on a chain the registry describes, fails at startup and says why. It does not +redeploy on every restart in silence. + +**Supply by `--chain-file` instead: a chain that outlives a run but not a +release.** The flag stays for that case, and for bootstrapping a chain before +anyone commits its file here. **Never commit an ephemeral chain's file.** It disappears after the run, so the entry could never verify again.