Statechains are a groundbreaking second layer protocol introduced by Ruben Somsen in 2018, based on the eltoo (or LN Symmetry) proposal. In 2021, CommerceBlock developed a variation of the original proposal called Mercury. Subsequently, in 2024, an enhanced version of the Mercury scheme, known as Mercury Layer, was introduced.
The Statechain protocol is a complex system compared to others like Ark or Lightning due to the various possible variations between the original design, the implemented versions, and potential future designs.
Similar to Ark, Statechains rely on a centralized coordinating server for operation. However, they have a different trust model compared to a vUTXO in an Ark batch. Statechains require the coordinating server to delete previously generated private key shares to maintain trustlessness. As long as the server adheres to the defined protocol, they offer a high level of security.
The core concept of Statechains is to enable the transfer of complete UTXO ownership off-chain between different users with the help of the coordinator. Unlike Lightning, there is no need for receiving liquidity, and unlike Ark, the coordinator server does not provide liquidity.
Initially, let’s delve into the original protocol proposed by Ruben Somsen.
The Original Statechain
Statechains essentially consist of a pre-signed transaction that allows the current owner to unilaterally withdraw on-chain at any time, along with cryptographically signed messages demonstrating past ownership transfers. The original design utilized eltoo with ANYPREVOUT, but current plans involve leveraging CHECKTEMPLATEVERIFY and CHECKSIGFROMSTACK for the same functionality. This involves a script enabling a pre-signed transaction to spend any UTXO with the script, locking the required bitcoin amount, rather than being restricted to a specific UTXO.
In the protocol, a user looking to deposit coins to a Statechain interacts with a coordinator server through a deposit protocol. The user, let’s say Bob, generates a key unique to him and a second “transitory” key to be shared later. Bob creates a deposit transaction locking his 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 spending the coin and creating a UTXO that can be spent by any other transaction signed by the transitory key and the coordinator’s key using LN Symmetry, or by Bob’s unique key after a timelock. Bob then funds the multisig with the necessary amount, establishing the Statechain.
To transfer the Statechain to Charlie, Bob goes through a series of steps. Initially, Bob signs a message with his unique private key indicating the transfer to Charlie. Charlie also signs a message confirming the receipt of the Statechain from Bob. Finally, the coordinator server signs a new transaction allowing Charlie to unilaterally claim the Statechain on-chain before Bob shares the transitory key with Charlie.
All transactions are made atomic using adapter signatures, which are modified to be invalid until the holder receives specific information to make them valid again. This ensures the security of the Statechain.
Holders of a Statechain must trust that the coordinator server does not engage in any malicious activities. The chain of pre-signed messages can expose any theft attempts by the coordinator. If a past owner tries to steal funds, the current owner can use the timelock to claim the funds on-chain.
Mercury and Mercury Layer
The original Statechain architecture necessitates a softfork, which CommerceBlock addressed in their variant. While maintaining the core idea of pre-signed transactions for fund withdrawal, CommerceBlock introduced new signing methods and transaction structures.
In Mercury and Mercury Layer, a multiparty-computation protocol is used for signing transactions without the need for passing a transitory private key between users. This protocol ensures secure transaction signing and key management without any single party possessing the complete key.
The pre-signed transaction structure in Mercury and Mercury Layer utilizes decrementing timelocks instead of LN Symmetry. This approach ensures that previous owners cannot submit their transactions before the current owner, enhancing security.
Mercury Layer incorporates a blind-signing protocol, enhancing transaction security by preventing the server from viewing transaction details. This protocol requires the server to track Statechains using anonymized records and the current owner’s authorization key for valid transfers.
Synergy With Other Layers
Statechains can complement other Layer 2 solutions based on pre-signed transactions, such as Lightning Channels. The integration of Statechains and Lightning Channels allows off-chain opening and closing of Lightning channels.
Similarly, Statechains can be nested on top of a vUTXO in an Ark batch, enabling seamless transfer of UTXOs off-chain.
Conclusion
While Statechains are not completely trustless, they offer a highly secure and efficient method for transferring UTXOs off-chain. Despite the limited adoption of the original proposal, the implementations by CommerceBlock showcase the potential of Statechains. With ongoing developments and flexible variations, Statechains remain a viable option for users in the future.
This article on Bitcoin Layer 2: Statechains was originally published on Bitcoin Magazine and authored by Shinobi.