Taproot’s Script Path: Programmable Bitcoin Custody in 2026

Bitcoin spent the first week of September trading around $79,300, roughly 37% below the all-time high of $126,080 it set on 6 October 2025, according to CoinGecko. More of that supply sits in self-custody than at any point in the asset’s history, and alongside it runs a quieter number: blockchain analytics firm Chainalysis has estimated that up to 3.7 million BTC may already be lost for good, a figure reported by Decrypt and echoed across the industry. The same culture that keeps coins off exchanges also built what CryptoSlate recently called an inheritance time bomb, and 2026 may be when it starts detonating.

The fix is not a new blockchain or a token. It is a part of Bitcoin that shipped almost five years ago and rarely earns a headline. When Taproot activated at block 709,632 on 14 November 2021, as CoinDesk covered at the time, most of the attention went to the key path: Schnorr signatures and, later, MuSig2 letting a group of signers produce one signature that looks like a single-key spend. That is the story of aggregation, and it is the story of making multisig invisible.

This is the other half of Taproot: the script path. It is the part that made Bitcoin spending rules programmable, without a soft fork, without a sidechain, and without handing your coins to anyone. In 2026 those rules are finally showing up in shipping wallets as timelocked inheritance, decaying multisig, and non-custodial recovery. This piece walks through how the script path works, what Tapscript and a language called Miniscript changed, and why the least advertised feature of Bitcoin’s biggest upgrade may turn out to be its most useful.

Two ways to spend a Taproot coin

Every Taproot output, the kind whose address begins with bc1p, commits to two independent ways of spending it at the same time. The first is the key path: a single Schnorr signature from the output’s public key. It is the cheapest and most private route, and it is where MuSig2 lives, because a group can aggregate their keys into one and sign together while the chain sees only one key and one signature.

The second is the script path. Behind the single key sits a tree of alternative scripts, each one a self-contained set of conditions. Any single branch can authorize a spend if whoever is spending satisfies that branch’s rules. The tree is called a taptree, and the magic of Taproot is that the output key itself is mathematically tweaked by the root of that tree, as specified in BIP 341. So the same 32 bytes of public key on-chain silently commit to a whole menu of spending conditions that nobody can see yet.

To spend by key path, you sign with the tweaked key and reveal nothing about the tree. To spend by script path, you reveal exactly one leaf script, satisfy its conditions, and attach a control block that proves that leaf really belongs to the committed tree. The elegant consequence: if you never need your backup rules, nobody ever learns they existed. A wallet can bury an emergency recovery clause in the tree, spend normally by key path for years, and the recovery clause is never published to the world.

MAST, or why hiding your unused rules matters

The taptree is an implementation of an idea Bitcoin developers discussed for years under the name MAST, short for Merkelized Alternative Script Trees. Before Taproot, a complex spending policy lived in a Pay-to-Script-Hash or Pay-to-Witness-Script-Hash output, and the entire script had to be revealed on-chain the moment you spent it. Every co-signer’s public key, every timelock, every fallback condition became public record, even the branches you did not use.

Taproot changes the economics and the privacy of that. A script path spend reveals only the single leaf you are actually using, plus a Merkle proof that links it to the committed root. That proof is the control block: it carries the internal public key and one 32-byte hash for each level of the branch you reveal. The tree can be up to 128 levels deep in principle, though wallets impose far smaller limits in practice. The other branches remain nothing more than a hash inside the output key, invisible and free.

The practical payoff is both privacy and cost. A two-of-three multisig with a timelocked recovery branch, when spent normally, looks like any other payment. Even when you are forced onto a script branch, the branches you did not take stay secret, so an observer learns you had a rule, not what all your other rules were. You also pay only to reveal the branch you use, rather than carrying the weight of every condition you ever wrote. Hiding the rules you did not need turns out to be one of the quiet reasons complex custody became affordable on Bitcoin at all.

What Tapscript actually changed

The scripts inside those leaves are not quite the old Bitcoin Script. They run under Tapscript, defined in BIP 342 by Pieter Wuille, Jonas Nick, and Anthony Towns and deployed as part of the same soft fork. Tapscript rewires several things that mattered for programmable custody.

First, signatures. Inside a Taproot leaf, OP_CHECKSIG and OP_CHECKSIGVERIFY now verify Schnorr signatures per BIP 340 rather than the older ECDSA. The legacy OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled outright, and in their place sits OP_CHECKSIGADD, an opcode that tallies signatures one at a time in a way that plays nicely with batch verification. That small change is what lets a threshold policy inside a script leaf stay efficient.

Second, headroom. Tapscript removed the old 10,000-byte limit on script size and the ceiling of 201 non-push opcodes per script. Instead of hard caps, per-input cost is governed by a signature-operations budget, roughly 50 plus the serialized size of the witness in bytes. That is the same headroom that lets extreme projects pack enormous verifier scripts into a single leaf, the mechanism underneath BitVM and the Citrea rollup, a niche but instructive corner of Bitcoin engineering. For ordinary users the effect is simpler: a rich spending policy with several fallback branches fits comfortably where it once bumped against limits. Tapscript also reserved a family of OP_SUCCESSx opcodes as clean hooks for future upgrades, and made the MINIMALIF rule a consensus requirement so that conditional branches behave predictably.

Miniscript, or Bitcoin Script you can reason about

Headroom is not the same as safety. Bitcoin Script is a stack-based language that is hard to write and much harder to analyze. A script that looks correct can turn out to be unspendable, malleable, or needlessly expensive, and a single mistake in a self-custody policy can lock coins away as permanently as losing a seed phrase. This is the problem Miniscript solves.

Miniscript is a structured subset of Bitcoin Script, introduced by Pieter Wuille, Andrew Poelstra, and Sanket Kanjalkar at Blockstream and unveiled in 2019. Its point is that a computer can analyze it. As Bitcoin Optech puts it, Miniscript allows software to automatically analyze a script, including determining what witness data must be generated in order to spend bitcoins protected by that script. A wallet that understands the Miniscript of a policy knows exactly how to spend it, what each branch costs, and whether it is safe from malleability, without a developer hand-writing new signing code for every template.

Above Miniscript sits an even friendlier policy language. You compose three primitives, signatures, timelocks, and hashlocks, using logical operators like and, or, and threshold, and a compiler turns that policy into an efficient script. The composition is the point: any valid sub-expression can be swapped for another. That the compiler often beats human experts is not marketing. Presenting the work at the Stanford Blockchain Conference in 2019, Wuille noted that the tool found slightly better scripts using it than a hand-written one that we were using in Blockstream Liquid. The whole design has since been written up as BIP 379, which describes a language for writing a subset of Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more. It is still formally a Draft, with authors including Wuille, Poelstra, Kanjalkar, Antoine Poinsot, and Ava Chow.

Crucially for our purposes, the same policy language targets both worlds. The variant that compiles to Taproot leaves, sometimes called MiniTapscript, means a wallet can express an inheritance rule once and deploy it into a bc1p taptree, getting the privacy and cost benefits of the script path for free. As one wallet team put it, you can think of the primitives like Lego blocks, signatures, time, and secrets you compose into clear, reliable policies without hand-rolled scripts.

From P2WSH to Taproot leaves: the toolchain caught up

An idea from 2019 does not become a shipping product overnight, and the reason programmable Taproot custody arrives in force only now is that the plumbing took years to land. Bitcoin Core added descriptor-wallet support for Miniscript in the older P2WSH context across 2022 and 2023, in work led by Antoine Poinsot. Support for Miniscript inside Taproot leaves, expressed through the tr() descriptor, shipped in Bitcoin Core 26.0, released in December 2023, in a change reviewed publicly as the MiniTapscript pull request. From that release, Core could not only watch but also help finalize a partially signed transaction that spends a Miniscript Taproot leaf.

The unglamorous hero here is the output descriptor, the portable text format standardized in the BIP 380 family and explained in Bitcoin Optech’s reference on the topic. A descriptor is the human-auditable, backup-able definition of a policy: which keys, which timelocks, which branches. Without descriptors, a complex script is a fragile secret that dies with the one machine that knew how to rebuild it. With them, a policy is a string you can print, verify on a second device, and restore. The maturation of descriptors and Miniscript together, from research in 2019 to production tooling by 2026, is exactly why the wallets discussed below can finally treat programmable custody as a feature rather than an experiment.

The inheritance problem Bitcoin kept ignoring

Self-custody is the ethos, but keys die with people. For years the honest answer to how do I pass on my bitcoin was a bad one. You could hand your seed phrase to an heir, which gives them the power to rob you today. You could trust an exchange or custodian, which reintroduces the counterparty risk that the collapses of the last cycle taught a generation to fear, a lesson we retraced in the Binance enforcement teardown. Or you could do nothing and hope, which is how coins become statistics.

The statistics are getting harder to ignore. Beyond Chainalysis’s estimate that millions of coins are already lost, analysts point to a structural shift: coins that have not moved in more than a decade are now aging into dormancy faster than miners create new supply, a Fidelity Digital Assets finding summarized by BitGo. Some of that ancient supply is patient conviction. Some of it is a wallet nobody living can open. As the first large cohort of long-term holders ages, the gap between those two explanations becomes a real question for real families.

Taproot’s script path offers a third way that avoids both the give-them-the-seed trap and the custodial one: encode the rule on the blockchain itself. Coins can be spendable by you now and by your heir later, with the later part enforced by the Bitcoin network rather than by a company that has to still exist, still be solvent, and still care. That is not a legal document promising access; it is a consensus rule guaranteeing it.

Decaying multisig and timelocked recovery

The clearest expression of this idea in a shipping wallet is Liana, built by the security firm Wizardsardine, whose founders include Bitcoin Core developer Antoine Poinsot and Kevin Loaec. Liana’s core policy reads almost like plain English. In Poinsot’s own words from the launch, the wallet lets you say: give me a signature for the primary key now, or Wait 1 year, then give me a signature for a recovery key. The recovery route only opens after a delay.

The delay is a relative timelock, enforced by OP_CHECKSEQUENCEVERIFY as defined in BIP 68 and BIP 112. Relative means the clock starts when the coins are received, and, importantly, any spend resets it. An active user who moves funds every few months keeps pushing the recovery window back, so it never actually opens for them; it only matures if the primary keyholder goes silent. Because it is a consensus rule, Wizardsardine cannot move the coins in either direction, and if the company disappeared, heirs could still sweep the recovery branch with open-source tools. The relative timelock caps out at 65,535 blocks, which is roughly fifteen months, enough to cover a long absence without being open-ended.

Poinsot has framed the design as adding a new axis to custody. The scheme provides another dimension to the inheritance scheme. In addition to who can spend the funds, you can now define when they gain access, he wrote, and the goal throughout is protecting against loss without degrading security, because the recovery key is worthless until its timeout arrives. The same primitive powers what the industry calls a decaying or expanding multisig: a two-of-three today that simplifies to a single recovery key after, say, a year of inactivity. A lost hardware wallet or a deceased co-signer no longer means the funds are frozen forever, because the policy gracefully degrades to something a survivor can satisfy. Liana has since extended to hardware, adding Coldcard and experimental Taproot support in its v5.0 release, and Poinsot has moved on to Chaincode Labs while continuing to work on Bitcoin consensus.

A menu of spending policies you can build today

Inheritance is the headline use, but it is one branch of a much larger menu. Because Miniscript composes signatures, timelocks, and hashlocks freely, and because the taptree hides every branch you do not use, a surprising range of real-world custody arrangements are expressible on Bitcoin today, with no new opcodes and no soft fork. The table below sketches the ones already appearing in products.

To make that concrete, picture a simple inheritance setup as a taptree with two leaves. The key path is a MuSig2 aggregation of you and your spouse, so everyday spends stay cheap and private and give away nothing about the rest of the plan. One script leaf holds a two-of-two of your daily keys as a hot fallback; a second leaf holds your child’s key gated behind a one-year relative timelock. While you are active, you spend by key path and neither leaf is ever published. If you and your spouse both go silent for a year, the timelock on the second leaf matures, and your child can claim the coins by revealing only that branch plus a control block proving it belonged to the committed tree the entire time. Everything else, including the hot fallback, stays private forever, and an observer sees an ordinary Taproot spend.

Each row is just one or more branches in a taptree. In the normal case you spend by the cheapest branch, or by key path, and the rest of the menu stays private. The point is not that any single policy is exotic; it is that they are now composable, analyzable, and, thanks to descriptors, backup-able. That combination is what turns a clever script into something an ordinary holder can actually rely on for years.

Vaults without a soft fork

It is worth being precise about what this does and does not deliver, because the crypto habit of overpromising is exactly how people lose money. Miniscript composes three ingredients and only three: signatures, timelocks, and hashlocks. That covers a great deal, inheritance, recovery, escrow, and the hash-and-timelock contracts that route payments on the Lightning Network. What it cannot do is constrain where coins go next.

A true covenant, a rule that says these coins may only ever be sent to this cold-storage address, or a reactive vault that gives you a window to claw a theft back before it settles, requires new consensus opcodes. The leading proposals, OP_CTV, OP_CSFS, and OP_CAT, remain unactivated in 2026 after the same fork fights that consumed Bitcoin’s development discourse this year. So the honest framing is this: Taproot did not give Bitcoin covenants. It gave Bitcoin analyzable, private, multi-branch scripts that run today. You can build a vault-lite, a delay plus an alarm, but not the fully reactive vault that covenant advocates want.

That boundary also clarifies the trade against Layer-2 approaches. Designs like statechains and Ark buy extra programmability and speed by adding new venues or trust assumptions, a trade we examined in our look at Spark and statechains. Script-path custody makes the opposite trade: everything stays on the base layer and fully non-custodial, at the cost of a larger on-chain footprint whenever a backup branch is finally used. For coins you intend to hold for decades and pass on, paying that footprint once, if ever, is usually the right side of the trade.

Where the wallets are

A protocol capability is only as real as the software that exposes it, and here 2026 looks noticeably healthier than 2024 did. Several wallets now support Taproot script paths and Miniscript to varying depths, with the hardware signers, always the slowest to move, finally catching up.

The gating factor across the board is hardware signing, because a device has to display and verify a complex policy before it will sign for it. Coldcard’s Edge firmware supports Schnorr signatures, Taproot, and Tapscript with Miniscript trees of up to eight leaves, documented in the project’s Miniscript notes, and recent firmware even rejects unfamiliar Taproot leaf versions during signing as a safety measure. Nunchuk, which shipped Taproot MuSig2 multisig in beta in December 2024, frames the goal in accessible terms and is extending toward built-in inheritance timelocks, per its own inheritance guide. The direction of travel is clear: the policies described in this article are moving from developer demos to buttons in consumer apps.

Reading what you sign

Programmable custody has a sharp edge. Complexity you cannot verify is not security; it is a trap with better branding. A malicious or simply buggy wallet could construct a policy with a hidden branch that drains you, or a recovery timeout that opens far sooner than you intended, and a script-path control block is not something a human reads by eye at signing time.

The defense is the descriptor-plus-hardware workflow. The descriptor is the auditable source of truth for a policy; a good hardware wallet re-derives that policy on its own screen and shows you the keys and timeouts before it signs, so a compromised computer cannot slip a different tree past you. This is the Bitcoin version of a fight the rest of the industry is also having, the push for clear-signing over blind approval that we covered in the context of Ethereum’s account-abstraction rollout, and it carries the same supply-chain exposure, where a trusted wallet update can itself become the attack, the pattern documented in our reporting on crypto’s supply-chain phishing.

Two habits matter for anyone building these policies. First, test the recovery path with a small amount, ideally on signet or with a token sum, and actually spend through it before you trust it with real size; a timelock you have never exercised is a theory, not a safety net. Second, back up the descriptor, not just the seed words. In a multi-branch policy, the seeds alone are not enough to reconstruct how the coins can be spent, and an heir who inherits keys but not the policy inherits a puzzle.

The SEC, the IRS, and self-custody

None of this touches the parts of crypto that United States regulators oversee, and that distinction is worth stating plainly. A soft fork like Taproot, and the scripts you build on top of it, are consensus-layer and wallet-layer engineering. The Securities and Exchange Commission neither approves nor blocks them; its remit runs downstream, to exchanges, registered custodians, and the spot Bitcoin exchange-traded products, each of which sets its own key-management and fork policies. Writing a Miniscript inheritance policy for your own coins is not a regulated activity any more than writing a will is.

For a self-custodian, the agency that matters is the Internal Revenue Service, and the news there is mostly benign. Moving your own coins between your own address types, from a legacy address to bc1p, or from a single-key wallet into a Miniscript policy, is not a sale, so it is not a taxable disposal and it does not reset any holding period; you are shifting your property between your own pockets. Inheritance is a separate and generally favorable event: under long-standing United States tax law, inherited property receives a stepped-up cost basis to fair market value at the date of death, and the IRS has treated crypto as property since its 2014 guidance. How those rules interact with retirement accounts and estate planning is its own subject, one we mapped in the 2026 tax rulebook for crypto in 401(k)s and IRAs. The upshot is that a script-path plan is a technical tool, but inheritance is also a legal event, and the on-chain timelock and the paperwork need to tell the same story.

The quantum asterisk

One caveat belongs on any long-horizon Bitcoin plan. Script-path spends still rest on elliptic-curve public-key cryptography, whether Schnorr or the older ECDSA, and a sufficiently large quantum computer could in principle break both. Taproot is if anything more exposed than older address types on this axis, because a bc1p output publishes a public key in the output itself, and a script-path spend additionally reveals the internal key inside the control block. So a taptree full of clever recovery branches carries the same distant risk as the rest of Taproot.

That risk is being addressed at the protocol level through post-quantum proposals and a contested migration plan, a story we told in detail when covering BIP-360 and the freeze debate, and it does not change the near-term case for timelocked recovery at all. The reasonable posture is simply to assume that address types will migrate over the coming decades, and to treat any inheritance policy as something that will be re-cut onto new script formats at least once in its lifetime, the same way a prudent estate plan gets updated as laws change.

What comes next

The near-term roadmap for programmable custody is unglamorous and important. Miniscript is still a Draft in BIP 379, and the work of 2026 and 2027 is standardization and interoperability, making sure a descriptor written by one wallet can be read, verified, and signed by another, so that a policy is genuinely portable and not a lock-in. Cross-wallet recovery, the ability for an heir to use any compliant tool rather than the exact app the deceased happened to choose, is the feature that turns a neat trick into infrastructure.

The longer arc depends on the covenant fights. If an opcode like OP_CTV or a CAT-and-CSFS combination ever activates, script paths become dramatically more powerful, unlocking real vaults and congestion control that Miniscript alone cannot express. Until then, the composition of signatures, timelocks, and thresholds is the frontier that actually ships, and it is quietly enough to rebuild inheritance and recovery for people holding at size.

Step back and the shape of Taproot’s real legacy comes into focus. Aggregation, through MuSig2, made multisig invisible. The script path made it programmable. Together they are why self-custody at size in 2026 increasingly means a policy rather than a single key. As the market chops sideways near $79,000 into a heavy autumn macro calendar, the engineering under bc1p keeps compounding regardless of the price. Almost five years after it activated to a shrug, the feature Bitcoin barely advertised is turning out to be one of the most consequential things it ever added.

Frequently Asked Questions

What is a Taproot script path?

A Taproot script path is the alternative-conditions route of a bc1p output. Behind the single public key sits a tree of scripts called a taptree, and any one branch can authorize a spend if its conditions are met. Only the branch you actually use is revealed on-chain; the rest stay hidden inside the output key, which is what gives the script path its privacy and cost advantages.

What is Miniscript and how does it relate to Taproot?

Miniscript is a structured, analyzable subset of Bitcoin Script created by Pieter Wuille, Andrew Poelstra, and Sanket Kanjalkar. It lets software reason automatically about a spending policy, including how to sign it and what it costs. Through the MiniTapscript variant it targets Taproot leaves, so wallets can build inheritance, recovery, and multisig policies and deploy them safely into a bc1p taptree.

Can I set up Bitcoin inheritance without a custodian?

Yes. Wallets such as Liana and Nunchuk use timelocked recovery branches enforced by the Bitcoin network itself, so an heir can access the funds after a set delay without any company being involved. Because the timelock is a consensus rule, the coins remain fully in your control until it matures, and heirs can recover using open-source tools even if the wallet provider no longer exists.

Does moving coins to a Taproot address trigger US taxes?

Moving your own coins between your own addresses, including into a Taproot or Miniscript policy, is not a sale and therefore not a taxable disposal in the United States, and it does not reset your holding period. Inheritance is treated differently and generally favorably, with a stepped-up cost basis at death, but estate and retirement-account specifics vary, so treat those as a separate planning question and consult qualified guidance.

Do Taproot script paths give Bitcoin covenants?

No. Miniscript composes signatures, timelocks, and hashlocks, which is enough for inheritance, recovery, escrow, and Lightning, but it cannot restrict where coins are sent next. True covenants, such as a reactive vault or send-only-to-cold-storage rules, need new opcodes like OP_CTV, OP_CSFS, or OP_CAT, and those remain unactivated on Bitcoin as of 2026.

Marcus Okafor covers Bitcoin protocol development and Layer-1 infrastructure for HOGE Wire.