Design the tree
Draft a Taproot script tree from audited templates only: the KeyLock leaf is byte-identical to the audited Pearl Bounty award leaf, the TimelockRefund leaf to the audited Pearl Escrow refund leaf, and the MultiSig leaf follows the audited Pearl Covenant multisig pattern. No new cryptography — every digest is BIP-340/BIP-341 from the audited Sign core.
Internal key — who (if anyone) can use the keypath
Leaves (1 of 8)
1–8 leaves. Each leaf is one authorization path — a distinct way the coins can move. Expert mode (custom script hex) is available per leaf; anything you paste there is unreviewed.
Blueprint drafted
Tree
Leaves
Canonical descriptor
Address & control blocks
Draft a blueprint in the Design step first — the address, the tweaked key, and the spend-ready control blocks land here.
P2TR address
Tree
Spend-ready leaves control blocks verify against the tweaked key
Verify a blueprint
Standalone verifier — paste a pearl-policy:v1:… descriptor, the address it claims,
and optionally the sealed commitment. Everything is recomputed from scratch: PROVEN only when the descriptor is
canonical and re-derives the claimed address exactly. Any tampering moves the address — loudly.
Export
Take the drafted blueprint with you: machine-readable JSON, a shareable link that carries the descriptor in the URL hash (nothing is uploaded — the page never phones home), and a markdown summary for docs.
Descriptor JSON
Shareable link
Markdown summary
Learn — what a policy tree proves (and doesn't)
What Taproot policy trees prove
- Authorization paths. A tree commits to a fixed set of leaves; each leaf is a script that says who can move the coins and under what on-chain conditions (a signature, a block height, m-of-n keys).
- Deterministic addresses. The P2TR address is a pure function of the internal key and the leaf scripts. Anyone with the descriptor recomputes the identical address — no registry, no server.
- Unspendable keypaths, by construction. With a NUMS internal key, nobody knows the discrete log, so the keypath cannot be used. Coins move only through the script leaves you drafted.
- Tamper evidence. Change one bit of one leaf and the address changes. The Verify tab turns that property into a standalone PROVEN / NOT PROVEN check.
What they don't prove
- Why the coins should move. Scripts authorize keys; they know nothing about prices, invoices, identities, or any off-chain fact. Authorization is not endorsement.
- Off-chain reality. Pearl script cannot check a bank transfer, a delivery, or a price feed. Anything real-world must be verified off-chain (see Pearl Hedge's strike-payment check for the pattern).
- That custom scripts are safe. Expert-mode hex is yours alone — audit it, test it on testnet, never fund what you can't read.
- Funding. An address is just an address until someone funds it. This page never touches funds; fund from Pearl Sign or Pearl Vault, and double-check the address character by character.
Reading a blueprint
- The descriptor (
pearl-policy:v1:<hrp>:<source>:<leaves>) is the whole design in one line — every field that moves the address is in it. - A control block is a leaf's proof of membership in the tree: the internal key plus the sibling hashes up to the root. Paste it into Pearl Sign to spend via that leaf.
- The sealed commitment (
pearl-policy:v1:<hrp>:<sha256(descriptor)>) binds the full descriptor into 32 bytes — publish it to commit to a policy before revealing the leaves.
Honest limits
- This page never moves PRL and never broadcasts a transaction. It computes addresses and data — funding and spending happen in Pearl Sign or your wallet.
- A NUMS internal key is intentionally unspendable on the keypath. Lose every leaf key and the funds are unspendable — treat that as permanent.
- Templates are authorization-only: they prove who can move coins, never why, never at what price, never any off-chain fact.
- Expert custom scripts are unreviewed. Verify them yourself; never fund a tree you can't fully read.
- No new cryptography: BIP-340, BIP-341 digests, taggedHash, bech32m — all audited Sign/Escrow/Bounty/Covenant lineage. The desk runs fully offline; it makes zero network requests.