Author: 798.eth
Lightning Labs co-founder Olaoluwa Osuntokun recently released a new Bitcoin scaling design called LayerTree.
It proposes a fairly radical idea: allowing thousands, or even millions, of users to share a single Bitcoin UTXO, while each user retains independent ownership of their funds and the ability to unilaterally exit.
That sounds somewhat contradictory.
If a million people each hold Bitcoin, that usually means a million UTXOs are needed on-chain. If the money is pooled on an exchange, it is indeed possible to keep only a small number of UTXOs, and internal transfers can be completed instantly, but users can only trust the exchange's database.
LayerTree tries to find a new position between the two.
Only one UTXO is stored on-chain. How much Bitcoin each person owns is recorded in an off-chain Merkle Sum Tree. The operator is responsible for maintaining day-to-day service, but cannot arbitrarily modify user balances, nor can it prevent existing users from withdrawing their money back on-chain.
How one tree represents everyone's balances
In LayerTree, each user has a leaf node.
The leaf node 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 sum of the balances and the hash of its two child nodes, ultimately forming a single tree root.
Suppose there are four people in the tree:
Alice has 5 BTC, Bob has 3 BTC, and Carol and David each have 1 BTC.
The shared UTXO on-chain holds a total of 10 BTC. The tree root then commits to how much balance each of the four people owns, and that all balances add up to exactly 10 BTC.
If anyone modifies a leaf node, the tree root changes. If someone tries to add balance out of thin air, the root node's amount validation will fail.
The Bitcoin chain does not need to store the entire tree, only this root, along with the UTXO corresponding to the total balance in the tree.
This is equivalent to compressing the property records of a large number of users into a single cryptographic commitment.
How users exit individually
When Alice wants to exit, she does not need approval from the operator, nor does she need other users to be online.
She only needs to submit her leaf node, the Merkle proof from the leaf node to the tree root, and her signature.
The Bitcoin script verifies that Alice is indeed in this tree, confirms that she owns the corresponding balance, and then completes two things in one transaction:
First, pay Alice's balance to the exit address she specifies.
Second, delete Alice's leaf node and place the remaining funds into a UTXO that commits to the new tree root.
Whether there are one hundred people or one million people in the tree, Alice only needs to broadcast one exit transaction.
What LayerTree calls O(1) exit means that the number of transactions required to exit is always one. The size of the Merkle proof still grows with the number of members, roughly as O(log N).
This design compresses a large number of users into one UTXO under normal conditions, while preserving an on-chain escape hatch under abnormal conditions.
Two transfer methods in LayerTree
If users modify the tree root on every transfer, all transactions still have to be posted on-chain one by one, and the scaling effect would be very limited.
Therefore, LayerTree moves everyday payments off-chain and mainly provides two methods: channel leaf and voucher.
Channel leaf: putting a Lightning channel into a leaf node
A leaf node can represent a Lightning channel between a user and the operator.
The channel's funding output does not temporarily appear on-chain as a separate UTXO; it is included in the shared output of the entire LayerTree. When users pay each other, ordinary Lightning HTLCs are forwarded through the operator.
During the payment process, LayerTree's tree root remains unchanged, and no on-chain transaction is generated.
Therefore, channel leaf payments can be close to ordinary Lightning in speed, usually completing within a few seconds. The operator acts as a routing node here, while LayerTree is responsible for compressing the on-chain UTXOs required by the channels.
It is much like a large Lightning hub that occupies only one output on-chain.
Voucher: a digital check that can be cashed out on-chain
The more creative part of LayerTree is the voucher.
A voucher can be understood as a digital check issued by a user, with Bitcoin script providing the ultimate enforcement capability.
Suppose Alice has 100,000 sats in her leaf node, and she wants to pay Bob 10,000 sats.
Alice does not need to immediately modify the entire tree. She only needs to sign a message stating which LayerTree this voucher belongs to, which leaf node the funds come from, what kind of new leaf node Bob will receive, the payment amount, and the current state sequence number of Alice's leaf node.
Alice sends the signed voucher to Bob, and the off-chain payment is complete.
This process involves only signatures and network transmission, and its speed can approach that of an internal exchange transfer.
The key difference is that what Bob receives is not just a balance record in the operator's database. He receives a payment instruction that can be submitted to Bitcoin script for execution.
If Alice or the operator stops cooperating, Bob can submit the voucher on-chain himself. The LayerTree contract will deduct the corresponding amount from Alice's leaf node and create a new leaf node for Bob.
This entire process is called CLAIM.
Alice does not need to sign again, and the operator cannot prevent Bob from cashing out.
Why a voucher can only be used once
Each LayerTree leaf node has a state sequence number, called seq.
Suppose Alice's current seq is 7, and the voucher she signs is explicitly bound to seq 7.
When a voucher is cashed out, Alice's balance decreases, and seq increases from 7 to 8. All old vouchers bound to seq 7 then become invalid.
This prevents the same check from being cashed out repeatedly.
If Alice frequently pays Bob, she also does not need to create a separate voucher each time.
For the first payment of 10,000 sats, Alice can sign a voucher with a cumulative amount of 10,000 sats. For a second payment of 20,000 sats, she can sign a new voucher with a cumulative amount of 30,000 sats.
Bob only needs to keep the latest one.
Hundreds or thousands of small payments can be compressed into a single proof representing the final cumulative balance. As long as both parties continue to cooperate, there is absolutely no need to write every payment into a Bitcoin block.
Vouchers cannot eliminate credit risk
A voucher has a real signature and an on-chain path to cash out, but before it is cashed out it still carries the issuer's credit risk.
Suppose Alice's leaf node has only 100,000 sats.
She can issue Bob a voucher for 80,000 sats, and at the same time issue Carol another voucher for 80,000 sats.
The signatures on both vouchers are real, but Alice's balance cannot cover them both at the same time.
Bitcoin script can prevent excess funds from being cashed out, but it cannot prevent Alice from signing multiple off-chain proofs exceeding her balance. In the end, who gets the money may depend on who completes the cash-out first.
Alice may also update her leaf node through other legitimate operations, causing seq to increase. Vouchers on the old state will then become invalid.
Therefore, a voucher that has not yet been settled is much like a traditional check:
The signature can prove who issued it, the holder can attempt to cash it, but the account balance may be insufficient, and multiple checks may also compete for the same balance.The recipient needs to pay attention to the payer's available balance, current seq, unsettled vouchers, leaf node lease term, and the payer's creditworthiness. When dealing with strangers or large payments, the recipient may choose to cash out immediately. For small, high-frequency payments between long-term partners, they can continue to accumulate off-chain.
The LayerTree official website also clearly states that the recipient should treat a voucher as credit until it is cashed out or settled through other means.
This credit risk is the price paid for the efficiency of vouchers.
Why design vouchers at all
Since credit risk exists, why not use Lightning channels for everything?
Because the structure of vouchers is simpler and more flexible.
It does not require the two paying parties to establish a separate channel in advance. It can be issued directly by any leaf node owner, can be cumulatively updated multiple times, and can also serve as a settlement credential between LayerTree and Lightning.
LayerTree has designed a credit leaf to receive payments from Lightning.
After the operator receives a Lightning payment, it can use a leaf node funded by itself to issue a new cumulative voucher to the recipient. The recipient can continue to hold it, or cash it out on-chain themselves when necessary.
The basic flow has a brief trust window: the operator has already received the Lightning payment, but has not yet issued a voucher to the recipient. The paper also designs a pending pair, using hash locks, pre-signed vouchers, and a settlement window, so that the recipient first obtains an executable credential, and then releases the preimage of the Lightning payment.
In this structure, the voucher becomes a bridge between Lightning payments and shared UTXO balances.
It is especially suitable for high-frequency small payments, salary streams, content payments, long-term service settlement, and scenarios where the operator periodically settles in batches. Daily state only requires exchanging signatures, while on-chain redemption is retained as a tool for dispute handling and final settlement.
Which Bitcoin upgrades does LayerTree depend on
LayerTree currently cannot run on the Bitcoin mainnet.
It requires covenants, that is, allowing a UTXO to impose constraints on how it can be spent in the future. For example, the script must ensure that after a user exits, the remaining funds re-enter an output committing to the new tree root, and cannot be taken by an arbitrary address.
The project has designed four combinations of opcodes.
The FULL version depends on BIP 441, BIP 440, OP_TX, BIP 348, and a set of elliptic curve opcodes.
BIP 441 restores some previously disabled scripting capabilities and supports more flexible data and numeric processing. BIP 440 provides a computation budget for these variable-cost operations.
The MID version depends on BIP 347's OP_CAT, OP_TX, BIP 348's OP_CHECKSIGFROMSTACK, and BIP 449's OP_TWEAKADD.
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 calculate the Taproot public key committing to the new state.
Among these, BIP 348 is especially important for vouchers. It allows Bitcoin scripts to verify a signature over arbitrary data. Without this capability, it would be difficult for scripts to verify the digital check that Alice issues off-chain.
The MIN version depends only on OP_CAT and OP_TWEAKADD, but can only implement exit and SPLIT, and cannot support vouchers and channel leaves. It is more like an experiment demonstrating the minimum capability boundary of LayerTree.
The CCV version depends on BIP 443's OP_CHECKCONTRACTVERIFY, OP_TX, and BIP 348 prepared for vouchers.
BIP 443 allows a UTXO to carry a dynamic state commitment and constrains new outputs to inherit the updated state. It fits very well with an on-chain state machine like LayerTree, and is also the option with the smallest exit size among the four schemes.
However, none of these BIPs have yet been activated on the Bitcoin mainnet.
"Millions of people sharing one UTXO" also has an additional prerequisite
The version with the most impressive performance in LayerTree's promotion also depends on a dedicated opcode called OP_MERKLESUMUPDATE.
It can verify a Merkle Sum proof and directly calculate the new tree root after replacing a leaf node.
With it, for a LayerTree containing 65,536 members, a single-person exit takes about 540 vB. Each time the number of members doubles, the exit transaction increases by only about 10 vB.
But OP_MERKLESUMUPDATE is currently only a design and simulated implementation in the project repository. It has not yet become a formal BIP, nor has it entered the Bitcoin upgrade process.
If only existing opcode proposals are used, the exit cost at a scale of 65,536 people is about 908 to 1,473 vB.
So "one tree carrying millions of people" holds in terms of cryptographic structure, but its efficient implementation still depends on Bitcoin scripting capabilities beyond the current BIPs.
Can it solve large-scale bank runs
LayerTree can greatly compress on-chain usage under normal conditions, but it cannot increase the capacity of Bitcoin blocks themselves.
All state updates of the same tree must spend and recreate the same shared UTXO, so individual exits need to be executed in a queue.
According to the project's own estimates, if 65,536 users exit separately from the same tree, it would take about 2,622 blocks, nearly 18 days.
Actual deployment requires distributing users across many smaller trees, while using batch joins, batch settlement, and batch exits.
This also illustrates LayerTree's design goal: keep the vast majority of normal activity off-chain, and reserve limited on-chain space for final settlement and exception handling.
The significance of LayerTree
LayerTree still has a clear operator.
The operator is responsible for admitting users, maintaining services, routing payments, and organizing batch updates. It can reject new users, and it can also stop providing real-time services. A single LayerTree is therefore not fully decentralized.
It is more appropriately called a non-custodial shared UTXO system.
The operator controls the service entrance, while users control the right to exit funds. The operator may shut down, and may also refuse service, but according to the protocol design, it cannot arbitrarily take away the balances in users' leaf nodes.
The most noteworthy part of LayerTree is that, beyond ordinary UTXOs, Lightning channels, and custodial databases, it demonstrates another form of funds:
a digital check that can circulate instantly, continuously accumulate, and ultimately be enforced for redemption by Bitcoin scripts.
It does not eliminate credit risk, nor does it break through the upper limit of block space.
It confines credit to the off-chain payment stage, while preserving for the recipient a permissionless on-chain execution path.
This is a quite creative approach to Bitcoin scaling.