Bitcoin is a trillion dollar asset class consistantly going on 2 year, but the amount of users interacting on the network is far smaller, as certain transaction types really don’t make sense for on-chain transfers. If you need transaction finality, if you don’t have access to Lightning or you want to consolidate funds for the long term, the base chain is your destination.
But for day to day transactions, you’re better off using another settlement layer.
An average users reasons for avoiding on-chain transaction is usually down to transaction costs, but the more UTXOs we have, the larger the database becomes, and nodes need to store that.
If A billion people holding Bitcoin separately meant a billion UTXOs are needed on-chain, it would not only be slow and costly to move funds, but many full nodes would have to convert to pruned nodes or upgrade their storage capacity to remain a complete archival node.
If funds are pooled at an operator level indeed only a few UTXOs are needed, internal transfers can be instant, since transactions become updating records of a percentage claim of the underlying UTXO, it’s almost as if you’re all shareholders in this UTXO and issued a share certifcate for your ownership.
The idea of sharing a UTXO has come up several times in the past, fedimint users are effectively sharing a UTXO, channel factories are built on the idea of sharing UTXOs and Ark with it’s VTXO operator model still lives ontop of a shared UTXO.
Lightning Labs co-founder Olaoluwa Osuntokun (roasbeef) published a 42-page paper introducing LayerTree, and Lightning Labs announced it publicly the next day.
The pitch is ambitious.
LayerTree is a Bitcoin scaling design that lets up to a million people share a single on-chain output, while each can leave on their own at any time in one transaction.
It also comes with a big caveat that you might miss if you’re like the majority that only read headlines or the announcement tweet.
LayerTree can’t run on Bitcoin today. It depends on the opcode feature that has been proposed but not activated.
So it is best read as a serious design with a reference implementation, not as a product you can use.
The Problem It Targets
Bitcoin’s base layer gives each user their own outputs, and every payment competes for limited block space. Layer-two systems try to get around that by letting many people share on-chain space. Lightning does it with channels between pairs of users.
Ark does it with trees of pre-signed transactions that many users share.
Each approach has costs. Lightning needs channels, liquidity and often an online node. Ark’s pre-signed transactions expire, so users must refresh their coins regularly, and exiting means broadcasting a chain of transactions.
LayerTree asks whether covenants can remove some of those costs.
How LayerTree Works
In LayerTree, each user owns a leaf in an off-chain Merkle Sum Tree and each leaf records the user’s balance, owner public key, exit public key, lease term, and state sequence number. Adjacent leaf nodes are continuously merged upward, with each parent node recording the balance sum and hash of its two child nodes, eventually forming a single unique root.
One shared output. Many members share a single Bitcoin output.
A tree of balances, kept off-chain. Who owns what is recorded in a Merkle-sum tree. Each member’s balance is a leaf. Every node above the leaves holds a hash of its two children and the sum of their amounts, all the way up to a single root. The shared output commits to that root, so changing any leaf changes the root.
A covenant enforces the rules. Every spend of the shared output must satisfy a covenant, a script that checks a proof against the committed root, applies one rule, and requires the transaction to recreate the output under the new root. The chain stores only the root, and each transition proves the old state and commits to the new one.
Exit in one transaction. Because the covenant itself enforces the rules, a member can leave at any time with no timelock, no transactions signed in advance and no expiry date. They provide a proof of their leaf, and the transaction pays them out and recreates the shared output with their slot removed. The operator who runs the tree can’t take anyone’s money or stop anyone leaving.
What the operator does. The operator admits members, can remove members whose lease has run out, and co-signs some changes. It holds no key over anyone’s balance.
Paying and Receiving
Moving value between members costs nothing on-chain. LayerTree describes two off-chain mechanisms:
- Channel leaves. A leaf can hold a channel, so two members can pay each other inside it.
- Vouchers. A voucher is a message signed by a leaf’s owner that lets its holder carve a new leaf out of the owner’s balance later, without the owner needing to be online.
For Lightning, a “credit leaf” lets a member receive over Lightning without being online. The paper also describes swaps, where a hash-locked voucher and a Lightning HTLC share one secret, and an order in which they must settle. One coverage of the paper notes a brief window of trust in the basic flow: the operator has received the Lightning payment but hasn’t yet issued the voucher to the recipient. A “pending pair” design is meant to narrow that gap.
What It Costs?
Bitcoin charges by transaction size in virtual bytes (vB), and the paper’s numbers are worth quoting precisely. A bare single-owner spend is about 111 vB. For a tree of depth 16, which has 65,536 slots:
| Operation | Approximate cost |
|---|---|
| Leaving alone (FULL tier) | about 1,020 vB |
| Leaving an Ark-style tree of transactions, per the paper’s comparison | about 2,511 vB |
| Leaving with a proposed Merkle-sum opcode | about 540 vB |
| Joining as part of a cohort of about 1,000 | under 1 vB per member |
| Sweeping an expired cohort (51 leaves) | about 158 vB per leaf |
| Paying another member | nothing on-chain |
The key idea is where the cost lands. Sharing is cheap for everyday use, and the price is paid at exit, which is about nine times a bare spend. That price is the proof, and it doesn’t grow with the number of members. With the purpose-built opcode, the site says exits grow by only about 10 vB per doubling of members. Independent coverage of the paper cites modelled figures of 541 vB at depth 16 and 581 vB at about a million members.
Those lower numbers rely on OP_MERKLESUMUPDATE, an opcode the repository specifies and measures but that nobody has proposed for Bitcoin. They are modelled estimates, not evidence of a working million-member deployment, and the figures above come from the project’s own comparisons.
The Catches
LayerTree’s site is unusually direct about what it doesn’t promise.
It can’t run today. The scripts use opcodes that have been proposed but not activated, and the site lists four sets of them. The same transitions are built four times, once for each set of proposed opcodes, with the costs of each.
Nobody has to let you in. Joining needs the operator’s signature. Someone never admitted has lost nothing, but nothing guarantees admission.
A grafted subtree can be empty of meaning. When the operator adds a cohort, the covenant sees only the subtree’s hash and a claimed sum. If no real tree stands behind that hash, nobody can ever prove a leaf under it, and the value is frozen. Existing members are unaffected, and no value is created, but a joiner who doesn’t check their own path before funding could lose access to their money.
Everything passes through one output. Every transition spends and recreates the same output, so unconfirmed transitions form a chain. Bitcoin’s default relay policy allows about 25 unconfirmed descendants, which caps how fast strangers can leave one at a time. A batch counts once against the cap. The proposed answer is to split a deployment into several trees. Independent coverage describes simultaneous withdrawals as a remaining challenge.
Cheap eviction is cheap griefing. At about 160 vB per leaf, an operator can clear expired members cheaply. Members who want a firm guarantee choose a distant lease, or none.
How LayerTree Differs From Ark?
LayerTree sits in the same family as Ark: a shared on-chain output, an operator, and users who keep an exit. The differences are the interesting part.
- Enforcement. Ark implementations today, such as Bark and Arkade, work without consensus changes and rely on pre-signed transactions and cooperative signing. LayerTree uses covenants, so the chain enforces the rules.
- Expiry. Ark balances have a lifetime, and wallets must refresh them. LayerTree funds don’t expire from inactivity, and it doesn’t require pre-signed transactions.
- Availability. Ark works on Bitcoin today. LayerTree doesn’t.
LayerTree’s own pages include a section on where it loses to other designs, and it deserves a read before drawing conclusions from the headline numbers.
Verification and Status
The project includes a paper in short and full versions, a reference implementation, and a simulator. The site says the simulator measures every script and witness size, and it describes a Lean model that proves properties of the rules, along with a planned model of the off-chain protocol. Independent coverage cites 3,019 executable checks. That shows care, but formal checks of the rules don’t prove that the opcodes will be adopted or that the surrounding protocol is secure.
Two Ways Money Moves in LayerTree
LayerTree gives users two straightforward ways to transfer funds:
- Direct Transfers: You send money directly from your balance to another user. This works instantly like a standard peer-to-peer payment, updated right on the ledger.
- Voucher Transfers: Instead of sending money directly, you create a digital “voucher” for a specific amount. You can pass this voucher to someone else, and they can redeem it to claim the funds whenever they are ready.
Why a Voucher Can Only Be Used Once
To stop people from spending the same money twice (known as the double-spending problem), every voucher is designed to self-destruct upon use:
- Unique Digital Identity: Each voucher gets its own unique ID code when created.
- Instant Invalidation: The moment someone redeems a voucher, the system marks its unique ID as “spent” on the network.
- Automatic Rejection: If anyone tries to redeem the same code or a copy of that voucher a second time, the system checks the ledger, sees it has already been used, and immediately rejects it.
Why Vouchers Don’t Eliminate Credit Risk
While vouchers make payments flexible, they don’t magically erase financial risk:
- Backing Depends on the Issuer: A voucher is only as good as the money backing it. If the person or entity who issued the voucher doesn’t have the actual funds in reserve, the voucher becomes worthless.
- Counterparty Risk: Holding a voucher means you are trusting the issuer to stay solvent until you redeem it. If the issuer defaults or goes bankrupt, the voucher cannot be paid out.
- System Risk: Vouchers secure the transfer of value, but they cannot guarantee the financial health of the person who created them.
Why Design Vouchers in the First Place?
If direct transfers exist, why bother with vouchers? Vouchers solve several key real-world business problems:
- Offline & Delayed Payments: You can generate and hand over a voucher even if the recipient isn’t online right away to accept a direct transfer.
- Flexible Smart Contracts: Vouchers act as flexible building blocks for automated deals (escrow, conditional payouts, or promotional rewards) that only execute when specific conditions are met.
- Privacy & Anonymity: Passing a voucher doesn’t require sharing personal account details between the buyer and seller during the transaction.
- Easier Accounting: Businesses can issue batches of fixed-value vouchers for auditing, budgeting, or customer gift cards without opening direct access to their main treasury accounts.
Which Bitcoin Upgrades Does LayerTree Depend On?
LayerTree requires covenants, which allow a UTXO to impose constraints on how it can be spent in the future.
An example of the rules required for LayerTree to function is a script ensures that after a user exits, the remaining funds go back into an output committing to the new tree root, and cannot be taken by any arbitrary address.
The project isn’t reliant on one OP_CODE but there are designs four opcode combinations.
1. The FULL version relies on BIP 441, BIP 440, OP_TX, BIP 348, and a set of elliptic curve opcodes.
BIP 441 restores some early-disabled script capabilities and supports more flexible data and numerical processing. BIP 440 provides a computational budget for these variable-cost operations.
2. The MID version relies on OP_CAT from BIP 347, OP_TX, OP_CHECKSIGFROMSTACK from BIP 348, and OP_TWEAKADD from BIP 449.
OP_CAT is used to concatenate data in scripts. OP_TX allows scripts to read and constrain the current transaction. OP_TWEAKADD is used to compute the Taproot public key that commits to the new state.
Among these, BIP 348 is particularly important for vouchers. It allows Bitcoin scripts to verify a signature on arbitrary data. Without this capability, scripts would have difficulty verifying the digital check Alice signed off-chain.
3. The MIN version relies only on OP_CAT and OP_TWEAKADD but can only implement exit and SPLIT, not vouchers or channel leaves. I
t’s more of an experiment to demonstrate LayerTree’s minimum capability boundary.
4. The CCV version relies on OP_CHECKCONTRACTVERIFY from BIP 443, OP_TX, and BIP 348 for vouchers.
BIP 443 allows UTXOs to carry dynamic state commitments and constrain new outputs to inherit the updated state. It aligns well with on-chain state machines like LayerTree and is also among the versions with the smallest exit volume.
Why It Matters?
LayerTree is less of a product and more of an argument, making the case that Bitcoin could support many self-custodial users on shared outputs, with exits that need no permission or timers, if the network were willing to add the right covenant tools. That connects it to a long-running debate about whether and which covenants Bitcoin should add, and it gives that debate a concrete, measured proposal to examine.
If projects like LayerTree gain traction and interest while other projects that could improve with convenants like Ark, we could see more pressure to push these BIPs forward.
For now, treat it the way you’d treat any new layer-two design. Read the paper, note which numbers are measured and which are modelled, and keep in mind that nothing here can be used on mainnet. The question to watch isn’t whether LayerTree works on paper.
It is whether Bitcoin’s developers and users decide the opcodes it needs are worth adding.
Do your own research.
If you want to learn more about LayerTree, use this article as a starting point. Don’t trust what we say as the final word. Take the time to research other sources, starting with the resources below.
Sources: layertree.tech & https://layertree.tech/paper/main.pdf
