BOOK III — The System of the Domain

Here the treatise descends from the general science to the particular machine, and asks what, concretely, should change in the CreateDomain instruction.

Proposition 11 (The Dissolution). The custody tension is not a dilemma to be endured but an indirection to be removed.

The custody problem frames an irreconcilable choice: a cold multisig postmaster or a hot automated key, never both, because authorising a domain requires the postmaster’s signature and automation therefore requires the postmaster’s key online. But that requirement is the indirection itself. Make authorisation proof-carrying rather than signature-carrying (Book II), and the postmaster’s signature drops out of the authorise path entirely. The postmaster — now safely a cold multisig — is demoted to governance: it curates the accepted root/verifier/allowlist keys, adjudicates fraud proofs, and holds the emergency deactivation lever. These are exactly the rare, high-value, human-paced decisions a multisig is good at, and never the per-domain drudgery that forced the key to go hot. The tension does not need resolving; it needs deleting.

Proposition 12 (The Concrete Path). A staged construction, coldest rung first.

1. Split the instruction. Introduce a new on-chain path — call it AuthorizeDomainByProof — beside today’s postmaster-signed CreateDomain. The old path remains for hand-run and edge cases; the new path carries a witness and requires no postmaster signature. This is an append, not a change, to the on-chain ABI (respecting the model’s ABI-stability rule and the error enum’s append-only discipline).
2. Build the DNSSEC shadow first (Prop. 4). It is the coldest rung and matches the running example. The Verifier gains an Ed25519 RRSIG-chain checker validating root → TLD → domain → TXT, with the root KSK stored in the post-office account and rotated by the (now governance-only) postmaster.
3. Keep the verification service — but change its job. It stops being the holder of a hot postmaster key and becomes a witness-gatherer: it fetches the DNSSEC chain (or, for unsigned zones, drives a Prop. 5 quorum or Prop. 7 zk proof) and assembles the instruction, which anyone may then submit and pay for — because the proof, not the submitter, is the authority. The service’s most dangerous property (a hot postmaster key on an internet-facing host) simply ceases to exist.
4. Adopt the bonded Constitution (Prop. 10) for the residue. Unsigned zones, and the separate worry about relaying authorities, have no witness; give them the falsifiable-bond treatment, seeded from the existing “reputation or stake” open question.

Proposition 13 (The Blast Radius, recomputed). The prize, measured.

Before: one hot key = {authorize, deactivate, sweep, retune} over the whole network. After Prop. 12: the authorise power is carried by witnesses anyone can verify and no one need hold hot; the deactivate power is already gated by a 7-day timelock; and sweep and retune live only behind the cold multisig. The Def.-X blast radius of any online key falls from the network to nothing that isn’t independently checkable — which is the whole game.