The protocols we studied explore different ways for participants to share control over a Bitcoin output or transfer the right to spend it without recording every change on-chain. They differ in how they represent those changes and in how participants can enforce their claims on-chain. Designing ways to update claims offchain while preserving a path to enforce them through the blockchain is one of the most interesting problems in Bitcoin protocol design.
From October 19 to 23, we gathered at Casa21, Vinteum's hackerspace in São Paulo, for yet another week-long Deep Dive, this time focused on a selection of offchain protocols commonly discussed under the Bitcoin Layer 2 umbrella. The goal was to understand how different protocols allow users to transact without recording every payment on Bitcoin's blockchain, while preserving some ability to recover their funds independently. We began with payment channels and traced the ideas that helped us make sense of Ark, including channel factories, eltoo, joinpools, and CoinPool. We then examined Ark itself before turning to statechains, which take a different approach to transferring control over a Bitcoin output.
These protocols have different architectures, cryptographic constructions, and security assumptions. But as we worked through their specifications and filled whiteboards with transaction graphs, a common structure began to emerge: every offchain payment changes who is entitled to spend some bitcoin, the difficult problem is making that change enforceable without immediately recording it on the blockchain.
That became the central question of our week.
What makes something a Bitcoin Layer 2?
Bitcoin's blockchain is a shared record of transactions. Each transaction consumes existing outputs and creates new ones, updating the set of coins that can be spent in the future. This gives Bitcoin an unusually strong property: anyone can independently verify the history of ownership without trusting the participants involved. But every on-chain transaction also occupies block space.
Layer 2 protocols try to loosen the relationship between economic activity and on-chain transactions. They aim to reduce the amount of on-chain data needed to support economic activity, allowing multiple transfers to take place without recording each one on Bitcoin’s blockchain. In his review of covenant-dependent Layer 2 protocols, Peter Todd describes this as collapsing two dimensions of Bitcoin's on-chain footprint. Payment channels allow many transactions to take place over time using one funding output. Shared-UTXO constructions go further by allowing several users to share the same on-chain output. The scaling benefits are fairly intuitive; the security requirements are less so.
There is no universally accepted definition of what qualifies as a Bitcoin Layer 2. Todd proposes a particularly strict one: no one should be able to profitably steal funds within the system, after accounting for its own costs and penalties. Under this definition, some systems commonly described as Layer 2s, including statechains, do not qualify because the operator can steal funds by violating the protocol. We found this framework useful, but did not use it as a boundary for our discussion. We wanted to examine the technical mechanisms these protocols use and make their additional trust assumptions explicit, including those that fall outside Todd’s definition.
One property remained central throughout the week: participants should have a way to exit the protocol and recover their funds on-chain without relying on the continued cooperation of an operator or counterparty, subject to the security assumptions and deadlines of the particular construction. This ability is deemed as a desired feature for Todd, not a requirement. For us, however, this aspect became central and gave us a useful framework for examining the protocols.
The problem of obsolete states
In offchain Bitcoin protocols, the blockchain anchors the funds while an offchain protocol tracks how participants’ claims to them evolve. Depending on the design, an update might change channel balances, transfer control of a UTXO, or create a new set of virtual outputs. These evolving arrangements are often described as protocol states.
To make the problem concrete, consider a simple payment channel. Alice and Bob lock 1 BTC into a jointly controlled 2-of-2 multisig output and begin transferring value between themselves offchain. Initially, Alice owns 0.7 BTC and Bob owns 0.3 BTC. After a payment, their balances become 0.5 BTC each.
We can describe the two states as:
- State 1: Alice has 0.7 BTC; Bob has 0.3 BTC.
- State 2: Alice has 0.5 BTC; Bob has 0.5 BTC.
In this example, the funding output on the blockchain remains unspent from the perspective of the network. Their balances and ownership change exist only in information exchanged between Alice and Bob, usually including presigned Bitcoin transactions that can eventually distribute the funds on-chain.
If everyone cooperates, there is no problem. But Alice might try to broadcast a transaction corresponding to State 1, claiming the larger balance she held before paying Bob. The Bitcoin network does not know that Alice and Bob agreed on a newer state. An older transaction may still be valid under consensus rules.
This example raises three recurring design challenges. First, a protocol needs a state-transition mechanism: some procedure for establishing a new allocation of spending rights without immediately recording it on-chain. Second, it needs unilateral enforcement: participants must possess sufficient information, typically transactions and signatures, to enforce their claims on-chain if the second layer protocol stops functioning cooperatively. Third, it needs conflict resolution: a way to prevent an obsolete state from displacing a newer one.
The third requirement is particularly subtle. An old presigned transaction does not automatically become invalid simply because the participants agree on a newer transaction. Bitcoin consensus does not know about their offchain agreement. Some protocols solve this by making newer transactions capable of superseding older ones. Others arrange timelocks so that the newest owner can act first.
Understanding those mechanisms became a useful way to compare otherwise very different protocols. We were already familiar with Lightning's penalty-based commitment mechanism, so we left most of Lightning for a dedicated future Deep Dive. We began instead with eltoo, whose proposed transaction structure gave us a concrete way to explore the issues raised by obsolete states.
Eltoo: superseding states instead of punishing participants
In 2018, Christian Decker, Rusty Russell, and Olaoluwa Osuntokun proposed eltoo: A Simple Layer2 Protocol for Bitcoin, a payment-channel construction that replaces Lightning's penalty mechanism with a way for newer states to supersede older ones. In penalty-based channels, participants exchange revocation information as they update their balances. If one later broadcasts an obsolete commitment transaction, the counterparty can use that information to claim the channel funds as punishment.
Eltoo takes a different approach: rather than punish someone for publishing an old state, it lets the most recent state replace it. To accomplish this, eltoo separates a channel state into two transactions. An update transaction establishes the current state through a shared output that can either be spent by a newer update or, after a delay, settled. A settlement transaction spends that output and distributes the funds according to the balances associated with the state.
The key idea is that a newer update can be rebound to spend the output of any older update. The construction achieves this through a proposed signature-hash mode, now associated with SIGHASH_ANYPREVOUT (BIP 118), which allows signatures not to commit to the specific outpoints being spent.
But if transactions can be rebound to earlier outputs, what prevents an old state from replacing a newer one? Eltoo uses an ordering encoded in the transactions' locktime fields. The spending conditions enforce that an update must carry a higher state number than the output it replaces. The locktime represents a state counter using values that are already valid with respect to Bitcoin's time rules, rather than introducing an actual waiting period. Meanwhile, OP_CHECKSEQUENCEVERIFY imposes a relative delay on settlement, giving the other participant time to publish a newer update.
We spent a substantial part of our first afternoon reconstructing these transaction pairs and the corresponding Bitcoin Scripts. What initially looked like a fairly small change to Lightning's commitment mechanism turned out to depend on a careful interaction between signature-hash behavior, absolute locktimes, relative locktimes, and the authorization keys assigned to each state. Eltoo offers an elegant answer to the obsolete-state problem, but it depends on consensus functionality that Bitcoin does not currently support. Yet, it’s particularly useful as a conceptual building block for understanding other proposals.
Tracing the ideas behind shared-UTXO protocols
If two people can hold an offchain agreement backed by one Bitcoin output, why not three, ten, or a thousand? Exploring that question led us through payment pools, channel factories, and different ways of coordinating claims to a shared UTXO.
One of the threads we followed began with Jeremy Rubin’s presentation on OP_COSHV at SF BitDevs in May 2019. In the discussion that followed, Greg Maxwell explored a related possibility: a group could jointly hold a Bitcoin output, update its members’ balances through a transaction tree, and let participants exit individually. He described it as a “rolling CoinJoin” and later as a “join-pool.”
This early sketch helped us see how covenant ideas could support a shared output with evolving participant balances. A later and more developed proposal we studied was CoinPool: Efficient offchain Payment Pools for Bitcoin, by Antoine Riard and Gleb Naumenko. CoinPool explores how participants could maintain balances within a shared Bitcoin output, make offchain payments, and withdraw independently.
Moving from a two-party channel to a multiparty pool raises new challenges. How can one participant withdraw without requiring everyone else to cooperate in constructing an entirely new set of transactions? How can the protocol ensure that the withdrawing participant receives the right amount while preserving the funds and exit options of everyone else?
The CoinPool proposal explores additional scripting and signature capabilities, including SIGHASH_GROUP and OP_MERKLESUB, alongside SIGHASH_ANYPREVOUT. These extensions aim to support transaction updates involving selected participants and preserve the constraints needed to enforce their claims. They illustrate an important challenge in multiparty protocols: it is not enough to specify the next valid global state. Participants also need efficient ways to enforce their individual claims without requiring everyone else to cooperate in rebuilding the remaining transaction structure.
We found the ideas compelling, but struggled to reconstruct all the proposed contracts from the paper alone. It gives a useful architectural picture while leaving some scripts and transaction-tree construction less explicit than we would have liked.
We then turned to an earlier proposal: Scalable Funding of Bitcoin Micropayment Channel Networks by Conrad Burchert, Christian Decker, and Roger Wattenhofer, published in 2018. The paper introduces channel factories, which let several participants jointly fund and rearrange payment channels while amortizing the on-chain funding cost among them.
Its hierarchical arrangement of presigned transactions was especially interesting. The paper also drew on Decker and Wattenhofer’s earlier work on duplex micropayment channels, where decreasing timelocks help establish priority among successive offchain states. Channel factories are a conceptual predecessor of several ideas that appear in later shared-UTXO protocols. The channel-factory paper is primarily architectural, so we could not treat it as an implementation-level specification of every transaction and signature exchange.
These proposals do not form a single, direct line of descent to Ark. Together, they helped us recognize a recurring challenge across different designs: sharing an on-chain UTXO is not, by itself, the hard part. The challenge is coordinating changes to participant's individual claims while preserving an independently enforceable exit path for each of them.
With those connections in mind, we turned to Ark.
Ark: a virtual transaction tree
Ark approaches the shared-UTXO problem through transaction trees that represent individual claims to pooled funds. Following Burak's original proposal, different constructions have explored how to coordinate these claims. We focused primarily on the covenantless family of constructions, commonly called clArk, which uses multisignature arrangements and presigned transaction trees to operate under existing Bitcoin consensus rules.
Implementations such as Arkade, developed by Ark Labs, and Bark, developed by Second, explore different ways to put these ideas into practice. We focused on the building blocks behind them: how transaction trees represent users’ claims, how those claims are transferred or refreshed, and what makes them enforceable on-chain.
A batch transaction creates an on-chain output that funds the root of a virtual transaction tree. offchain branching transactions divide the value among participants until the leaves represent individual claims. Ark calls these claims VTXOs, or virtual UTXOs. A VTXO is not a new Bitcoin primitive: it is an output of an offchain Bitcoin transaction, backed by the chain of transactions and signatures needed to bring it on-chain.
In the cooperative case, the virtual transactions remain unpublished. To exit unilaterally, a participant can broadcast the transactions along their branch of the tree and, after the applicable timelocks, spend the resulting output. Understanding this required considerably more than looking at a diagram of a tree. We filled several whiteboards following the actual transactions involved in entering an Ark, constructing new trees, refreshing VTXOs, making payments, and leaving the system.
The funding output includes a timelocked spending path that allows the Ark Server to reclaim the remaining funds after expiry. Users must therefore refresh their VTXOs into a new batch or bring their claims on-chain in time to avoid the operator's sweep paths. Refreshing exchanges an expiring VTXO for a new one with a later expiry. We also examined the covenant-based hArk and Erk constructions, which explore ways to simplify signing and reduce interactivity or enable offline refreshes. We left a more detailed reconstruction of those designs for a future Deep Dive dedicated to covenant opcodes.
One particularly interesting mechanism we examined is the combination of forfeit transactions and connectors. Suppose Alice holds an old VTXO and participates in a new round to obtain a replacement. During the round, the operator and participating users coordinate the construction of a new transaction tree, funded by a batch transaction that will be published on-chain. The operator must ensure that Alice cannot redeem both her old VTXO and her new one. Alice, on the other hand, must ensure that she cannot lose her old claim if the batch transaction never confirms.
The forfeit transaction spends Alice's old VTXO and a connector output derived from the new batch transaction. This makes the exchange conditional: if the new batch transaction confirms, the operator obtains an enforceable way to prevent Alice from redeeming her old claim; if it never confirms, the forfeit cannot be confirmed either, because it depends on an output derived from that transaction. The construction is described particularly well in Elle Mouton's articles on VTXOs and transaction trees and forfeit transactions and connectors. We found ourselves repeatedly returning to those diagrams while building our own transaction graphs on the boards.
Ark also supports out-of-round payments, which allow users to transact without waiting for the next round. At a high level, a VTXO owner and the operator cooperate to sign a transaction spending an existing VTXO into a new one for the receiver. The resulting transaction can remain offchain, becoming part of the receiver's exit history. But the security properties differ from those of a VTXO established directly in a confirmed round.
The receiver can respond to a previous holder's attempt to redeem an ancestor VTXO by getting the appropriate descendant transaction confirmed before the relevant timeout. However, a previous holder and the Ark Server could collude to authorize a conflicting cooperative spend. This introduces an additional trust assumption until the receiver exchanges the VTXO for a fresh one in a confirmed batch. The discussion is covered in the third article of Mouton's series, Out-of-Round Transactions.
By the end of our Ark discussions, the boards were covered with transaction boxes, arrows connecting inputs and outputs, timelock conditions, and competing spending paths. The exercise made an important distinction visible. An Ark payment is not merely a change to a balance stored by an operator. It creates or exchanges Bitcoin transaction claims whose enforceability depends on the structure of the presigned transactions, their scripts, and their relationship to transactions that may eventually confirm.
Statechains: transferring the right to spend a UTXO
Ark creates offchain outputs backed by transaction trees. Statechains explore a rather different idea: what if the signing arrangement controlling a Bitcoin UTXO could change hands without spending the UTXO on-chain? We began with Ruben Somsen's 2018 paper, Statechains: offchain Transfer of UTXO Ownership. In the original construction, an on-chain output is controlled cooperatively by a statechain operator and a special transitory key.
When Alice transfers the coin to Bob, she passes the transitory private key to him, while the protocol establishes a newer recovery state allowing Bob to claim the funds on-chain. Of course, Alice might keep a copy of the private key. Simply handing over a secret does not make the previous owner forget it. Somsen uses eltoo to ensure that the new owner's recovery state can supersede an older owner's state. This does not prevent the operator from colluding with a previous owner to sign a conflicting spend. The operator also participates in the ownership-transfer process and maintains a public record of the transfers, making certain kinds of misbehavior detectable.
This design illustrates another approach to offchain payments. Rather than create a new transaction output to represent every transfer, the system changes who can exercise control over an existing output. The original construction relies on functionality such as SIGHASH_ANYPREVOUT, so we continued with statechain designs intended to work with Bitcoin's current consensus rules.
Spark: key rotation and timelock priority
Spark takes the statechain idea in a different direction, using distributed signing and key-share updates to transfer ownership. It combines these mechanisms with presigned transaction trees, a structure we also encountered in Ark, allowing funds to be split into smaller outputs for payments of varying amounts. Each leaf's output requires the current owner's participation alongside a threshold of operators, using a signing scheme adapted from FROST. When ownership changes, the parties update their private-key shares while preserving the same aggregate public key. The Bitcoin output itself does not change.
Assuming the operators erase their obsolete shares, the previous owner can no longer use the old signing arrangement to produce new signatures with them. Distributing the signing authority across operators reduces the dependence on a single service, although the construction still makes assumptions about operator behavior.
But we quickly identified a second problem: rotating keys does not invalidate signatures that already exist. If a previous owner possesses a valid presigned recovery transaction, Bitcoin will continue to accept that signature regardless of whether the corresponding private-key shares have subsequently been deleted. Spark therefore employs decreasing relative timelocks in its recovery transactions, revisiting the idea we encountered in duplex micropayment channels: new owners receive earlier opportunities to enforce their claims than previous owners. These delays are measured from the confirmation of the parent transaction, so they do not start counting down while that transaction remains offchain.
This is a different conflict-resolution mechanism from eltoo. Eltoo permits newer states to supersede older ones by enforcing a state ordering. Spark relies on a time window during which the newer recovery transaction can confirm before older alternatives become valid. That introduces a natural limitation. Timelocks cannot decrease indefinitely with successive transfers, so continuing to transfer a leaf eventually requires renewing the relevant exit structure.
We found references to such renewal operations in Spark's implementation, but did not establish a complete transaction-level account of how renewal preserves security against previously signed recovery transactions. That remains a question worth investigating.
Mercury Layer: signing without seeing the transaction
Our last major topic was Mercury Layer, another statechain construction using key-share updates and timelocked backup transactions. What particularly interested us was its approach to privacy using blind signatures.
Mercury also offers a useful contrast in its recovery design. Its backup transactions spend the original funding output directly and use decreasing absolute timelocks, giving successive owners earlier opportunities to recover the coin. This makes the exit structure comparatively simple, but imposes a finite transfer window: as the timelocks approach the current block height, the coin cannot continue changing hands indefinitely within the same arrangement.
In many statechain designs, the service operator participates in signing Bitcoin transactions and consequently learns information about the transactions being authorized. Mercury instead uses a blind two-party Schnorr signing protocol, allowing the operator to contribute a signature share without learning the transaction it is signing. We spent a substantial amount of time reconstructing this mechanism on the whiteboards.
At a high level, the owner and server control shares of a private key corresponding to the same public key \(P\). During signing, the client introduces a secret blinding value that modifies the nonce point and the Schnorr challenge presented to the server. If the server's nonce point is \(R_s\), the client's nonce point is \(R_c\), and the blinding secret is \(b\), the client constructs a combined nonce of the form \(R = R_s + R_c + bP\).
The client computes the normal Schnorr challenge \(e\) from the actual transaction, but asks the server to sign using the blinded challenge \(c = e + b\). The server returns its partial signature without learning \(e\) or the transaction contents. When the client combines that partial signature with its own, the terms introduced by the blinding factor cancel out in the verification equation, producing a valid signature under \(P\).
The algebra is compact. Understanding why it works, why the server does not need to see the transaction, and what each participant learns at every step took us rather longer. It was one of the more enjoyable parts of the week. We moved back and forth between the Mercury protocol specification, the Schnorr equations, and our own diagrams, tracing the information exchanged at each step.
But the privacy implications are more complicated than simply saying that Mercury hides transactions from the operator. Each time a coin changes hands, the receiver must obtain the entire history of backup transactions created for that UTXO, not just the latest one. This allows the receiver to verify that every previous recovery transaction is valid, that the timelocks decrease correctly, and that their own recovery transaction takes precedence. However, it also reveals the public keys associated with previous ownership states, exposing part of the coin’s offchain transfer history.
There is another subtle security assumption. Since the server blindly signs transactions, it cannot verify their contents or whether they follow the protocol's rules. Instead, it reports how many signatures it has produced, and the receiver checks that this number matches the backup transactions they have received and validated. This verification depends on the operator reporting that count honestly. If the operator underreports it, the receiver may accept an incomplete history, unaware that other signed transactions exist.
Interestingly, this information exposure is asymmetric. Once someone transfers the coin to another participant, they do not automatically learn about subsequent offchain payments or their recipients. However, they still know the underlying on-chain UTXO and can monitor the blockchain for its eventual expenditure. When that happens, they can observe the withdrawal transaction and its outputs, potentially learning something about the final destination, even without knowing the intervening payment history.
This creates an interesting tension: Mercury can keep the operator unaware of the Bitcoin transactions it signs, while revealing the coin's past to each new owner and allowing previous owners to observe its eventual on-chain exit. This echoed a lesson from our previous Deep Dive on Bitcoin privacy: privacy depends on who learns what, at which stage, and how that information can later be combined with observations from the blockchain.
Beyond the mechanisms we examined, Mercury’s documentation describes atomic transfers, which coordinate multiple statecoin transfers so that they complete together or not at all, and Lightning Latch, which links a statecoin transfer to a Lightning payment using a hold invoice. Both rely on the server to coordinate completion correctly. These suggest further possibilities for exchanging statecoins and connecting them to other payment systems, but we did not explore their detailed mechanics or trust assumptions during the week.
Learning to think in settlement layers
Our fellows and grantees came into this Deep Dive with a solid understanding of Bitcoin's base layer: how transactions are constructed, how scripts determine spending conditions, and how consensus rules establish which transactions are valid. But reasoning about offchain protocols requires a different perspective.
On the base layer, confirmed transactions establish a shared history of how outputs have been spent and which remains unspent. offchain protocols introduce a new layer of complexity: participants can hold multiple presigned transactions, some conflicting with others, representing different possible futures. Understanding a protocol means reasoning about which of those transactions might eventually reach the blockchain, under what conditions, and what other participants can do in response.
This was the skill we spent the week developing. Whether we were drawing Ark transaction trees across several whiteboards or working through Mercury's blind-signing equations, the exercise was about understanding how transaction structures, spending conditions, and cryptographic tools combine to support more sophisticated agreements between participants.
That is what makes thinking of Bitcoin as a programmable settlement layer so powerful. Instead of requiring every payment to be immediately recorded on-chain, we can construct protocols in which participants transact offchain while retaining ways to enforce specific claims through Bitcoin, subject to each construction's assumptions and constraints.
Of course, this comes with trade-offs. Faster payments, lower fees, greater scalability, or improved privacy may require additional trust, coordination, or monitoring. Different applications and different users will value these properties differently. The objective is not to eliminate trust from every human or commercial relationship. It is to build systems in which users need to trust service providers less, because the protocols themselves limit what those providers can do. Evaluating those systems requires making both those limits and remaining assumptions explicit.
For us, this is a fundamental aspect of developing Bitcoin engineers. Beyond understanding individual protocols, we want our fellows and grantees to become comfortable reasoning about what Bitcoin can enforce, how far its guarantees can be extended beyond the blockchain, and where additional assumptions become necessary. That understanding opens the door to designing new systems, not merely maintaining existing ones.
