CoinPool

What Is CoinPool?

CoinPool is a proposed multi-party protocol for Bitcoin that allows many users to co-own a single on-chain UTXO while maintaining individual control over their funds. Proposed by Antoine Riard and Gleb Naumenko in 2022, the design aims to improve Bitcoin's transactional scaling and privacy by orders of magnitude.

In traditional Bitcoin usage, every participant needs their own UTXOs, and every transfer requires an on-chain transaction. CoinPool changes this model: a group of participants pools their funds into one shared UTXO, then transfers value among themselves off-chain by cooperatively updating the pool's internal state. Only the creation and final settlement of the pool require on-chain transactions.

The core innovation is combining shared UTXO ownership with guaranteed individual exit rights. Unlike a custodial arrangement where users trust an operator, CoinPool participants can always withdraw their funds unilaterally: the Bitcoin script enforcing the shared UTXO includes exit paths that any participant can trigger without anyone else's permission.

How It Works

CoinPool uses a combination of Taproot trees, Merkle commitments, and pre-signed transactions to manage shared ownership. The protocol operates in two modes: a cooperative fast path for normal operations and a unilateral exit path for when cooperation breaks down.

Pool Creation

Setting up a CoinPool involves several steps:

1. A group of participants agrees to form a pool. Each contributes funds and a public key.
2. The participants construct a shared UTXO locked to a Taproot address. The internal key is an N-of-N MuSig2 aggregate of all participants' keys.
3. A Merkle tree encodes each participant's public key and balance. This tree is committed inside the Taproot address structure.
4. Pre-signed transactions covering all possible exit scenarios are created before the funding transaction is broadcast.

Once the funding transaction confirms on-chain, the pool is live. A single UTXO now represents the combined balances of all participants.

Off-Chain Transfers

Transfers within the pool happen off-chain through cooperative state updates. When Alice wants to pay Bob (both pool members), the process works as follows:

1. Alice proposes a state update that decreases her balance and increases Bob's
2. All pool participants verify and co-sign the new state
3. The old state is invalidated and the new state becomes the current one

These transfers settle instantly among participants and never appear on-chain. The on-chain UTXO remains unchanged: only the off-chain state tracking each member's balance is updated. This is conceptually similar to how Lightning channels update balances off-chain, but extended from two parties to many.

Unilateral Exit

The most critical design property of CoinPool is that any participant can exit the pool at any time without cooperation from others. If other participants go offline or refuse to cooperate, a user can broadcast a transaction that proves their balance via the Merkle commitment and withdraws their funds to a separate UTXO.

The exit mechanism uses the Taproot script path. A participant reveals their Merkle inclusion proof (showing their key and balance are committed in the tree), signs the withdrawal transaction, and the remaining participants' funds move into a new, smaller pool UTXO with the exiting user removed from the Merkle tree.

Required Consensus Changes

CoinPool cannot be built on Bitcoin today. The original proposal requires three consensus changes:

• SIGHASH_ANYPREVOUT: allows signatures that do not commit to a specific input UTXO, enabling rebindable pre-signed transactions that remain valid after pool state changes
• SIGHASH_GROUP: a proposed sighash flag that lets a signature commit to specific outputs while leaving other outputs as wildcards, enabling a participant to authorize their withdrawal without constraining the remaining pool output
• OP_MERKLESUB: a proposed opcode that verifies a Merkle branch was removed from the committed tree, enforcing that a withdrawing user is correctly removed from the pool state

More recently, Salvatore Ingala's OP_CHECKCONTRACTVERIFY (BIP 443) has emerged as a more general-purpose covenant opcode that could also enable CoinPool-style constructions. A proof of concept demonstrated a 2-of-4 unilateral exit using OP_CHECKCONTRACTVERIFY with a script size of 142 bytes, suggesting the approach is viable if the opcode is activated.

CoinPool vs. Payment Channels

Understanding CoinPool's design is easier when contrasted with payment channels, the building block of the Lightning Network:

The key tradeoff is interactivity: payment channels only need two parties online to update state, while CoinPool requires all N participants. If even one member goes offline, cooperative updates stall. The CoinPool authors envision the two approaches as complementary: pool participants could also open Lightning channels, combining CoinPool's on-chain efficiency with Lightning's routing capabilities.

Relationship to Ark and Virtual UTXOs

CoinPool shares conceptual DNA with several related proposals that use shared UTXOs for scaling. Ark takes a similar starting point (pooling users into shared on-chain UTXOs) but introduces a service provider (the Ark Service Provider, or ASP) to coordinate state updates, reducing the interactivity burden on users.

In Ark, each user holds a virtual UTXO (vTXO): a leaf in a transaction tree whose root is the shared on-chain UTXO. Users can unilaterally exit by publishing their branch of pre-signed transactions. CoinPool's Merkle-committed balances serve a similar purpose but use a different mechanism: covenant opcodes enforce exit rights directly in Bitcoin Script rather than relying on pre-signed transaction trees.

Both designs aim to let Bitcoin scale to many more users per on-chain UTXO. For a deeper comparison of these approaches, see the Bitcoin Layer 2 comparison and Ark protocol explainer.

Use Cases

Mass Onboarding

Bitcoin's UTXO model means each user needs at least one on-chain UTXO to self-custody funds. With roughly 7 transactions per second on the base layer, onboarding millions of new users into self-custody is infeasible one UTXO at a time. CoinPool compresses this: a single on-chain UTXO can represent hundreds of users, each with cryptographic proof of their balance and the ability to exit independently.

Privacy Enhancement

When many users share a single UTXO, external observers cannot distinguish individual balances or transfers within the pool. Off-chain state updates leave no on-chain trace, providing a significant privacy improvement over standard Bitcoin transactions. This is similar in spirit to CoinJoin but with ongoing privacy rather than a single mixing event.

Fee Reduction

On-chain fees are paid per transaction, not per user. A CoinPool with 100 participants performs internal transfers at zero on-chain cost. Even exits are cheaper than they would be for 100 separate UTXOs, since the pool amortizes the base transaction overhead. During periods of high fee market congestion, pooled users benefit from dramatically lower costs.

Lightning Integration

CoinPool participants could open Lightning channels from within the pool, combining the on-chain efficiency of shared UTXOs with Lightning's payment routing capabilities. This layered approach addresses Lightning's liquidity fragmentation: instead of each channel requiring its own on-chain UTXO, multiple channels could share a single CoinPool UTXO.

Risks and Considerations

Interactivity Requirements

CoinPool's cooperative mode requires all participants to be online and sign every state update. In a pool of 100 users, a single unresponsive participant blocks all cooperative transfers. While unilateral exits remain possible, frequent non-cooperation degrades the pool over time as members exit and the pool shrinks.

State Management Complexity

Each participant must store and verify the entire pool state, including Merkle proofs for all members. As pool size grows, so does the data each user must manage. Coordinating N-of-N signatures across many participants introduces latency and reliability challenges that two-party channels avoid.

Consensus Change Dependency

CoinPool cannot be deployed without new Bitcoin opcodes and sighash flags. The Bitcoin community's soft fork activation process is deliberately conservative, and none of the required changes (SIGHASH_ANYPREVOUT, SIGHASH_GROUP, OP_MERKLESUB, or the alternative OP_CHECKCONTRACTVERIFY) have been activated on mainnet as of 2026. This makes CoinPool's deployment timeline uncertain.

Unilateral Exit Costs

While any participant can exit without cooperation, doing so requires an on-chain transaction that includes a Merkle proof. These proofs grow logarithmically with pool size, adding witness data and fees. In a worst-case scenario where all participants exit unilaterally at once (for example, during a fee spike), the on-chain footprint could temporarily exceed what individual UTXOs would have required.

Unresolved Research Questions

Several open problems remain. State update coordination at scale, penalty mechanisms for publishing outdated states, and the interaction between different covenant proposals all need further research. The relationship between SIGHASH_GROUP and existing sighash flags also requires careful analysis to avoid introducing new attack surfaces.

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.