Statechains are L2s
I’ve thought about the trust assumptions related to statechains for a little bit now. I’m by no means an expert, but I think “rug-risk” related to statechains hasn’t been fully presented.
Most people (correctly) describe this rug-risk as, “the statechain entity can rug users if they collude with a previous owner of a UTXO.” I’m not challenging this claim, but rather how we classify it on a risk spectrum. The risk does not rely on the custody of funds, but rather can a chain of transactions be "reverted".
Statechains are L2s where users lock into a 2-2 multisig with an operator known as the statechain entity. To transfer funds offchain, users send their private key for said multisig to a recipient (with the help of the statechain entity). Now, the new owner and the statechain entity have the ability to immediately spend the funds. During all of this, users have a unilateral exit path to leave the protocol if the operator becomes unresponsive. These unilateral exit paths are accompanied with decrementing timelocks to ensure current owners of the offchain UTXO can spend the funds prior to previous owners. A way to visualize this is as so:
Alice and the statechain entity both own a key to a 2-2 multisig to spend a given UTXO. The multisig has an arbitrary value of 100. Each key has an arbitrary value of 50 each. To immediately spend the UTXO, the “100” threshold needs to be met.
Alice sends her private key to Bob. At this point, the statechain entity tweaks the keys to see Bob’s key worth 45 and the entity’s key worth 55. Alice still has a record of her key worth 50, but the statechain entity is expected to delete their previous keyshare worth 50. If the entity deletes their previous keyshare, Alice cannot collude with the statechain entity because 55 + 50 =! 100. Now, only Bob can immediately spend funds with the statechain entity. Also, the timelock related to unilateral Bob’s exit path expires before Alice’s.
If the statechain entity deletes their keyshare with Alice, only Bob can immediately spend funds with the statechain entity. The collusion risk only takes place when funds are transferred. In my opinion, this is a finality risk, not a custody risk.
In @BitcoinLayers reviews, for example, we look at four categories when assessing L2s - custody of funds, data availability & storage, network operators, and finality. Related to statechains, the risk lies in finality - i.e., the recipient(s) of funds can be “double spent” by the operator and previous owner(s). In protocols leveraging collaborative multisigs, finality assurance is ultimately achieved when funds are recovered on the Bitcoin L1. In statechains specifically, users have no assurance of finality as there is no way to ultimately prove that the statechain entity is deleting its keyshares held with previous owners.
People might read this and think, “the trust assumptions here sound off…”
To the contrary - most uses of offchain BTC are completely custodial and subject to a single point of failure. In sidechains, the bridge operators have complete custody of funds and can steal from users unilaterally. Statechain entities can become malicious, but the attack vector requires collusion with previous owners of individual UTXOs. Not all previous UTXO owners are likely to collude, especially at scale. You could argue statechain entities are virtually unable to unilaterally rug all users within the system.
And in the event that statechain entities are honest, current owners have immediate control of funds and previous owners cannot revert this control. We’ve provided a good framework for thinking about bitcoin L2s, and within that framework, statechains would be considered “bitcoin native” but not necessarily an L2. I guess this is me saying I somewhat disagree with the framework 🙂
I think statechains are L2s with very strong custody guarantees but rather “poor” finality guarantees. This is in direct contrast to something like rollups (with BitVM) where users give up custody of funds but can challenge malicious bridge operators and have state transitions finalized when checkpoints are posted to the L1.
All this to say - it’s tradeoffs all the way down! I’m excited for the upcoming application layer on @buildonspark and continued progress for FOSS projects like @mercurylayer.
