Bitcoin custody mechanics

The Miniscript Policy Gap in Bitcoin Custody

Updated 11 November 2026

That is a policy gap. It is not a key failure.

The Rule Exists in the Script

Bitcoin scripts can encode conditions such as a timeout, a required signature or a branch between two spending paths. Miniscript extends that expressive surface with a compact language for describing many such policies. The resulting policy can then be compiled into a Bitcoin script, checked by tools and presented to signers for review. That is useful because a human readable policy and an executable script no longer need to be maintained as unrelated artefacts.

But compiling the policy does not govern the people who hold keys. A signer can reject a transaction even when the transaction satisfies the script. A signer can also sign a transaction that satisfies the script but was selected by a coordinator whose understanding of the policy differs from the signer's. The chain will validate the spend. The chain will not validate the intention behind it.

This distinction matters most when policy is not a single binary switch. Suppose the policy permits an old key to move funds before a timelock expires, while a recovery key can move them afterwards. Every participant can possess the correct keys and still disagree about which path should be used. The script remains valid under either interpretation. Custody risk has moved from key control to decision control.

The relevant reference is Bitcoin Core's support for Miniscript descriptors, which allows wallets to import and analyse policies expressed in the language. Core's documentation treats the descriptor as a policy declaration and provides validation tooling for it. Those checks are valuable, but they do not constitute approval by every cosigner. The official Bitcoin Optech explainer on Miniscript also describes it as a language for expressing spending conditions, not as a mechanism that binds human decisions. See Bitcoin Core descriptor documentation and Bitcoin Optech on Miniscript.

Three Views of One Wallet

A single signer wallet, coordinator wallet and policy file can form three different interfaces to the same UTXO. The signer sees a request and a set of possible scripts. The coordinator sees a route chosen from a policy. The observer sees a script whose branches may be lawful under conditions that have not yet arrived.

Consider a timelocked branch with an emergency path. The policy says that the emergency path is for a later date. The coordinator offers the emergency path early because its clock, or its interpretation of the timelock, says that the ordinary path is unavailable. The signer checks that the script is valid and that the emergency signature is valid. If the signer does not independently evaluate the time condition against the intended policy, the spend can proceed before the intended date.

That failure does not require a stolen seed, a malicious exchange or a flaw in elliptic curve cryptography. It requires only that a signer verifies the wrong question. The useful question is not whether the transaction will be accepted by Bitcoin. It is whether this transaction implements the policy that the signer has approved.

Hardware wallets can display policy information, and some wallets offer explicit policy validation. Neither feature changes the underlying trust model. A device can reduce interpretation errors, but the signer must still know which policy is authoritative, who can change it and which clock is relevant. The hardware wallet is a signing environment. It is not a custodian of organisational intent.

The Coordinator Is Not the Policy

The coordinator chooses which transaction is constructed from the available UTXOs and paths. That role gives it substantial influence without giving it the ability to spend alone in a properly coordinated wallet. This is why some teams describe the coordinator as the weakest link. The phrase is incomplete. It is the most powerful link over policy selection, provided the signers remain willing to check what they sign.

For a custodian, the practical control should therefore include the policy itself. A policy identifier, version and approved source should accompany every signing request. A change from a timelocked path to a recovery path should trigger a separate approval state rather than appear as an ordinary coin selection choice. The signer should see the relevant locktime, sequence requirements and all constraints attached to the selected branch.

Clock comparison deserves particular care. A relative timelock uses transaction sequence information, while an absolute timelock uses block height or timestamp depending on the script. Wallets can also apply a safety margin so a transaction is not broadcast too close to the boundary. These are different policies even when they produce similar user interfaces. A signer who knows only that a timeout exists does not know whether the approved timeout is 30 days, 90 days or six months.

Multisignature and script policies are therefore not substitutes for transaction review. Multisignature establishes how many keys are required. A script establishes which conditions the network will enforce. A policy review establishes what the key holders intend. Each layer answers a separate question.

When Policy Files Diverge

Policy divergence often begins with ordinary operational friction. A descriptor is copied into a vault. A coordinator upgrades its wallet. A recovery plan is documented as prose. Another signer imports only a public descriptor and reconstructs the logic from memory. Each party may still be technically competent while operating from a different statement of the rules.

The danger grows when one party can silently change the selected branch. A signer may rely on the coordinator to show only policy conforming transactions. If the signer is not shown the alternatives, or if the interface reduces every branch to an opaque transaction request, then the signer has not reviewed policy. The signer has reviewed a proposal that may be valid.

Teams can make the policy authoritative by storing it in a versioned artefact, recording its hash with each approval and requiring the signer to check that hash. Hardware signing devices can include the descriptor or relevant policy data in the device's own review flow. Where possible, signers should compare the complete spending set, not merely the selected path, because the selected path reveals little about what else was available.

These controls do not create consensus among humans. They create evidence that each participant acted on the same rules. That is the standard required for institutional custody. Evidence can be logs, signed policy commitments, device review exports or an independent coordinator. The important property is that a signer can later show what policy was displayed when approval occurred.

The Recovery Path Needs Its Own Approval

Recovery branches deserve separate treatment because they are often introduced during stress. A routine payment path and a recovery path may differ in delay, key set and destination. Combining them in one familiar interface can make an emergency transaction look routine. The signer may see a familiar wallet, a familiar amount and a familiar destination, while the branch selected under the script differs from the branch expected by the policy.

The recovery path should not be treated as a fallback for uncertainty about policy. If signers disagree about which path is permitted, the correct response is to stop. Deliberation may be inconvenient, but a pause is preferable to a technically valid spend that undermines the agreed recovery schedule.

A recovery policy should identify its trigger, the evidence required, the eligible keys, the permitted destinations, the timelock or delay and the party responsible for assembling the transaction. If a trigger depends on an outage, a loss or a legal instruction, the coordinator must provide evidence that matches the approved trigger. The script cannot assess whether an outage occurred. It can enforce delay and key thresholds, not the business meaning of the event.

This is also why policy review must be continuous. A valid descriptor today can become stale after a wallet migration, a hardware replacement, a change of legal control or an update to the recovery process. The UTXO does not care. The human system does.

Custody Means More Than Key Coverage

Bitcoin custody is often reduced to where the private keys are, whether backups exist and whether the signing device is secure. Those are essential controls. They are not sufficient when a wallet has several legal branches. Key coverage answers who can sign. Policy coverage answers who decides what will be signed.

The gap appears when a signer cannot reproduce the policy decision independently. In a simple wallet with one obvious destination and one spending path, the ambiguity is small. In a vault with timelocks, emergency paths, different clocks and multiple coordinators, the ambiguity can be large enough to dominate the technical risk.

The control stack should therefore end with a hard rule: no signature should be treated as approval until the signer has verified the policy version, the selected branch and the relevant timing constraints. If those facts are not available to the signer, the signer is being asked for blind trust.

Never paste a seed into a watch-only field.