by Lydia Ludmila 
The search for layered protocols has uncovered many exciting tools for improving the scalability, functionality and privacy of public blockchain networks.
In most cases, the differing substrates of a blockchain impose limits on what techniques are available to engineers building these novel systems. For example, the Lightning Network is made possible by leveraging the time and hash locking functionality of Bitcoin script. Blockchains with fewer restrictions on their runtime have access to layered protocols that depend on advanced proof validation engines which facilitate off-chain functionality beyond simple ownership transference (e.g. optimistic and zk-rollups).
There are however layered protocols whose construction is not restricted by the scripting systems available on the blockchain, but instead by the cryptographic algorithms that secure user’s funds.
One such protocol, statechains, was originally proposed by Reuben Somson in 2018. The construction he described enables the off-chain transference of private keys. Following a deposit of a Bitcoin into a statechain, the key material can be transferred between users instantly and with no additional on-chain fees.
This would appear contrary to our understanding of how blockchains work, as the global settlement layer was designed to solve this exact problem. However, with some cool cryptography and additional trust assumptions, key transference is not only possible, but extremely powerful! Before we dive into some of the exciting use cases enabled by statechains, let’s have a look at how they work.
Statechains. How do they work?
To deposit funds into a statechain, a user interactively generates a Bitcoin address with a Statechain Entity. This collaborative key generation process creates a key which is equally split between the Statechain Entity and the user. The funds cannot be moved without their mutual collaboration. The user is also provided with a timelocked backup transaction so they can retrieve their funds in the event that the Statechain Entity is unreachable.
To transfer this “statecoin,” an interactive protocol between the Statechain Entity, sender, and receiver is initiated. No party ever has the full key, and the keys are cryptographically updated (tweaked) on each transfer. With each transfer a new backup transaction is generated for the receiver. How exactly this works in the Mercury statechain implementation we will dive into shortly, as it notably differs from Reuben’s original proposal.
As it relates to the security model, you can think of a statechain as a blend between the Lightning Network and a federated sidechain (e.g. Liquid). In the Lightning Network, two parties interact off-chain by passing around presigned transactions. Security is dependent upon both parties monitoring the chain for bad behavior (malicious or accidental broadcast of old presigned transactions). In a federated sidechain, user’s give custody of the Bitcoin to one or more entities in exchange for access to the sidechain. Security depends on an honest federation.
In a statechain, each backup transaction is presigned and transferred off-chain. This is similar to the Lightning Network, as the current keyholder must monitor the network for the broadcast of these old backup transactions. There also exists a Statechain Entity that holds part of the key. The primary difference is that the Statechain Entity alone cannot steal the funds. To steal funds they would either have to collude with an old statecoin holder or have previously been a holder of that statecoin.
At the highest level, our understanding of statechains has evolved over time. The first and currently only implementation, Mercury, has deviated from Reuben’s proposal for two reasons: it was created before the activation of taproot-schnorr and the Bitcoin protocol upgrade ANYPREVOUT has not yet been proposed for activation.
As a drop-in replacement to Schnorr signatures, the Mercury implementation utilizes a 2-of-2 multiparty computation ECDSA library. If ANYPREVOUT was live, each new backup transaction would update its sequence number, which would enable new backup transaction holders to overwrite any old backup transactions that are maliciously or accidentally broadcast. Because this feature is not available, Mercury uses Bitcoin’s timelocking feature in a decrementing fashion: each new backup transaction has a more-recent timelock than the previous one. This gives the current keyholder a time-enforced advantage in the race to confirm their backup transaction in the event any old backup transactions are broadcast.
Statechain uses
Now that we have established how a statechain works, let’s understand what useful functions it serves as a platform for. One thing to note is the primary constraint imposed on a bare statecoin: when transferring it, the full output must be moved. You cannot break it down into smaller values without adding additional protocols on top of the statecoin.
One use case that is well suited to this constraint is the development of privacy protocols. When building a privacy protocol, you want to lower the cost of user’s anonymity and make the process as low friction as possible. The most popular on-chain privacy protocol, coinjoin, generally requires users to interactively construct a large transaction with equally-valued outputs. With each new round of a coinjoin, an additional on-chain transaction with fees and confirmation delays is required.
In the context of a statechain, you can imagine a coinswap protocol that allows users of equally-valued outputs to instantly and with no additional fees swap their private keys with other users in the statechain. This is exactly what Mercury Wallet is designed to do. This is the first and most powerful non-custodial privacy protocol in the Bitcoin network that operates on layer two. You pay one fee and can do as many coinswaps as you like. A very exciting prospect for privacy enthusiasts.
Mercury’s usefulness extends beyond privacy. It is also an excellent tool for the settlement of funds between financial institutions, custodians and other entities who wish to instantly exchange value amongst one another. This, along with coinswaps, will work out of the box when Mercury wallet is deployed on mainnet. In this way, statechains are an alternative to networks like Liquid, which allow for quick and private settlement but come with a more onerous security model.
Looking to the future, there are other exciting use cases that will arise from the development statechains. One such use case that is served well by full output transference are asset protocols. Non-fungible assets on the Bitcoin network are heavily restricted in layer two environments like the Lightning Network exactly because they are non-fungible: there is not enough liquidity of these tokens to successfully route them. For those non-fungible assets that exist on-chain, converting them to statecoins will allow them to be instantly and with no additional fee be transferred off-chain.
For users engaging in various types of financial instruments, statechains come in handy. Take for example an on-chain bet between two users on the price of Bitcoin, perhaps constructed as a Discrete Log Contract. If any one of the parties wanted to novate the contract (swap themselves for a new counterparty), a number of on-chain interactions would have to occur. If instead, the bet was happening in a statechain, the entire contract could be updated off-chain with no additional fees or confirmation delays.
Because a statechain exists at the level of a blockchain’s cryptosystem, it is possible to layer additional systems on top of it. Not only can you use a statechain inside a sidechain, but you can also layer the Lightning Network on top of it. There are a few approaches to doing this, and most are strongly improved by the existence of ANYPREVOUT, but the possibility of their existence is extremely exciting.
There are two primary benefits of layering the Lightning Network on top of a statechain: the first is the instant transference of the ownership of a lightning channel between parties, which will allow for users to be onboarded to the lightning network without previously having a channel, and the second is the ability to deploy a lightning channel anywhere on the network graph without requiring a channel to be closed and then reopened.
There is so much to be hopeful about with statechains. Mercury has paved the pathway to their existence and I hope to see further development from the wider community as others begin to realize their potential. You can keep up with the development of Mercury by following their work on GitHub.
