§42.1 Function

CVS-01 defines verification for any action requiring shared custody. It does not invent a new signature scheme; it specifies how existing signatures are counted and bound.

§42.2 Threshold Classes

Two classes are defined. STANDARD = 3-of-5 (operational, registry edits, namespace changes). TREASURY = 5-of-7 (any movement of treasury assets). Both classes draw signers from the published custodian set for that class.

json
{
  "custody_classes": {
    "standard": { "t": 3, "n": 5, "purpose": "registry, namespace, executor config" },
    "treasury": { "t": 5, "n": 7, "purpose": "treasury movement, custodian rotation" }
  },
  "signature_alg": ["ed25519", "secp256k1"],
  "binding": "action_hash = sha256(canonical_json(action))"
}

§42.3 Verification Procedure

(1) Compute action_hash = sha256 of the canonical JSON serialization of the action. (2) Collect signatures, each one a tuple (custodian_id, sig_bytes, alg). (3) For each signature, verify sig_bytes against the published public key of custodian_id over action_hash. (4) Count distinct verified custodian_ids. (5) Accept iff count ≥ t for the action's class.

Duplicate custodian_ids count once. Unknown custodian_ids are discarded silently — they are not errors, they are noise.

§42.4 Custodian Rotation

Any custodian may be added, replaced, or removed by a RATIFIED proposal of class constitutional (RWC-01 §41.3). Rotation actions themselves require CVS-01 TREASURY verification of the outgoing set before the new set takes effect, ensuring continuous custody and no gap epoch.

§42.5 Final Principle

Custody is t distinct signatures over the canonical hash of the action. No more, no less. Cryptographic fantasy is forbidden.

“If verifying custody requires reading a whitepaper, the scheme has already failed.”