Bitcoin Layer 2: Statechains

Statechains Ruben Somsen developed an original protocol for the second layer in 2018 based on eltoo’s (or LN Symmetry). CommerceBlock created a Mercury variation in 2021, based on the original proposal. Mercury Layer was a new iteration, built in 2024, of the original Mercury plan. 

Statechain Protocol is slightly more difficult to understand compared with other systems like Ark Lightning is a term that refers to the wide range of possible variations between the design that was originally proposed, those that were actually implemented and the other designs loosely suggested. 

Statechains, like Ark, rely on a central coordinating server to operate. They have a different model of trust than an Ark batch vUTXO. The coordinating server must delete any previously generated private keys in order for them to be trustless. However, as long as they follow the protocol, there is a high level of security. 

Statechains are designed to allow users to easily transfer the ownership of UTXOs between themselves, off-chain. This is done by a coordinator. The coordinator does not need to receive liquidity, like Lightning. 

We will begin by looking at the original Ruben Somsen protocol. 

Original Statechain

Statechains allow the current owner to unilaterally withdraw from the Statechain when they wish. A history of signed messages is also kept, cryptographically verifying that previous owners and those to whom they transferred the Statechain have approved the transfers. 

The design of the original was built with eltoo. ANYPREVOUTBut the plans for enabling the same functionality currently make use CHECKTEMPLATEVERIFY The following are some examples of how to get started: CHECKSIGFROMSTACK The CHECKSIGFROMSTACK page has a good explanation. This is a script that allows a transaction that’s been pre-signed to use any UTXO with that script, and lock the amount of bitcoin that it needs. 

The protocol is a protocol that a user follows to deposit coins into a Statechain. Bob generates two keys: one that is his own and unique, as well as a secondary key. “transitory” Key that is eventually shared. (More on this shortly). This is followed by a multisig transaction that requires the coordinator key as well as the transitory one to be signed. 

Using this multisig Bob and the Coordinator sign a Transaction that Spends the Coin and Creates a UTXO. This UTXO can be used by Bob or the Coordinator’s Key using LN Symmetry. Bob now funds the multisig using the correct amount. The Statechain is created. 

Bob will have to follow a complex process in order for him to send a Statechain over the internet. Bob first signs a private message that confirms he’ll be transferring the Statechain. Charlie has to also confirm that Bob gave him the Statechain by signing a message. Finaly, before Bob is able to send Charlie a copy the transitory keys, the coordinator must sign an additional transaction which allows Charlie unilaterally to claim the Statechain. 

This is all made atomic by adapter signatures. Signatures are altered in a manner that makes them invalid. However, they can be restored to validity once the owner of the signature has received the random data. The adapter signatures are used to sign all messages and pre-signed transactions. They can be made atomically valid by releasing the adapter data. 

Statechain owners must be confident that coordinator servers will never work with previous owners to steal funds by signing an immediate closing of the Statechain. The chain of messages that have been pre-signed can show that coordinators were involved in theft. The timelock allows the present owner to claim funds when a previous owner tries to use the pre-signed transactions to steal funds. 

Mercury and Mercury Layer

Statechains require a “softfork” to work. CommerceBlock created their Statechains version to operate without a “softfork”, but to achieve this, they had to make trade-offs in functionality. 

It is still the same basic concept as in the original. All users have a presigned transaction which allows them unilaterally to claim funds. The coordinator server also plays an important role to facilitate off-chain transactions, but they must be trusted that the transfers will take place honestly. These two differences come down to how the transaction is signed, as well as the type of pre-signed transactions that are provided. 

In the case of signing, there’s no more transitory keys that are passed on from one user to another. 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. The key used for signing pre-signed transaction. MPC allows the owner, coordinator, and receiver to initiate a new protocol. different pieces Adding up the numbers to get the same private key. After completing the transfer, an honest coordinator server will delete the key material that corresponds to the previous owner. So long as it’s done, the coordinator is unable to complete a transfer with any previous owners, since the key material that they now have does not match the old piece. If the coordinator is being honest, then this guarantee is stronger than the original one.

Mercury Layer and Mercury’s pre-signed transactions cannot use LN Symmetry because it isn’t possible to do so without using a Softfork. CommerceBlock chose to implement decrementing locks instead. The original owner’s transaction, which is pre-signed and timelocked by nLocktime at a future date far in advance of when the Statechain was created. When a subsequent user is given the Statechain, their nLocktime will be a certain amount of time lower than that which was set by the previous owner. It is guaranteed that the previous owner will not be able to send their transaction before the current one. You can also read about how to get started. Before previous owner’s transactions become valid, close your Statechain. 

Mercury Layer differs from Mercury in the way these transactions are signed. Mercury uses a coordinator server that simply views the transaction being proposed, checks it and signs it. Mercury Layer utilizes blind-signing, which means they don’t see the details of what they are signing. Statechains must be tracked by the server using anonymized server records, as well as a key that is unique to the owner. This allows them to make sure that they only sign valid transactions. 

Synergy between layers

Statechains are compatible with Layer 2s based on transactions that have been pre-signed. In the original proposal, for example, a combination between Statechains (and Lightning Channels) was suggested. It is possible nest a Lightning Channel on top of Statechains because both transactions are pre-signed. The current owner must have a multisig exit key, as well as the ability to create the pre-signed payments that spend the output of the Lightning channel. It is possible to open and close Lightning channels completely off-chain. 

A Statechain can be nestled on top a vUTXO within an Ark batch. It is possible to nest a Statechain on top of vUTXOs in an Ark batch. 

Wrapping it up

Statechains do not have a 100% trustless model, but it is a trust-minimized scheme which allows users to freely transfer UTXOs between each other off the chain. 

CommerceBlock’s two versions of implementation have already been fully implemented. They both failed to reach anything beyond marginal use. It is not clear whether this failure is due to the users’ unwillingness to accept a trust-based model, or if it is simply down to a lack of marketing and awareness. 

This option will remain available, despite the fact that two complete implementations are already in place, as well as designs and concepts for a flexible variant, should LN Symmetry be made possible on Bitcoin. Open source software will be available indefinitely, regardless of how many people choose to use it.