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 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 (CSV relative timelock).
signer_key	PUBKEY	32-33 B	Witness	Public key of the signer — either the recovery key or the hot key. Only the key being used is revealed; the evaluator checks which commitment it matches.
signature	SIGNATURE	64-65 B	Witness	Signature from the revealed key (recovery or hot).

Both public keys folded into Merkle leaf via merkle_pub_key (PubkeyCountForBlock = 2). No key fields in conditions.

Wire Format Breakdown

0x0302 0 3 NUMERIC · 3B Conditions ≈ 10 bytes

0x0302 0 2 PUBKEY · 35B SIGNATURE · 67B Witness ≈ 110 bytes

Total ≈ 188 bytes

Evaluation Logic

1.Read recovery_commit, hot_commit, hot_delay from conditions. Read signer_key, signature from witness. Any missing → ERROR

2.Hash signer_key and check which commitment it matches (recovery_commit or hot_commit). If neither → ERROR

3.If signer_key matches recovery_commit: verify signature against signer_key. If valid → SATISFIED (no delay)

4.If signer_key matches hot_commit: verify signature against signer_key. If valid AND CheckSequence(hot_delay) passes → SATISFIED

5.Neither path satisfied → UNSATISFIED

Return Values

Condition	Result
Missing required fields (pubkeys, signature, delay)	ERROR
Pubkey does not match its commitment	ERROR
Signature invalid for both keys	UNSATISFIED
Hot key sig valid but CSV delay not met	UNSATISFIED
Recovery key signature valid	SATISFIED
Hot key sig valid + CSV delay satisfied	SATISFIED

JSON Wire Format

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

{
  "type": "VAULT_LOCK",
  "inverted": false,
  "fields": [
    { "type": "PUBKEY", "value": "02aabb...recovery_pubkey..." },
    { "type": "PUBKEY", "value": "03ccdd...hot_pubkey..." },
    { "type": "NUMERIC", "value": 144 }
  ]
}

Witness (hot key spend)

{
  "type": "VAULT_LOCK",
  "fields": [
    { "type": "PUBKEY", "value": "03ccdd...signer_pubkey..." },
    { "type": "SIGNATURE", "value": "3045...signature..." }
  ]
}

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 →