TYPE 0x0302 · COVENANT FAMILY

VAULT_LOCK

Two-path vault with recovery key and hot key. The recovery key (cold sweep) can sign immediately with no delay. The hot key requires a CSV delay before spending is valid. Combines custody tiering and time-delayed authorization in a single block.

Covenant Non-Invertible

Ladder Diagram

Fields

Field	Data Type	Size	Side	Description
hot_delay	NUMERIC	1-4 B	Conditions	Number of blocks the hot key path must wait (passed to `CheckSequence` as a BIP-68 sequence value, with the same uint32 range guard as CSV).
recovery_pubkey	PUBKEY	32-33 B	Witness	Cold-recovery pubkey (witness PUBKEY at index 0). Must be revealed even if the spend uses the hot key, because both keys are folded into the rung leaf via `merkle_pub_key` and the leaf reconstruction needs both.
hot_pubkey	PUBKEY	32-33 B	Witness	Hot-spend pubkey (witness PUBKEY at index 1). Always revealed alongside the recovery pubkey.
signature	SIGNATURE	64-65 B	Witness	Single Schnorr signature (size strictly enforced 64-65 B — no SCHEME field, ECDSA/PQ rejected). The evaluator tries it against the recovery key first, then the hot key, and selects the path by which key validates.

Both pubkeys are revealed in the witness because PubkeyCountForBlock(VAULT_LOCK) = 2 — the rung leaf binds both keys, so spending requires presenting both to satisfy MLSC-proof-level reconstruction. No key fields appear in conditions.

Wire Format Breakdown

0x0302 0 1 NUMERIC · 3-6B Conditions ≈ 7-10 bytes

0x0302 0 3 PUBKEY · 35B (recovery) PUBKEY · 35B (hot) SIGNATURE · 66-67B Witness ≈ 140 bytes

Total ≈ 150 bytes

Evaluation Logic

1.Collect both witness PUBKEY fields, the SIGNATURE, and the conditions NUMERIC (hot_delay). If fewer than 2 PUBKEYs, or SIGNATURE/NUMERIC missing → ERROR

2.Strict-size check on the SIGNATURE: must be 64-65 B (Schnorr range). VAULT_LOCK has no SCHEME field, so ECDSA's 8-72 B and PQ scheme sizes are rejected. Out of range → ERROR

3.Decode hot_delay from the NUMERIC. If undecodable → ERROR

4.Try the recovery key (witness PUBKEY index 0): call VerifySigWithScheme(recovery_pk, sig, scheme=null). If valid → SATISFIED immediately (cold sweep, no delay). If VerifySigWithScheme returns ERROR → propagate ERROR.

5.Otherwise try the hot key (witness PUBKEY index 1) the same way. If the sig validates: range-check hot_delay ∈ [0, 0xFFFFFFFF] — out of range → UNSATISFIED (regression `1a23fa32c8`: silent uint32 truncation). Then call CheckSequence(uint32_t(hot_delay)); fails → UNSATISFIED; passes → SATISFIED

6.Neither key validated the signature → UNSATISFIED

Return Values

Condition	Result
Fewer than 2 PUBKEYs in witness, or SIGNATURE/NUMERIC missing	ERROR
SIGNATURE size outside 64-65 B (Schnorr range)	ERROR
`hot_delay` NUMERIC undecodable	ERROR
Recovery-key sig validates	SATISFIED
Hot-key sig validates and `CheckSequence(hot_delay)` passes	SATISFIED
Hot-key sig validates but `hot_delay` > 0xFFFFFFFF or negative	UNSATISFIED
Hot-key sig validates but `CheckSequence` fails (delay not met)	UNSATISFIED
Neither key validates the signature	UNSATISFIED

JSON Wire Format

Conditions (recovery + hot key with 144-block delay)

{
  "type": "VAULT_LOCK",
  "inverted": false,
  "fields": [
    { "type": "NUMERIC", "value": 144 }
  ]
}

Witness (hot-key spend — both pubkeys revealed)

{
  "type": "VAULT_LOCK",
  "fields": [
    { "type": "PUBKEY", "value": "03aabb... recovery_pubkey ..." },
    { "type": "PUBKEY", "value": "03ccdd... hot_pubkey ..." },
    { "type": "SIGNATURE", "value": "... 64-65 B Schnorr sig ..." }
  ]
}

The witness layout is identical for a recovery-key spend — only the SIGNATURE differs. Both pubkeys must be present so the rung leaf can be reconstructed.

The 144-block delay (~1 day) gives the cold key holder time to detect unauthorized hot key usage and sweep funds using the recovery path before the hot spend confirms.

Worked Example

Vault with 144-block hot delay

UTXO locked with VAULT_LOCK: recovery_commit + hot_commit + delay=144

Scenario A (emergency recovery): Owner detects compromise, signs with cold key

Signature verifies against recovery key → SATISFIED immediately

Scenario B (normal spend): Hot key signs, tx has nSequence ≥ 144

Signature verifies against hot key, CheckSequence(144) passes → SATISFIED

Scenario C (premature hot spend): Hot key signs but only 50 blocks elapsed

Signature valid but CheckSequence(144) fails → UNSATISFIED

Use Cases

Bitcoin Vaults

Traditional vault pattern where day-to-day spending uses the hot key with a mandatory delay, while a cold recovery key can sweep funds immediately if the hot key is compromised. The delay window is the detection-and-response period.

Tiered Custody

Corporate treasury with an operations key (hot, delayed) and a board-level override key (recovery, instant). The board can intervene during the delay period if an unauthorized transaction is initiated by the operations team.

Emergency Recovery

Personal cold storage with a hardware wallet as the recovery key and a mobile wallet as the hot key. If the phone is stolen, the hardware wallet can sweep all funds immediately before the attacker's delayed spend confirms.

← CTV AMOUNT_LOCK →