Vault

A vault locks funds behind two spend paths:

• Primary key can spend, but only after a chosen locktime height.
• Recovery key can spend immediately, any time.

The intended use is a self-imposed delay on the primary key with an emergency override. If the primary key is compromised, the attacker cannot spend immediately — they have to wait past the locktime, giving you (the recovery key holder) a window to move the funds out first.

Lock

exfer script vault-lock \
    --wallet           ~/primary-wallet.key \
    --recovery-pubkey  <RECOVERY_PUBKEY_HEX> \
    --locktime         <BLOCK_HEIGHT> \
    --amount           "100 EXFER" \
    --rpc              "$RPC" \
    --json

Pick --locktime based on how much delay you want. At 10 s per block:

Compute from current tip: locktime = current_height + delay_blocks.

Spend with primary key (after locktime)

exfer script vault-spend \
    --wallet           ~/primary-wallet.key \
    --tx-id            <LOCK_TX_ID> \
    --recovery-pubkey  <RECOVERY_PUBKEY_HEX> \
    --locktime         <BLOCK_HEIGHT> \
    --rpc              "$RPC" \
    --json

The CLI fails locally if current_height <= locktime. After the locktime passes, the spend succeeds.

Recover with recovery key (any time)

exfer script vault-recover \
    --wallet           ~/recovery-wallet.key \
    --tx-id            <LOCK_TX_ID> \
    --primary-pubkey   <PRIMARY_PUBKEY_HEX> \
    --locktime         <BLOCK_HEIGHT> \
    --rpc              "$RPC" \
    --json

This works at any height, including before the locktime. The recovery key is the "fire alarm" — you only sign with it if the primary is compromised or you want to abort the timelock.

Threat model

• Primary key compromise: attacker has the primary key, but cannot spend until locktime. You spot the leak (via monitoring or just noticing UTXOs are locked), and use the recovery key to sweep funds before the attacker's window opens.
• Recovery key compromise: attacker can spend immediately. The vault offers no protection here. Keep the recovery key colder than the primary (offline, hardware, paper, etc.).
• Both keys compromised: total loss. Same as any 1-of-2 multisig.

For deeper defense, layer a vault on top of multisig (e.g. multisig 2-of-3 for the recovery branch) — that's not a built-in pattern but can be assembled by composing scripts. See Protocol specification §6 for the script language.

Common pitfalls

• Locktime in the past at lock time. If locktime <= current_height when you lock, the primary key can spend right away — the vault has no protective effect. Always sanity-check before submitting.
• Recovery key on same machine as primary. Defeats the purpose. Keep the recovery key on a different host, ideally offline.
• Forgetting --locktime on spend. The script binds the locktime in the spending witness — you must repeat the same --locktime you used at lock time, not the current height.