Timelocked recovery for company bitcoin

Sources checked 8 November 2026. This explains a custody mechanism, not a wallet recommendation or a ready-to-use spending policy.

What is actually locked?

Bitcoin is held in unspent transaction outputs, or UTXOs. An output can encode alternative spending paths: a normal approval path available now, and a recovery path that also requires a timelock to have matured. Signatures are still required. Expiry does not send coins, contact an executor or prove that somebody has died. The ordinary path can remain available after the recovery path matures.

Miniscript is a structured way to express and analyse certain Bitcoin spending conditions, including signatures and timelocks. It is not a new Bitcoin asset, and it does not make an incorrectly chosen policy safe.

Absolute and relative locks are different

• Absolute lock: CHECKLOCKTIMEVERIFY, or CLTV, uses a fixed block height or a blockchain time threshold. It does not count from the last spend. Recreating an output with the same fixed deadline does not push that deadline back.
• Relative lock: CHECKSEQUENCEVERIFY, or CSV, works with BIP 68 to require a minimum age of the output being spent, anchored to its confirmation. The encoded units are blocks or 512-second time intervals. Blockchain time uses median-time-past, not your laptop clock, and block intervals vary.

Relative delays have encoding limits: BIP 68 uses a 16-bit value, up to 65,535 blocks or 65,535 units of 512 seconds. Do not assume an arbitrary multi-year delay is available as one relative lock. A label such as months is only an approximation for a block-based delay.

Each output has its own clock

Spending does not reset the whole wallet. A confirmed transaction consumes the selected outputs. New outputs start new relative ages only where the new outputs have the applicable relative-timelock policy. Any untouched outputs keep ageing. A wallet login, signature, incoming payment or an unconfirmed refresh does not reset the existing outputs.

Example only: outputs A and B were confirmed at different heights. A normal transaction spends A and creates change back into the same relative-lock policy. That new change has a new confirmation-based clock. B was not spent, so its recovery deadline is unchanged. Change sent to a different policy may have different recovery rights or none at all.

Staged recovery without a one-person override

Conceptual example only, not a deployment recipe: a normal path requires two of three operating keys. After a first delay, a separate two-of-three recovery group can act. A later fallback could require another independently controlled threshold group. Every branch must be reviewed together, including the earliest time each combination of people can spend.

The company should preserve separation of authority on recovery paths as well as the normal path. A fallback that permits one key to spend becomes a single point of control once it matures. We do not recommend single-signature recovery for a company treasury. Two devices held by one person do not provide independent authority.

Earlier paths do not automatically disappear when later ones mature. A delayed signer group can act once its path is valid, even if nobody is missing. Collusion, compromised recovery keys or a missed refresh can therefore create a live competing spending path. Bitcoin enforces the script, not board approval or an employment contract.

The maintenance obligation

• Keep a per-output inventory of confirmation height or time, applicable branches, signer thresholds and earliest recovery eligibility. Assign an accountable role and a deputy.
• If the design relies on renewing relative delays, plan which outputs must move, allow a margin for fees and confirmation delays, and verify the new outputs and their policy after confirmation. A reminder alone changes nothing on-chain.
• Budget transaction fees and staff time. Refreshing can reveal links between outputs and does not guarantee privacy. A reorganisation can alter confirmation-based calculations.
• Do not assume expiry removes the normal signers. Plan for both paths being available, including who can authorise emergency movement.
• Rotate departed or compromised signers through a reviewed migration. Updating a name in the company register does not alter the policy of existing coins.

Support and operational limits

Ordinary multisig support is not proof of support for an arbitrary Miniscript policy. Confirm the exact wallet software, script type, hardware signer firmware, policy registration, transaction display and partially signed Bitcoin transaction workflow for every branch. Export and test the complete descriptor, public-key origins and derivation details. A set of seed backups alone may not reconstruct the policy.

Wizardsardine documents business timelock and custom recovery policies, showing that implementations exist. That is not independent assurance of a product, insurance cover, compatibility or recovery outcome. We do not rank products or recommend a provider. Portability must be demonstrated with the exact exported policy, not assumed from an open-source label.

What to add to the recovery drill

1. Have an independent technical reviewer translate every path into plain English: who can act, when, with which threshold, and what remains available afterwards.
2. On a separate test wallet and suitable test network, demonstrate a recovery attempt before maturity failing, then the authorised threshold completing it after maturity. Record network, software, firmware and policy versions. Do not experiment with the company treasury.
3. Demonstrate a normal-path refresh and inspect all outputs, including change. Check untouched outputs retain their old deadlines.
4. Rebuild watch-only from the descriptor backup and demonstrate the intended signing workflow without the original provider's hosted service. Record dependencies and any branch that cannot be tested.
5. Document fees, monitoring, escalation, deputies and migration steps. Never put recovery words or private keys in the drill record.

Use the existing recovery drill, keyholder continuity plan, owner's estate guide and 2 of 3 multisig explainer alongside this page.

Sources and limitations

The protocol sources below describe consensus mechanisms, not a complete custody system. The staged groups and operating checklist above are educational design examples and editorial risk checks, not independently audited policies. No executable script or wallet configuration is supplied. We have not tested a product, a hardware combination or an actual recovery. Company authority, succession, tax and legal ownership still need qualified professional review: a keyholder's death does not transfer company assets into their personal estate.

Sources

Primary sources only. Each link was checked on 8 November 2026. Rules change, so confirm the current version with your adviser.

1. Bitcoin BIPsBIP 65: CHECKLOCKTIMEVERIFY, absolute locks
2. Bitcoin BIPsBIP 68: relative lock-time, per-input age and units
3. Bitcoin BIPsBIP 112: CHECKSEQUENCEVERIFY and delayed script paths
4. Miniscript authorsMiniscript: structured policies, analysis and compatibility
5. WizardsardineLiana Business: an implementation example, not an endorsement