Chapter Θʹ · genesis and the freeze

Deployment and freeze

STYX ships as immutable artifacts. Deployment is therefore a one-shot, genesis-time act: compile the five covenants, pin them into each other, issue the two assets, and verify everything before the first satoshi is locked - because nothing can be fixed after.

1Compilation and pinning

The covenants compile in dependency order - pot, stability, vault, issuer - and each later artifact receives the earlier ones' identities as compile-time parameters:

  1. The pot's two leaves compile against the OBOL and token asset ids; its taproot scriptHash becomes POT_SPK.
  2. The reserve compiles against POT_SPK and the asset ids; its scriptHash becomes STABILITY_SPK.
  3. The vault compiles against both flat pins plus the NUMS, the tapleaf constants, and the five oracle keys; its commitment Merkle root becomes VAULT_CMR.
  4. The issuer compiles against everything, including VAULT_CMR - it is the only artifact that carries another covenant's CMR.

The two assets are issued with no reissuance token: 100,000,000 OBOL into the pot and one identity token unit into the issuer. Neither can ever be reissued.

2The deploy preflight

The genesis configuration is baked into immutable artifacts, so its correctness is a trust assumption - the preflight turns as much of it as possible into asserted fact:

CheckWhy it is load-bearing
the five oracle x-only keys are pairwise distinct a duplicated key silently degrades 2-Byzantine tolerance to 1 - the quorum still verifies, the math is just wrong
NUMS equals the canonical BIP341 point 50929b74...803ac0 a "NUMS" with a known discrete log makes every covenant key-path spendable
OBOL_ID != ISSUER_TOKEN_ID the token gate and the debt asset must never alias
POT_SPK, STABILITY_SPK, VAULT_CMR each equal the actually compiled sibling a pin pointing at anything else redirects value flows at genesis, invisibly and forever
On a real deploy

The reference preflight compares pins against a same-process recompilation. A production multi-artifact deployment must compare them against the published on-chain scriptHashes and CMRs - the artifacts users will actually spend against - not against a local recompute that could differ from what was shipped.

3The freeze and the golden CMRs

The v1 covenant source is frozen (2026-07-03), after the economic pass and the final hardening round. The gate is the golden-CMR test: each covenant is compiled against a fixed set of dummy parameters so its CMR isolates the source logic; comments and witness values do not affect it, and any behavioral change flips it and fails the gate. The frozen roots:

CovenantFrozen CMR
reserve_repay52828127db4184834512b2e486e23c308f037e68deab8506fdcbb96e4b9e303f
pot_outflowd1e8412dcf1fedaec9879e9afcaa1d2b11046178268b601d17c324716b47c5c6
stability3ce24252af1248a0a6992868c324c8e928c55c4d043d85bf1cc4bbd8a1c65fd4
vault8ea44eac4c31403a0e35b75940225d5f8833114ae2a9ac8d9607be25ec291eb7
issuer145438e32272e966a1015593924210e7cc3951155ee2d904c81dee850a3b38f3

If these values ever change, the covenant was re-frozen and this specification needs a version bump - the CMRs are the spec's integrity check as much as the code's.

4Operational invariants

Three things the covenant assumes but cannot enforce, owed by whoever operates the deployment:

  • Exactly one pot UTXO and one reserve UTXO. Both addresses are public; anyone can create a second UTXO there. The covenants cannot consolidate fragments, so value sent to a fragment is operationally stranded until deliberately spent back in one piece. Builders must refuse to act when they observe more than one.
  • Keepers run on a schedule. POKE the issuer anchor toward the tip and REFRESH dormant healthy vaults - the ratchets only protect positions someone keeps fresh.
  • Oracle prices come from tight, aggregated feeds. The keeper's quote-subset freedom means the oracle spread is directly the owner-protection slack (chapter Εʹ).