CoinPool: How Shared UTXO Ownership Could Scale Bitcoin 100x

Bitcoin processes roughly 7 transactions per second. At that rate, onboarding the world's 8 billion people would take over 35 years of continuous block production, assuming no one else used the chain for anything. CoinPool addresses this bottleneck with a radical idea: instead of giving every user their own UTXO, let many users share a single one. Each participant retains independent spending authority and can leave the pool unilaterally at any time, without permission from any other member.

Proposed by Gleb Naumenko and Antoine Riard in their 2022 paper, CoinPool is a covenant-based payment pool construction that could theoretically compress thousands of users into one on-chain footprint. The catch: it requires Bitcoin consensus changes that have not been activated, and the coordination demands on participants are steep. This article explains how the protocol works, what it needs to deploy, and how it compares to alternatives that exist today.

What Is CoinPool?

CoinPool is a multi-party off-chain protocol where N users jointly own a single UTXO. Inside the pool, participants can transfer value to each other without broadcasting any on-chain transaction. Every internal transfer updates a shared state that all members agree on. When a user wants to leave, they can exit unilaterally: their share is peeled off the pool UTXO and appears as a standard on-chain output, no cooperation required.

The construction uses Taproot Merkle trees to encode each participant's balance as a leaf. The pool UTXO commits to the root of this tree, and covenant opcodes enforce that any spend must either be a cooperative update (everyone signs) or a valid unilateral exit (one member proves their leaf and removes it from the tree).

Key insight: CoinPool collapses the "space dimension" of Bitcoin: where Lightning collapses the time dimension by batching many payments into a single channel open/close, CoinPool collapses the user dimension by batching many owners into a single UTXO. Peter Todd's covenant review frames this as a complementary scaling vector to payment channels.

How Shared UTXO Ownership Works

The pool UTXO is locked behind an N-of-N MuSig2 aggregate key. All participants must sign to spend it cooperatively. The Taproot tree attached to this output contains one leaf per user, each encoding that user's balance and a spending condition that allows unilateral exit.

The Taproot Merkle Tree

Each user's balance is represented as a Tapscript leaf in the pool's Taptree. The leaf contains:

• The user's public key
• Their current balance
• A spending path that creates two outputs: one paying the user their balance, and another recreating the pool without that user's leaf

This structure means the pool UTXO's script simultaneously encodes every possible exit scenario. A pool of 8 users has 8 tapleaves, each representing a different user's exit path. The Merkle proof for any leaf is O(log N) in depth, meaning a user in a 1,024-person pool needs roughly 10 hashes to prove their position in the tree.

Off-Chain State Updates

When Alice pays Bob inside the pool, all N participants sign a new commitment reflecting Alice's decreased balance and Bob's increased balance. The old state is invalidated, and the new state becomes the canonical version. This mirrors how commitment transactions work in Lightning channels, but extended to N parties.

The critical difference: in a two-party Lightning channel, only Alice and Bob need to sign. In a CoinPool with 100 members, all 100 must sign every state update. This is the fundamental coordination cost that shapes the protocol's practical limits.

The Exit Tree: How Users Leave Without Permission

CoinPool's unilateral exit mechanism is the core of its security model. Any user can leave at any time by revealing their Merkle branch and executing their tapleaf spending path. The exit transaction creates two outputs:

1. A standard output paying the exiting user their balance
2. A new pool UTXO containing the remaining participants, with the exiting user's leaf removed from the Taproot tree

This "peel off" design is what makes CoinPool different from naive shared custody. The remaining pool continues functioning with N-1 members. Their balances are unaffected, and they can still transact off-chain or exit themselves later. If every user exits one by one, the final user simply claims the last UTXO.

Exit cost matters: Each unilateral exit consumes on-chain block space. In a pool of 1,000 users, if everyone exits simultaneously during a fee spike, the on-chain cost could exceed the value of small balances. This is the same stranded UTXO problem that affects Lightning and every other Bitcoin Layer 2. Pool size creates a direct tension between scaling factor and worst-case exit affordability.

Exit Tree Depth and On-Chain Cost

The depth of the Merkle tree determines how much witness data an exiting user must reveal. For a pool of N users, the exit proof contains approximately log₂(N) hashes (each 32 bytes). A 1,024-user pool requires about 10 hashes (320 bytes of witness data), while a 16-user pool needs only 4 hashes (128 bytes).

The exit transaction also needs to include the new Taproot tree for the remaining pool. This means a single exit's on-chain footprint scales with O(log N), which is efficient but not free. In practice, the OP_MERKLESUB opcode handles the tree surgery: it verifies that a specific branch was correctly removed from the committed tree.

What Opcodes Does CoinPool Require?

CoinPool cannot be built on Bitcoin today. The protocol requires three consensus changes, none of which have been activated. This is the single biggest obstacle to deployment.

The authors originally also discussed TAPLEAF_UPDATE_VERIFY (OP_TLUV) as an alternative to OP_MERKLESUB. OP_TLUV would recreate a pool output with the departing user's key and leaf removed. A later proposal, ZmnSCPxj's OP_EVICT, offered yet another approach to the same problem.

Could Newer Covenant Proposals Enable CoinPool?

The covenant landscape has evolved since the original CoinPool paper. Several more general proposals could potentially serve the same role:

• OP_CHECKTEMPLATEVERIFY (CTV, BIP 119) constrains which outputs a transaction can create, enabling pre-committed exit trees
• OP_CHECKSIGFROMSTACK (CSFS, BIP 348) allows signature verification over arbitrary messages, which combined with CTV could provide the flexibility CoinPool needs
• OP_CHECKCONTRACTVERIFY (CCV, BIP 443), proposed by Salvatore Ingala in 2025, is a more general covenant primitive that could enable CoinPool-style constructions along with vaults, Ark, and timeout trees
• OP_CAT could achieve similar Merkle tree manipulation through concatenation, though with more complex scripting

None of these have been activated. The Bitcoin covenant debate continues, with the community still deliberating on which opcode (if any) should be activated first. For a deeper comparison of these proposals, see our covenant activation path analysis.

The Coordination Problem: Why Everyone Must Be Online

CoinPool's most significant practical limitation is its interactivity requirement. Every off-chain state update requires signatures from all N pool members. If even one participant is offline, the remaining members cannot update the pool state. They can still exit unilaterally, but they cannot process new internal transfers.

What Happens When a Member Goes Offline

Consider a pool of 50 users. If user #37 loses internet connectivity, the other 49 users are stuck: no internal transfers can be processed until #37 comes back online or is evicted through a unilateral exit. Eviction requires an on-chain transaction, partially defeating the purpose of the pool.

This creates a practical ceiling on pool sizes. The probability that at least one member is offline at any given moment increases with pool size. For a pool of 1,000 users, achieving simultaneous online presence is unrealistic for consumer wallets that run on mobile phones. The BitMEX Research team's CoinPool FAQ noted that every action except withdrawal requires cooperation from all pool users.

Possible Mitigations

Several approaches could reduce the coordination burden:

• Smaller pools (8 to 32 users) reduce the chance of a single offline member blocking updates
• Delegated signing lets users pre-authorize a semi-trusted party to sign on their behalf
• Timeout-based eviction would automatically remove inactive members after a grace period, though this requires careful design to avoid griefing
• Hierarchical pools could nest smaller subpools inside a larger tree, limiting the blast radius of an offline member

Each mitigation introduces its own tradeoffs. Delegated signing weakens self-custody guarantees. Timeout eviction may force users out unfairly. Hierarchical structures add protocol complexity. The CoinPool authors acknowledged these challenges, estimating that mature payment pools would likely take about a decade of engineering effort.

How CoinPool Compares to Other Shared UTXO Proposals

CoinPool is not the only approach to shared UTXO ownership. Several related proposals tackle the same problem with different tradeoffs. Understanding the landscape helps evaluate where CoinPool fits in the broader scaling picture.

CoinPool vs Ark

Ark solves the coordination problem by introducing an operator (the Ark Service Provider) who coordinates rounds of virtual UTXO creation. Only the operator and transacting parties need to be online for a transfer, not every pool member. The tradeoff is that Ark's vTXOs expire after approximately four weeks and must be refreshed, creating ongoing on-chain costs. CoinPool has no such expiration: once you're in the pool, you stay indefinitely without refreshing.

Ark's biggest advantage is that it works on Bitcoin today without any soft fork, though it would benefit from covenant opcodes like CTV or CCV. CoinPool is strictly dependent on consensus changes that have no activation timeline.

CoinPool vs Channel Factories

Channel factories let a group of users open multiple Lightning channels from a single on-chain transaction. Research from Burchert, Decker, and Wattenhofer estimated approximately 90% on-chain cost savings for a 20-user factory with 100 intra-group channels. Like CoinPool, factories require all members to cooperate for updates. Unlike CoinPool, factories produce individual payment channels that can then operate independently: once the factory is set up, two-party channel updates do not need the full group's participation.

CoinPool is more flexible in that it supports direct intra-pool transfers without the overhead of channel routing, but it pays for this with stricter coordination demands.

Pool Size Tradeoffs: Scaling Factor vs Exit Cost

The scaling potential of CoinPool is directly proportional to pool size. Larger pools mean more users per UTXO, which means fewer UTXOs needed to serve the global population. The original paper suggested pools of 1,000 users, which would require approximately 7.9 million pool UTXOs to onboard 7.9 billion people.

But pool size creates tension across multiple dimensions:

Scaling Arithmetic

Bitcoin's UTXO set currently contains roughly 180 million entries. If each UTXO represented a 1,000-person pool, that would serve 180 billion user slots: far more than the world's population. Even at a more conservative 100-person pool size, the existing UTXO set capacity would cover 18 billion user slots.

The theoretical scaling factor is straightforward: N users per UTXO means Nx fewer on-chain transactions for onboarding. A 100-person pool is a 100x scaling improvement. A 1,000-person pool is 1,000x.

The Exit Cost Ceiling

Larger pools create deeper Merkle trees and larger exit transactions. More importantly, if a pool fractures (many users exiting at once), the on-chain cost can be substantial. Consider the worst case: a 1,000-person pool where everyone exits unilaterally during a period where Bitcoin fee rates are elevated. Each exit transaction requires block space, and 1,000 exits create significant mempool congestion.

This creates a practical ceiling on pool sizes. Pools of 8 to 32 users are likely the realistic range for consumer applications, where the coordination burden is manageable and the exit cost remains affordable even during fee spikes. A 32-user pool still provides a 32x scaling improvement, which is meaningful but far from the theoretical 1,000x.

Can CoinPool Actually Scale Bitcoin 100x?

The honest answer: theoretically yes, practically not yet, and possibly not in its current form.

CoinPool's theoretical scaling is real. Sharing UTXOs among many users does compress on-chain footprint proportionally. The math works. But three practical barriers stand between the theory and a deployed system:

1. No required opcodes have been activated, and the Bitcoin community has not reached consensus on any soft fork covenant proposal. The ossification debate makes the timeline uncertain.
2. The N-of-N signing requirement makes large pools impractical for consumer wallets. Mobile users go offline frequently, and any offline member blocks the entire pool. Pools would likely need to stay small (under 32 members) to maintain liveness.
3. The protocol is still at the research stage. No reference implementation exists, no testnet deployment has been attempted, and the authors themselves estimated that mature payment pools would require approximately a decade of engineering effort.

Comparing CoinPool to Lightning's trajectory is instructive. Lightning was proposed in 2015 and took years of engineering before reaching production quality. CoinPool would need not only similar implementation work but also a soft fork activation, which adds a social consensus step that Lightning never required.

What Works Today Without a Soft Fork

CoinPool represents an important direction for Bitcoin scaling research, but it is not the only path to shared-infrastructure efficiency. Several protocols achieve similar goals using Bitcoin's current consensus rules.

Spark, for example, achieves many of CoinPool's practical objectives through a different architecture. Instead of covenant-enforced shared UTXOs, Spark uses a statechain model with FROST threshold signatures. Users hold Bitcoin in two-of-two multisig arrangements with a distributed operator set. Transfers happen off-chain by rotating key shares rather than updating a shared Merkle tree. Every user can exit unilaterally using pre-signed transactions, without any covenant opcode.

The key difference: Spark requires no soft fork and is live on Bitcoin mainnet today. The tradeoff is a 1-of-n trust assumption on the operator set (at least one operator must behave honestly during transfers), whereas CoinPool's covenant-based design would be fully trustless. For users who value a working system over theoretical perfection, Spark represents a deployable alternative that achieves instant, low-cost Bitcoin transfers without waiting for consensus changes.

Developers building Bitcoin applications can integrate Spark today through the Spark SDK. For a broader view of how different Layer 2 approaches compare, see our Bitcoin Layer 2 comparison.

The Road Ahead for Shared UTXO Protocols

CoinPool's contribution to Bitcoin is conceptual as much as practical. It formalized the idea that UTXO sharing could be a first-class scaling primitive, not just a privacy technique. That framing has influenced later proposals: Ark, timeout trees, and BIP 443's design all draw on insights from the CoinPool paper.

If Bitcoin does activate covenant opcodes (whether CTV, CCV, or something else), CoinPool or a successor construction could become viable. The protocol's pure trustlessness and lack of expiration windows give it theoretical advantages over operator-coordinated designs. But reaching that future requires solving the covenant activation question, the interactivity problem, and a substantial engineering effort.

In the meantime, the Bitcoin scaling landscape is not standing still. Protocols like Spark, Ark, Liquid, and Lightning continue to evolve. The question is not whether shared UTXO ownership will eventually come to Bitcoin, but whether it will arrive through covenant-enforced pools like CoinPool or through alternative architectures that sidestep the consensus change requirement entirely.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.