Lightning Labs has introduced LayerTree, a proposed non-custodial scaling construction that allows a large number of users to share a single Bitcoin unspent transaction output (UTXO).
Announced on October 15, 2026, via the company’s official X account, the design uses covenants and an off-chain Merkle-sum tree so that one on-chain output can represent balances for up to a million participants. Any user can leave at any time in a single transaction, recipients do not need to remain online, and funds carry no forced expiry.
The proposal is detailed in a technical paper authored by Lightning Labs CTO Olaoluwa Osuntokun.
How LayerTree Enables Constant-Size Exits from Shared Bitcoin Outputs
Bitcoin’s fundamental constraint for widespread ownership is the scarcity of UTXOs: each distinct owner typically requires a separate output, and those outputs consume block space and raise fees. LayerTree addresses this by keeping the ownership record entirely off-chain. Each participant’s balance, keys, and optional lease appear as a leaf in a binary Merkle-sum tree; internal nodes store both a hash of their children and the summed value.
The single on-chain output commits only to the tree’s root. When the output is spent, a covenant script verifies a Merkle proof of the current root, applies a permitted transition (such as an exit or join), and requires the spending transaction to recreate the same output under the correctly updated root. Because the tree itself never becomes a chain of on-chain transactions, an individual exit remains one transaction whose size grows only with the depth of the tree rather than with the total number of members.
According to measurements published with the design, a unilateral exit from a depth-16 tree (65,536 slots) costs roughly 1,020 virtual bytes under the fuller set of proposed opcodes—about nine times a simple single-owner spend but substantially less than the approximately 2,511 virtual bytes required for a comparable exit in an Ark-style tree of pre-signed transactions. With an additional purpose-built Merkle-sum opcode (not yet proposed), the same exit falls to around 540 virtual bytes and grows by only about 10 virtual bytes each time membership doubles.
The operator who maintains the tree cannot seize balances or block exits; the covenant and the owner’s signature on the exit transaction enforce the rules. Joining remains under the operator’s signature, so admission is not guaranteed, but once inside, a user can leave without further permission or a waiting period.
Batch joins of roughly 1,000 participants can reduce the on-chain cost to less than one virtual byte per person. These properties distinguish LayerTree from constructions that require a path of transactions or that force the entire structure on-chain when a single participant becomes unresponsive.
Integrating with the Lightning Network for Offline Receives and Payments
LayerTree is explicitly designed to compose with the Lightning Network, Bitcoin’s primary off-chain payment layer. The Lightning Network enables near-instant, low-fee transfers by moving most activity into bidirectional payment channels that ultimately settle on the base chain only when necessary.
LayerTree treats certain leaves as channel anchors, so a Lightning hub can host many channels inside one shared output rather than one output per channel. Users can receive payments into a funded “credit” leaf via Lightning without staying online; a voucher mechanism allows an issuer to pre-authorize incremental updates that anyone can later redeem, so repeated incoming payments incur no per-payment on-chain cost. Internal transfers within the tree, including those that move value between Lightning channels and ordinary leaves, can likewise remain off-chain until an exit occurs.
This composition addresses a practical limitation of pure channel-based systems: the need for recipients to monitor the chain or rely on watchtowers to prevent counterparties from broadcasting outdated states. Because LayerTree exits carry no timelock and the shared output itself never expires, a user who receives funds through Lightning can later claim them unilaterally even after prolonged inactivity.
Real-world Lightning adoption has already expanded through merchant integrations and remittance corridors; Square’s Lightning-powered checkout, for example, has brought instant Bitcoin acceptance to millions of U.S. sellers, while services such as Chipper Cash have shifted a substantial share of transactions onto Lightning in emerging markets.
LayerTree aims to supply the underlying ownership layer that lets such payment networks scale to far larger user sets without a corresponding explosion in on-chain outputs. Osuntokun’s paper notes that a hub sized by exit throughput, rather than by the number of channels, can occupy a single output, potentially lowering the capital and operational requirements for large Lightning operators.
Opcode Dependencies and Path Toward Broader Bitcoin Adoption
None of the LayerTree transitions run on Bitcoin today. The design compiles to four tiers of already-proposed opcodes, ranging from a minimal set that includes OP_CAT and a point-tweak operation up to the fuller “Great Script Restoration” package together with transaction introspection (OP_TX), OP_CHECKSIGFROMSTACK, and elliptic-curve opcodes.
The specification states that LayerTree introduces no new opcodes of its own; it composes candidates already under discussion. Until those soft-fork changes activate, the construction remains a research and implementation prototype, complete with a Go reference implementation, test vectors, a Lean 4 formalization of the core conservation and exit properties, and measured script sizes.
The proposal arrives amid ongoing work on other Bitcoin scaling approaches, including timeout trees, channel factories, and Ark-style systems. LayerTree’s distinguishing claim is that the cost of sharing is paid primarily at exit rather than at every state update or at forced expiry, and that the exit itself stays a single transaction.
For a tree of one million members (depth 20), the paper and site materials place a solo exit at roughly 1,150 virtual bytes under current opcode assumptions—still one transaction and without a mandatory refresh period. Whether this efficiency is sufficient for mass adoption will depend on fee markets, the eventual activation of the required script capabilities, and the practical willingness of operators to run large trees. The design does not promise free entry or eliminate all coordination; an operator can refuse joins, and grafted subtrees must be verified by participants to avoid empty commitments.
At the same time, the absence of forced timeouts and the ability to receive without remaining online remove two common friction points for long-term holders and for users who interact with Bitcoin primarily through Lightning.
By publishing the full specification, formal arguments, and cost models alongside the announcement, Lightning Labs has placed a concrete, measurable proposal into the public discussion of how Bitcoin can support ownership at population scale while remaining non-custodial and interoperable with existing payment channels.
The next steps will be community review of the scripts and security arguments, further measurement against alternative designs, and, ultimately, decisions by Bitcoin node operators and miners about whether the underlying opcode proposals should proceed. Until then, LayerTree exists as a detailed blueprint rather than a live network feature, illustrating one path by which a single on-chain output might eventually serve as the settlement anchor for millions of independent balances.
Also read: This Indicator Puts Bitcoin Price at $251K by 2030, $2.2M by 2040
