Timeout Tree

What Is a Timeout Tree?

A timeout tree is a construction that allows many users to share a single on-chain UTXO by arranging their individual claims as leaves in a tree of pre-signed transactions. The root of the tree is the only transaction that must appear on the blockchain. All intermediate branches and leaf outputs stay off-chain as long as participants cooperate. After a predetermined expiry period, the tree creator can sweep any unclaimed funds, which provides a natural mechanism for recycling on-chain space.

The concept was introduced by pseudonymous researcher John Law in the 2023 paper Scaling Lightning With Simple Covenants. Law proposed timeout trees as a way to onboard large numbers of casual Lightning Network users through a single Lightning channel factory, without requiring each user to open an individual on-chain channel.

The design addresses a fundamental scaling bottleneck: Bitcoin's limited block space constrains how many channels can be opened or closed per block. By batching many users into one UTXO, timeout trees reduce the per-user on-chain footprint from one transaction to a fraction of one, enabling layer-2 protocols to serve orders of magnitude more users.

How It Works

A timeout tree begins with a coordinator (an operator, LSP, or protocol server) who constructs a tree of transactions and collects signatures from participants before publishing the root on-chain.

1. The coordinator builds a binary tree of transactions. The root spends a single on-chain UTXO. Each internal node produces two child outputs, and the leaves represent individual user balances or payment channels.
2. Participants sign from the leaves upward. Each user signs the branch that leads from their leaf back to the root, confirming their claim on the funds. Because signing proceeds bottom-up, the root cannot be finalized until every leaf is committed.
3. The coordinator broadcasts only the root transaction. The full tree of pre-signed transactions exists off-chain, held by participants and the coordinator.
4. Each non-leaf output includes two spending paths: a cooperative path (requiring signatures from the relevant parties) and a timeout path that lets the coordinator spend the output unilaterally after a set expiry.
5. Before the timeout expires, users must move their funds into a new tree (a process called refresh or rollover). If they do not, the coordinator can sweep the expired outputs.

Tree Structure

The tree follows a Merkle-like binary structure, though it is a tree of transactions rather than a tree of hashes. A tree with depth d can hold up to 2^d user leaves. For example, a tree of depth 20 could theoretically represent over one million users sharing a single on-chain UTXO.

Root UTXO (on-chain)
├── Internal Node A (off-chain, 2-of-2 + timeout)
│   ├── Leaf: User 1 channel (off-chain)
│   └── Leaf: User 2 channel (off-chain)
└── Internal Node B (off-chain, 2-of-2 + timeout)
    ├── Leaf: User 3 channel (off-chain)
    └── Leaf: User 4 channel (off-chain)

Each leaf typically contains a virtual UTXO (vUTXO) or a payment channel between the user and the coordinator. The vUTXO itself is often a 2-of-2 multisig between the user and the operator, with an additional spending path that allows the user to claim funds unilaterally after a separate timelock.

Timeout and Expiry Mechanics

The timeout is the defining feature that separates this construction from a standard channel factory. Every non-leaf output includes a time-bounded spending condition: after the expiry block height or timestamp passes, the coordinator can spend that output without the participants' signatures.

In practice, the expiry is typically set weeks to months into the future. For instance, the Ark protocol uses approximately 30-day expiry windows for its vUTXOs. This gives users a window to transact, refresh, or exit before the tree expires.

The timeout serves dual purposes: it ensures the coordinator can eventually reclaim liquidity even if users go offline permanently, and it limits how long the off-chain state remains valid, reducing the risk of stale or disputed claims.

Unilateral Exit

If a user needs to claim their funds without the coordinator's cooperation, they can publish the chain of pre-signed transactions from the root down to their leaf. This is called a unilateral exit. For a tree of depth d, a unilateral exit requires publishing d transactions on-chain (one per level of the tree).

Unlike channel factories where one offline user can force the entire structure on-chain, timeout trees limit the blast radius: a user only reveals the branch leading to their leaf, leaving the rest of the tree intact.

Timeout Trees vs. HTLC Timeouts in Lightning

Both timeout trees and HTLCs use timelocks, but they serve fundamentally different purposes and operate at different scales:

HTLC timeouts protect individual payments; timeout trees protect the structural integrity of shared UTXO ownership. In systems like SuperScalar, both mechanisms coexist: the timeout tree sets the factory's lifespan, while HTLCs inside the factory's channels secure individual payments.

Use Cases

Lightning Service Provider Scaling

Timeout trees were originally proposed to solve Lightning's onboarding bottleneck. An LSP can onboard thousands of users through a single on-chain transaction by creating a timeout tree where each leaf contains a channel between the LSP and a user. The SuperScalar proposal builds on this by combining timeout trees with Decker-Wattenhofer state invalidation, enabling channel updates within the factory without consensus changes to Bitcoin.

Ark Protocol and vUTXOs

The Ark protocol uses timeout trees as its core batching mechanism. In each round, the Ark server (ASP) creates a timeout tree where each leaf is a vUTXO belonging to a user. Users transact by swapping vUTXOs between rounds, and the server periodically creates new trees. The approximately 30-day expiry on each tree forces users to refresh their vUTXOs, but this also means the server recovers liquidity from inactive accounts automatically. For a deeper exploration of Ark's architecture, see the Ark protocol explainer.

Shared UTXO Ownership

More broadly, timeout trees enable any protocol that needs many parties to share a single UTXO while maintaining individual exit rights. This includes joinpools, coinjoins with delayed settlement, and federated custody schemes where a group pools funds on-chain but manages individual balances off-chain.

Risks and Considerations

Refresh Requirement

The most significant operational burden is the refresh cycle. Users who fail to move their funds to a new tree before expiry lose those funds to the coordinator. This creates an availability requirement: users (or their wallets) must come online periodically. For casual users who may not open their wallet for months, this is a meaningful concern that protocols must address through notifications, automated refresh, or extended expiry windows.

Thundering Herd Problem

If many trees expire around the same time, a large number of users may need to refresh simultaneously. This could create a surge of on-chain transactions competing for limited block space, driving up fees. Worse, a coordinated group could deliberately trigger mass expirations to congest the network, potentially stealing funds from users who cannot get their exit transactions confirmed before the timeout. This denial-of-service vector requires careful staggering of expiry times across trees.

Unilateral Exit Cost

While timeout trees limit the blast radius compared to channel factories, unilateral exits are still expensive. A user in a tree of depth 20 would need to publish 20 transactions to claim their leaf. During periods of high fee market activity, the cost of these transactions could exceed the value of the user's funds, effectively making small balances uneconomical to exit.

Coordinator Trust

The coordinator controls tree creation and the refresh process. While the pre-signed transactions prevent the coordinator from stealing funds before expiry, users depend on the coordinator to create new trees for refresh. A malicious or insolvent coordinator could refuse to create new trees, forcing all users into expensive unilateral exits. This is mitigated by the fact that the coordinator's own liquidity is locked in the tree, creating an economic incentive to cooperate.

Signing Overhead

Creating a timeout tree requires collecting signatures from all participants during construction. For large trees, this coordination overhead can be significant. Each user must be online during the signing round and must verify their branch of the tree before signing. This interactive setup limits the practical size of timeout trees and adds latency to the onboarding process.

Related Concepts

Timeout trees are closely related to several other Bitcoin scaling constructions:

• Channel factories share the goal of batching many channels into one on-chain UTXO but lack a built-in expiry mechanism, which can complicate liquidity management.
• Pre-signed transactions are the building block of timeout trees: each node in the tree is a transaction signed before the root is broadcast.
• Covenants can enforce the tree structure at the consensus level. Proposals like CTV would allow timeout trees to be constructed without interactive signing rounds, reducing the coordination burden.
• OP_CHECKSEQUENCEVERIFY and OP_CHECKLOCKTIMEVERIFY are the opcodes that enforce the timeout conditions within the tree's spending paths.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.