Skip to content

Spend Policies

A spend policy defines the conditions under which an Output may be spent. The output only references the Merkle root of the policy—i.e., its "address." When the output is spent, the policy is revealed. This improves privacy and saves block space, since polciies may be much larger than addresses.

Spend policies are based on Miniscript, an expression-based DSL for Bitcoin Script. A number of policy types are supported:

  • above(n): Satisfied if the block height is greater than n.
  • after(t): Satisfied if the median timestamp is later than t.
  • pk(k): Satisfied if the transaction is signed by Ed25519 key k. This is the "standard" policy used by most wallets.
  • h(x): Satisfied if a preimage is supplied whose SHA256 hash is x. SHA256 was chosen to maximize compatibility for cross-chain atomic swaps.
  • thresh(n, [p1, p2, p3...]): Satisfied if exactly n sub-policies are satisfied. This is the only recursive policy; it is evaluated depth-first and left-to-right. Unsatisfied sub-policies must be replaced with their address using opaque.
  • opaque(a): Unsatisfiable; replaces an unsatisfied thresh sub-policy with its address a.
  • uc(t, [k1, k2, k3...], n): Provides backwards compatibility for v1 unlock conditions. Cannot be used as a thresh sub-policy.

The address of a policy is derived by hashing its binary encoding, except for thresh, which hashes a concatenation of the addresses of each sub-policy. The address of a uc policy is also special-cased, for backwards-compatibility with v1.

Signatures and preimages are included alongside the policy being satisfied, and must appear in the order in which they will be evaluated, i.e. depth-first traversal order.

In v1

The predecessor to spend policies was "unlock conditions," which could specify a timelock, a list of allowed public keys, and a number of signatures required. Addresses were defined as the root of a Merkle tree containing these values.

In v1 transactions, signatures were more flexible: they could cover any subset of fields within the transaction. Public keys could also specify which signature algorithm should be used for verification, though in practice only Ed25519 was ever supported.