State Chain is a protocol that was first proposed in 2018 by Ruben Somsen, spurred by ideas related to the Eltoo (or LN symmetry) proposal. In 2021, CommerceBlock developed a variant called Mercury, and in 2024, additional improvements led to the creation of the mercury layer.
Discussing the Statechain protocol is a bit more complex than talking about systems like ARK or Lightning. There are several variations to consider, from the initial design to the two implemented versions and other loosely proposed ideas.
Much like ARK, state chains utilize centralized tuning servers for their operation. However, they differ in their trust model compared to ARK’s vutxo system. State chains depend on coordination servers to manage stocks of previously generated private keys, which can sometimes be unreliable. Still, if the server adheres to established protocols, it can offer robust security.
At its core, state chains allow ownership of a UTXO to be transferred among users, mediated by the coordinator. Unlike systems needing a coordinator server for liquidity, state chains don’t require such arrangements to function.
To dig deeper, let’s revisit the original protocol introduced by Ruben Somsen.
The original state chain operates as pre-signed transactions, which allow current owners to withdraw on-chain whenever needed. Owners communicate their status to past owners through signed messages, ensuring approved transfers. The initial design was based on Eltoo using anyPrevout, but now the feature plan involves CheckTemplateVerify and ChecksigFromStack. The goal is to use a script that permits pre-signed transactions, locking an appropriate amount of Bitcoin.
In this protocol, users deposit coins by reaching out to the coordinator server. For instance, if a user named Bob wants to deposit, he generates a unique key and a secondary “temporary” key, which will be shared eventually. A deposit transaction is created, locking the coins into a multi-signature that requires both the coordinator key and the temporary key to sign.
With this multisig setup, Bob and the coordinator can sign transactions to create UTXOs for others, utilizing LN symmetry. Bob ends up funding the multisig correctly, thereby establishing the state chain.
To transfer the state chain to someone like Charlie, Bob must go through a multi-step process. He signs a message with his unique private key as proof that he’s passing his status to Charlie. Charlie must then sign a message confirming he received the state chain from Bob. The coordinator server needs to sign a new transaction allowing Charlie to claim the status chain on-chain before Bob sends a temporary copy of the key to Charlie.
This entire process is atomic, made smooth by adapter signatures, which are altered using random data making them temporarily invalid, but reactivating once the owner receives the corresponding information. All communications and new pre-signed transactions are atomically enabled by releasing adapter data.
The state chain holder has to trust the coordinator server not to collaborate with the previous owner to hijack funds. However, a sequence of pre-signed messages can reveal if the coordinator attempts theft. Should that happen, a time lock on spending ensures the current owner can reclaim funds with a pre-signed transaction.
### Mercury and the Mercury Layer
The initial StateChain design requires a soft fork. However, CommerceBlock’s version—functioning without one—traded off some functionality. The core concept remains the same: users possess pre-signed transactions allowing them to independently claim their funds, while the coordinator facilitates off-chain transfers under the assumption of honest behavior.
The key difference is in transaction signing and user structure. In this model, there’s no longer a temporary private key exchanged; instead, a multi-party computing protocol (MPC) generates partial segments of the private key securely. Both the current owner and coordinator generate a key to sign pre-signed transactions, involving a third party who is the transfer recipient.
In both mercury versions, once the transfer is completed, the honest coordinator server discards important material relating to the previous owner. As long as this process is followed, the coordinator can’t sign transactions with the earlier owner because the new materials won’t align with past records—thus offering stronger security, assuming honesty.
In terms of transaction structures, the mercury and mercury layers can’t use LN symmetry without a soft fork. Instead, CommerceBlock has opted for a reduced time lock, making the original owner’s pre-signed transactions subject to nlocktime significantly further in the future. This approach prevents previous owners from submitting transactions on-chain before the current owner can effectively close the state chain, even if the former’s actions could impact the situation down the line.
The mercury layer’s major distinction lies in how these transactions are signed. In Mercury, the coordinator verifies and signs proposed transactions, while the Mercury Layer employs a blind signature protocol. This means the coordinator doesn’t see the transaction details, allowing for anonymized and secure verification.
### Synergy with Other Protocols
State chains can harmonize with other Layer 2 solutions founded on pre-signed transactions. For instance, proposals have suggested merging state chains with Lightning channels since both involve pre-signed transactions. This could enable nesting Lightning channels within state chains, requiring the current owner’s unilateral exit key to be multisig and a connection to the Lightning channel through pre-signed transactions.
Similarly, state chains could intermingle with vutxo in an arc batch, necessitating pre-signed transactions to construct the state chain while requiring Vutxo outputs for spending.
### Summary
State chains, while not completely trustless, offer a liquid-efficient approach that minimizes trust, allowing UTXOs to be transferred off-chain among users willing to accept its trust model.
Although the original proposal hasn’t been fully realized, the implementations by CommerceBlock are operational but haven’t yet pushed beyond practical use cases. Whether that’s due to reluctance towards the trust model or issues in outreach, it’s unclear.
Still, if LN symmetry becomes viable with Bitcoin, it’s always an available option, given that there are two complete implementations and ongoing flexibility in design. The beauty of open-source software is that possibilities remain open for the future, regardless of current usage.
