The state chain is the original second-layer protocol originally developed by Ruben Somsen in 2018, in response to the ELTOO (or LN symmetry) proposal. In 2021, the original proposal, Mercury variant was built by CommerceBlock. In 2024, further iterations of the original mercury scheme constructed the mercury layer.
The Statechain protocol is a little more complicated to discuss compared to other systems such as ARK and Lightning, as there is a range of possible variations between the original proposed design, the two actually implemented, and the other possible designs that are loosely proposed.
Like ARK, state chains rely on centralized tuning servers to function. Unlike the Ark, they have a slightly different trust model from the vutxo of the Ark Batch. They rely on coordination servers to remove stocks of previously generated private keys for unreliable maintenance, but as long as the server follows defined protocols and does so, they provide strong security assurances.
The general idea of ​​state chains is that ownership of the entire UTXO can be transferred between different users between different users, facilitated by the coordinator. You don’t need a requirement to receive liquidity such as lightning or a coordinator server to provide liquidity such as ARK.
First, let’s look at the original protocol proposed by Ruben Somsen.
Original state chain
State chains are effectively pre-signed transactions, allowing current owners to withdraw on-chain with chains whenever they need them, and signed messages encrypted that they had sent their status with past owners and approved their transfer.
The original design was built on Eltoo using anyPrevout, but the current plan on how to enable the same feature is to use CheckTemplateVerify and CheckksigFromStack (a high-level explanation of this can be found at the end of the CheckSigfromStack article). The basic idea is not related to using a single specific UTXO, but a script that has that script and allows pre-signed transactions to use UTXO that locks the right amount of Bitcoin.
In the protocol, users who want to deposit coins into the stach chain approach the coordinator server and pass the deposit protocol. Deposit user Bob generates a key he owns, but also generates a second “temporary” key that will eventually be shared (more on this). You then create a deposit transaction that locks the coin into a multi-sign, and need a coordinator key and a temporary key to sign.
Using this multisig, Bob and the Coordinator use the coin to sign transactions that create UTXOs that can be used by other transactions signed by the transiter key and coordinator key using LN symmetry. Bob is now able to fund Multisig for the right amount, and the state chain has been created.
To transfer the state chain to Charlie, Bob must go through a multi-stage process. First, Bob signs the message with his unique private key, proof that he will forward his status to Charlie. Charlie also needs to sign a message proof that he received the state chain from Bob. Finally, the coordinator server must sign a new transaction, allowing Charlie to unilaterally charge a stator chain on chain before Charlie sends a temporary copy of the key to Charlie.
All of these are made atomic using adapter signatures. These are signatures that are modified in such a way using random data that is invalidated, but can be re-enabled when the signature owner receives that information. All messages, as well as new pre-signed transactions, are signed with adapter signatures and are simultaneously enabled atomically through the release of adapter data.
The holder of the state chain must trust that the coordinator server will not conspire with the previous owner to sign an immediate closure of funds from the current owner, but a chain of pre-signed messages can prove that the coordinator has participated in the theft if he does so. If a past owner attempts to steal funds using a pre-signed transaction, a time lock on the spending pass using only keys allows the current owner to submit a pre-signed transaction and correctly claim the funds for the chain.
Mercury and mercury layer
The original StateChain architecture requires a soft fork to work. CommerceBlock designed a status variant to work without SoftFork, but that resulted in a trade-off in terms of functionality.
The basic idea is the same as the original design, with all users holding pre-signed transactions allowing them to unilaterally claim their own funds, and the coordinator server plays a role in facilitating off-chain transfers where they need to trust to behave honestly. The big difference between the two is that they are given how these transactions are signed and the structure of pre-signed transaction users.
For signatures, there is no longer a temporary private key that users will pass to the user. Instead of this, a multi-party computing protocol (MPC) is used, allowing the original owner and coordinator server to jointly generate a partial portion of the private key without any one having the full key. This key is used to sign a pre-signed transaction. The MPC protocol allows current owners and coordinators to participate in the second protocol with recipients and third parties of the transfer to play different pieces that are added to the same private key. With both the mercury and mercury layer protocols, after completing the transfer, the honest coordinator server removes important material corresponding to the previous owner. As long as this is complete, the coordinator will no longer be able to sign transactions with the previous owner. Because the new and important material they have is not compatible with works that their previous owners may still have. This is a stronger guarantee than the original suggestion, as long as the coordinator is honest.
Pre-signed transaction structures of mercury and mercury layers cannot use LN symmetry. This is not possible without a soft fork. Instead of this, CommerceBlock chose to use a reduced time lock. The original owner’s pre-signed transactions are time-locked to use nlocktime to go out much further in the future from the time of the creation of the StateChain. The nlocktime value of the transaction is shorter than the previous owner, as each subsequent user receives a status during transfer. This ensures that the previous owner cannot even file a transaction on-chain before the current owner can, but ultimately, at some point, the current owner must close the status on-chain before the previous owner’s transaction becomes effective.
The main difference between the mercury layer and the mercury layer is how these transactions are signed. In Mercury, the coordinator server verifies that the transaction is proposed, validates it before signing it. Mercury Layer uses a blind signature protocol. This means that the details of the transaction you are signing are not actually displayed. This allows you to verify that the server tracking status requires a special authorization key from the current owner using anonymized records on the server and that you are signing only valid forwarding.
Synergistic effects with other groups
The state chain can be synergized with other Layer 2 based on pre-signed transactions. For example, some of the original proposals suggested a combination of status and Lightning channels. Both are simply pre-signed transactions, so you can actually nest lightning channels above the state chain. This requires that the unilateral exit key of the current owner is multisig and requires creating a pre-signed transaction to output to the lightning channel. This allows you to open and close the lightning bolts, completely closing them with chains.
In a similar way, it is possible to nest the stach chain over vutxo in an arc batch. This requires the pre-signed transactions needed to build the state chain and requires Vutxo output to be spent.
I’ll summarize
The state chain is not completely trusted, but is a very liquid-efficient, highly trust minimization scheme that allows UTXOS to be freely transferred off-chained among users who are willing to embrace the trust model of the state chain.
The original proposal has not yet been built, but the two implementations designed by CommerceBlock are fully implemented. Neither achieved anything beyond the limits of use in the real world. This is whether users don’t want to accept the trust model involved, or simply whether marketing or recognition failures are completely unseen.
Anyway, if LN symmetry is possible with Bitcoin, this is always here, given that there are two complete implementations and designs for more flexible variation. The good thing about open source software is that if you choose in the future, it’s always there, whether people are using it now or not.
