Bitcoin Layer 2: Statechains

Statechains are an original second layer protocol originally developed by Ruben Somsen in 2018, depending on the eltoo (or LN Symmetry) proposal. In 2021 a variation of the original proposal, Mercury, was built by CommerceBlock. In 2024, a further iteration of the original Mercury scheme was built, Mercury Layer.

The Statechain protocol is a bit more complicated to discuss compared to other systems such as Ark or Lightning because of the range of variations that are possible between the original proposed design, the two that have been actually implemented, and other possible designs that have been loosely proposed.

Like Ark, Statechains depend on a centralized coordinating server in order to function. Unlike Ark, they have a slightly different trust model than a vUTXO in an Ark batch. They depend on the coordinating server to delete previously generated shares of a private key in order to remain trustless, but as long as the server follows the defined protocol and does so, they provide a strong security guarantee.

The general idea of a Statechain is to be able to transfer ownership of an entire UTXO between different users off-chain, facilitated by the coordinator. There is no requirement for receiving liquidity like Lightning, or the coordinator server to provide any liquidity like Ark.

To begin, we will look at the original protocol proposed by Ruben Somsen.

The Original Statechain

Statechains are effectively a pre-signed transaction allowing the current owner of the Statechain to unilaterally withdraw on-chain whenever they want, and a history signed messages cryptographically proving that past owners and the receivers they sent the Statechain to approved those transfers.

The original design was built on eltoo using ANYPREVOUT, but the current plans on how to enable the same functionality make use of CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK (a high level explanation of this is at the end of the CHECKSIGFROMSTACK article). The basic idea is a script enabling a pre-signed transaction to spend any UTXO that has that script and locks the appropriate amount of bitcoin, rather than being tied to spending a single specific UTXO.

In the protocol, a user wishing to deposit their coins to a Statechain approaches a coordinator server and goes through a deposit protocol. The depositing user, Bob, generates a key that will be uniquely owned by him, but also a second “transitory” key that will eventually be shared (more on this soon). They then craft a deposit transaction locking their coin to a multisig requiring the coordinator’s key and the transitory key to sign.

Using this multisig, Bob and the coordinator sign a transaction that spends that coin and creates a UTXO that can either be spent by any other transaction signed by the transitory key and the coordinator’s key using LN Symmetry, or Bob’s unique key after a timelock. Bob can now fund the multisig with the appropriate amount, and the Statechain has been created.

To transfer a Statechain to Charlie, Bob must go through a multistep process. First, Bob signs a message with his unique private key that attests to the fact he is going to transfer the Statechain to Charlie. Charlie must also sign a message attesting to the fact that he has received the Statechain from Bob. Finally, the coordinator server must sign a new transaction allowing Charlie to unilaterally claim the Statechain on-chain before Bob sends Charlie a copy of the transitory key.

All of this is made atomic using adapter signatures. These are signatures that are modified in such a way using a random piece of data that renders them invalid, but can be made valid again once the holder of the signature receives that piece of information. All of the messages, and the new pre-signed transaction are signed with adapter signatures, and atomically made valid at the same time through the release of the adapter data.

Holders of a Statechain must trust that the coordinator server never conspires with a previous owner to sign an immediate closure of the Statechain and steal funds from the current owner, but the chain of pre-signed messages can prove that a coordinator has participated in theft if they were to do so. If a past owner attempts to use their pre-signed transaction to steal the funds, the timelock on the spend path using only their key allows the current owner to submit their pre-signed transaction and correctly claim the funds on chain.

Mercury and Mercury Layer

The original Statechain architecture requires a softfork in order to function. CommerceBlock designed their variant of Statechains to function without a softfork, but in order to do so tradeoffs were made in terms of functionality.

The basic idea is the same as the original design, all users hold a pre-signed transaction that allows them to claim their funds unilaterally, and the coordinator server still plays a role in facilitating off-chain transfers that requires them to be trusted to behave honestly. The two major differences are how those transactions are signed, and the structure of the pre-signed transaction users are given.

Where the signing is concerned, there is no longer a transitory private key that is passed from user to user. Instead of this, a multiparty-computation protocol (MPC) is used so that the original owner and the coordinator server are able to collaboratively generate partial pieces of a private key without either of them ever possessing the full key. This key is used to sign the pre-signed transactions. The MPC protocol allows the current owner and coordinator to engage in a second protocol with a third party, the receiver of a transfer, to regenerate different pieces that add up to the same private key. In both the Mercury and Mercury Layer protocol, after completing a transfer an honest coordinator server deletes the key material corresponding to the previous owner. As long as this is done, it is no longer possible for the coordinator to sign a transaction with a previous owner, as the new piece of key material they have is not compatible with the piece any previous owner might still have. This is actually a stronger guarantee, as long as the coordinator is honest, than the original proposal.

The pre-signed transaction structure for Mercury and Mercury Layer can’t use LN Symmetry, as this is not possible without a softfork. In lieu of this, CommerceBlock opted to use decrementing timelocks. The original owner’s pre-signed transaction is timelocked using nLocktime to a time far out in the future from the point of the Statechain’s creation. As each subsequent user receives the Statechain during a transfer, the nLocktime value of their transaction is some pre-determined length of time shorter than the previous owner. This guarantees that a previous owner is incapable of even trying to submit their transaction on-chain before the current owner can, but it also means that eventually at some point the current owner must close their Statechain on-chain before previous owners’ transactions start becoming valid.

The major difference between Mercury and Mercury Layer is how these transactions are signed. In the case of Mercury, the coordinator server simply sees the transaction proposed, verifies it, and then signs it. Mercury Layer uses a blind-signing protocol, meaning that they do not actually see any details of the transaction they are signing. This necessitates the server tracking Statechains using anonymized records on the server, and a special authorization key of the current owner so that they can be sure they are only signing valid transfers.

Synergy With Other Layers

Statechains can synergize with other Layer 2s that are based on pre-signed transactions. For instance, part of the original proposal suggested a combination of Statechains and Lightning Channels. Because both are simply pre-signed transactions, it is possible to actually nest a Lightning channel on top of a Statechain. This simply requires the current owner’s unilateral exit key to be a multisig, and the creation of the pre-signed transactions spending that output into a Lightning channel. This allows Lightning channels to be opened and closed entirely off-chain.

In a similar fashion, it is possible to nest a Statechain on top of a vUTXO in an Ark batch. This simply requires the pre-signed transactions necessary for a Statechain to be constructed, spending the vUTXO output.

Wrapping Up

Statechains are not entirely trustless, but they are a very trust minimized scheme that is very liquidity efficient and allows freely transferring UTXOs off-chain between any users willing to accept the trust model of Statechains.

While the original proposal has yet to be built, the two implementations designed by CommerceBlock have been completely implemented. Both failed to achieve anything more than marginal use in the real world. Whether this is due to users being unwilling to accept the trust model involved, or simply a failure in marketing or awareness is something that cannot be fully ascertained.

Regardless, given that there are two full implementations and designs for a more flexible variation should LN Symmetry ever become possible on Bitcoin, this an option that will always be here. The nice thing about open source software is that it will always be there regardless of whether people use it now, should they choose to in the future.

This post Bitcoin Layer 2: Statechains first appeared on Bitcoin Magazine and is written by Shinobi.