Statechains are a concept that were introduced by Ruben Somsen more than 6 years ago. Since then Mercury Layer was launched by Commerce Block as arguably the most advanced Statechain - with blinded signing. In this article, we are going to introduce a spin-off protocol that we believe possesses advanced privacy properties. In this protocol, state transitions inside a dedicated ledger are replaced with zkSNARKs. The selected programmable ZK stack also allows for more flexibility when it comes to enabling smart contract support. We outline ideas for market-based solutions to address the non-fungibility of statecoins and bring-in private, albeit limited, zero-knowledge smart contracts for this execution layer on top of Bitcoin.
Intro
When working on a bitcoin-specific application for private payments, our team began thinking about ways to improve the trust assumptions related to pegging in and out of the protocol. Currently, the network hosts a “bridge” contract on a bitcoin rollup, making the protocol a Bitcoin “L3” per marketing language used on twitter.
But the application itself is not a “layer” on top of any protocol. It is a sovereign network with its own consensus mechanism. The fact that it can host light clients on other protocols, for purposes of message passing, can connect it to bitcoin (or any other blockchain).
When thinking through this lens, we’ve asked ourselves, “how can we improve the trust assumptions for bitcoiners who want improved privacy?” We thought through many ideas; BitVM, Ark, and other types of Layer 2 protocols.
We’ve found that our protocol works well with statechain-like assumptions. Meaning, a user can deposit funds into a multisig collaboratively with an operator. They can transfer ownership of this UTXO, backing private notes on the private network, by transferring their spending key to a recipient. When doing this, the operator is trusted to not collude with the spender to double-spend the recipient.
In this post, we cover how a statechain-like deposit mechanism can offer a different set of tradeoffs for users who want to have improved privacy related to their bitcoin holdings.
Literature Review
The basic idea behind statechains is that a user Bob (public key B) locks his funds in a 2-of-2 multisig. One multisig key is held by the statechain entity Alice (public key A) and the other by Bob (public key X). The statechain entity (Alice) and Bob together pre-sign a unilateral exit transaction for Bob in case of unresponsiveness from the statechain entity (Alice). When Bob wants to transfer the money (the entire UTXO) to Claire (public key C), he simply hands over the private key for X to Claire.
Some resources on statechains are:
-
In the Mercury Layer design, the Statechain entity is signing blinded messages — it does not know whether these are Bitcoin transactions or something else entirely (image source).
-
Ruben Somsen’s blog is the most up-to-date source of accessible information about statechains principles and design.
-
Later design ideas proposed a “channel” based escrow that relies on Eltoo introduced by Christian Decker, Rusty Russell and Olaoluwa Osuntokun. This version of Statechains does not require a Statechain Entity. However, it can’t work with Bitcoin now since it requires an activation of SIGHASH_NOINPUT opcode to enable Eltoo. This opcode was proposed in a draft BIP-118 in 2017 and unlikely to be activated soon on the Bitcoin blockchain.
Statechain Entity-based designs achieved peak performance, in terms of privacy, via the Mercury Layer implementation. A detailed description of the protocol is available in the repository, in the documentation section. Whereas receivers still have to verify the history of the statecoin, the Statechain Entity has no insight into the statecoin thanks to blind signing of the UTXO transfer.
Another protocol flavor called Spark, which was launched in 2025, addressed non-fungibility of statecoins with its “leaf splitting” technology. This way, users could spend not just whole UTXOs on the statechain, but use smaller amounts which greatly improved user experience (when compared to Commerce Block’s Mercury Layer protocol). To our knowledge, Spark operators do not use blind signing, thus they have a record of every transaction that takes place in the Spark protocol. Leaf splitting also suggests there is a very large amount of pre-signed transactions that have to be constantly updated, adding significant overhead for the operators. Finally, the launch of Spark support in Wallet of Satoshi highlighted that all Lightning payments for WoS users may be publicly visible via Spark’s block explorers.
Spark and Mercury layer are production ready protocols based on the statechain paradigm. A research implementation from Super Testnet possibly provides the simplest implementation of statechains; statechainjs. An interesting feature of this project is its reliance on relative timelocks. Relative timelocks do not require statecoin updates at fixed block heights, as opposed to absolute timelocks that force users to come onchain prior to the timelock expiry. They defer this inevitable “reset” of the backup transaction to an undefined time horizon that depends on the usage of the corresponding coin. However, any prior holder may broadcast their pre-signed exit transaction that “starts the clock,” but they can’t withdraw til after the latest holder gets a chance to do so, so prior holders have limited incentive to try and cheat the current user – unless they think the “real holder” is offline, in which case they may be able to steal from them. Due to this possibility, the latest holder has to watch the chain “just in case,” and be ready to broadcast their withdrawal transaction “first.”
Super Testnet’s experimental implementation also lacks support for the important concept of Adaptor signatures. Therefore this design relies significantly on incentives to work cooperatively and not withholding key shares during statecoin transfers.
ZK Execution Layer for Private Transfers
Somsen’s original idea implied a degree of freedom when it comes to statecoin “ledger” that registers state coins transfers for coordination purposes. It practically addresses technical issues that stem from the ability of statechain users to look up original deposit transactions, track transitory keys, timelocks and verify backup transactions.
We propose a combination of statechain exit mechanics with a zero-knowledge transaction layer (ZK Ledger) as the main ledger that is responsible for the validation of “key changes” and simultaneous relative timelock decrements corresponding to onchain Bitcoin transactions. Our idea relies on previous work related to the ZK Rollup design for Payy Network. We found that the notion of private “payment links” to be potentially synergetic with statechain-style protocols.
When connected to statechains, the enhanced programmability of the ZK Ledger allows for simplified backup transaction updates. In this model, the receiving party verifies a zero-knowledge proof as a part of the UTXO transfers, in addition to normal ways to verify bitcoin transactions. It is our view that this programmability makes the protocol simpler and closer to Super Testnet’s demo case.
Transmitting notes P2P
Protocol explainer
Let’s dive into more details about proposed architecture. On the highest level, the Sender and Receiver facilitate a peer-to-peer transfer. For the Sender to generate a valid zkSNARK proof and transfer ownership of the UTXO to the recipient, they must have the corresponding the note’s data (note being the private, offchain representation of an onchain UTXO). This zkSNARK proof is transferred to the user client-side, and only the hash commitment of the note is published to the operator within the ZK Ledger. Senders coordinate with the Statechain entity to pass ownership of the UTXO to a recipient. Upon validating the validity of the UTXO, recipients receive the coin and trust the operator to not collude with previous owners to double spend them. For the remainder of this post, we will refer to the Statechain entity as the “Operator”.
Protocol roles
The protocol has three actors; the operator, the sender and the receiver who operate the ZK Ledger. Each of these parties are responsible for specific items during a statecoin transfer.
ZK Ledger: The ZK Ledger is a sovereign network with its own consensus rules and implementation. It enables token transfers that are proven valid through zkSNARKs and minimal information leakage related to participants in a transaction.
Operator: The operator is responsible for maintaining a ledger of note commitments that nullify a sender’s ability to double-spend a recipient (i.e. run a ZK Ledger full node). Upon verifying a sender’s proof to spend a UTXO, and ensuring the newly generated output commitment does not exist within the list of previous commitments, the operator co-signs the new presigned transaction. The Operator is meant to be a Statechain Operator which is an independent role to validators in the ZK ledger.
Sender: The sender is a user in the protocol that wants to transfer funds to another party. To transfer these funds, they construct a new presigned transaction that designates the recipient as the recipient for the payout transaction. This presigned transaction has a lower timelock than that of their presigned transaction.
Receiver: The receiver is responsible for initiating transfers within the protocol and verifying their validity. When they want to receive funds, they generate a secret key that is passed to the sender, which the sender then uses to pre-sign a new pay out transaction (related to the bitcoin UTXO locked in the onchain multisig) specifying the recipient as the previous owner. After the sender and the operator pre-sign a new payout transaction, and this information is communicated with the recipient, the recipient verifies that the payout transaction is for a valid bitcoin UTXO and that their pay out transaction timelock is lower than that of the sender.
Payment flow
The payment flow can be described as the following: a user deposits funds into a 2-2 Musig address where they and the Operator each hold a keyshare. This deposit transaction is mirrored on the ZK Ledger and credits the user’s balance with an amount of bitcoin-denominated tokens that is equivalent to that of tokens held in the multisig address. The Operator can be a single signer or their key can be sharded across multiple signers using some Threshold Signature Scheme. When depositing funds into the protocol, the user works with the Operator to generate a presigned transaction that enables them to unilaterally exit the protocol in case of an Operator liveness failure.
To send funds to a recipient, the sender is responsible for communicating her UTXO in the form of “input note’s” data to a receiver via short “payment links”. Such payment links may be shown as QR code or sent via communication channels. This way the receiver “pulls” payment and constructs her new UTXO. SuperTestnet suggested a way that is featured by some eCash projects when bearer tokens are sent via Nostr relays. If implemented, it would mean achieving the goal of “push” payments via a combination of creating a “pull” note by the Sender, encrypting it for the Receiver using the Receiver’s Nostr public key, and broadcasting the message via a dedicated Nostr relay.
To fully facilitate a payment, the sender (Bob) first proposes a transaction within the ZK Ledger. He creates a payment link for a note (UTXO) and broadcasts the payment to this link to the network’s validators. If newly created UTXO satisfies rules for normal send, mint or burn type of transaction, the network validators confirm the payment as valid and add its corresponding commitments to the ZK Ledger chain. It is the purpose of the future research to evaluate potential options for note contents and corresponding rules. For example, a transitory key may be handed over along with a nullifier inside the note or alternatively note could commit to a key that was used for creating Bob’s backup address, i.e. when handing over secret in the payment link automatically invalidates previous timeout spending branch. This “InputNote” created by Bob has to be handed over to the recipient (Carol).
As mentioned, in the ZK Ledger, the sender (Bob) has created a note to transfer funds to the recipient (Carol). To mirror this transfer on Bitcoin, we need to transfer ownership of the spending key in the onchain bitcoin multisig from Bob to Carol if it wasn’t transferred via note. To do this, the sender (Bob) works with the operator to create a new pre-signed exit transaction for the new recipient (Carol) as depicted in Figure n (“blind statechains”). This procedure establishes the recipient (Carol) as the new current owner. As with all statechain-like designs, the timelock on this new exit transaction expires before the timelock of the previous exit transaction belonging to Bob. After this procedure is complete, the sender (Bob) communicates the secret key for X the recipient (Carol).
Upon downloading the link, the recipient can then claim the note and create new UTXO through a second ZK Ledger transaction. Carol does this and broadcasts said transaction to the networks’ validators who confirm their claim. A second commitment is added to the chain, finalizing the transfer within the ZK Ledger. This transfer is also reflected on bitcoin via the statechain-like ownership transfer procedure. Carol now holds a note within the ZK Ledger and a copy of a presigned transaction for the 2-2 multisig on bitcoin for optional unilateral exit.
In this protocol, the transfer of ownership is proven valid by a zkSNARK proof which the recipient validates client-side. The zkSNARK proves, per some zero-knowledge circuit logic, that the sender constructed a presigned payout transaction with a lower timelock than the one they previously received and that the note they’ve received on the ZK Ledger is valid and has an available output commitment. To prove that the sender has not previously transferred ownership to another user within the ZK Ledger, the receiver checks the generated output commitment against all commitments through its ZK Ledger full node or a third-party node. If the output commitment is unique, and the proof is valid, the recipient validates the ZK proof and finalizes the transaction. After verifying the transfer’s validity, the recipient locally stores the backup transaction, but does not broadcast it. The recipient is now the current owner of the statecoin. Note, that in our protocol, a history of backup transactions is not passed to the recipient. The zkSNARK that they validate locally is proof that the note they are receiving in the ZK Ledger is valid, and that this transfer of ownership is updating the bitcoin multisig’s view of said transaction.
A successful verification means that that locktime committing to the output hash was accepted along with his Shielded note secret key hash in private inputs of corresponding SNARK proof and it was lower than locktime in previous transactions.
Note structure
Within the example above, you may note that the sender is responsible for two operations: 1) create a payment in the ZK Ledger and engage in a key reassignment procedure with the operator to transfer ownership of the bitcoin multisig to a recipient. This is necessary, but user complexity can likely be mitigated through application UI abstraction.For the receiver, we can construct the ZK Ledger’s note structure and corresponding ZK-Circuits to verify the validity of a transfer pertaining to funds in the bitcoin multisig, offchain. It is important for Receiver’s security that upon receipt of the pre-signed backup transaction, the Receiver must obtain a finalized transaction that spends from an existing Bitcoin UTXO and contains a timelock that is lower than all previously generated backup transactions.
In previous protocols, the timelock decrement could be enforced via verification of the entire history of statecoin transfers client side. In our protocol, we address that in a way that allows compressed representation via SNARK while providing privacy as a by-product.
Updated UTXO note structure
When included into note structure, the timelock validation becomes a part of the dedicated UTXO circuit which validates privately if Receiver’s timelock in the output satisfies a condition to be less than timelock in the input with given delta. The timelock and the authentication key become two entities that connect a shielded pool note with Bitcoin. The authentication key may be a valid libsecp256k1 private key that corresponds to the backup transaction and is not known to the next receiver until signing of the new backup is complete.
In the less private setup after obtaining the payment link with the previous transitory key along with private key to backup address, the receiver includes them as input into a new shielded transaction, validates it, generates proofs and sends the new transaction to the Operator. However, albeit less private (details are shared with counterparty), this way may be considered also as most secure since the next shielded coin owner also has a private key from the previous backup transaction. This disincentivizes the previous owner from broadcasting an old backup.
In a more private setup the Receiver can only obtain Sender’s public key in case of an attempt to spend funding UTXO and because Receiver already has a transitory key after completion of the statecoin transfer, she may convince Operator to punish dishonest sender and co-sign to the new “recovery” address of the owner of valid Shielded note.
Crime and Punishment
In the current design, we propose a more straightforward way to facilitate backup UTXO transfer. However, it still allows Spenders to attempt a double-spend. In a scenario where the Spender hands over payment links with the note private key encoded, broadcasting an old backup does not make sense since the Receiver may know the private key for the backup output from the link (i.e. it becomes a way to revoke backup). Alternatively, when the Sender publishes their previous back up transaction onchain, and the Receiver already has a backup transaction, the recipient reconstructs the commitment and expects confirmation in the ZK Ledger which only happens if the timelock in the Output was lower than the timelock in the Input. Here, double spend is impossible too, unless the Operator colludes and secretly co-signs a new transaction with lower timelock without submitting it into ZK ledger.
However, this situation may be detected by external observers and fraud is provable the same way it is done in the original statechains. When defrauded, the Receiver may obtain a transaction that spends funding input of the state coin, extract public key, amount and timelock and obtain commitment that should have been submitted into statechain ledger in the honest scenario. If the existence of the output commitment is not confirmed, it means that the operator colluded with dishonest Sender.
When the Operator entity is represented by FROST federation, each participant may track funding UTXO and verify if new spends correspond to shielded UTXO. Besides detecting potential collusion, this defines a unilateral exit scenario when UTXO must be burned.
Fungibility of Notes in Shielded Pool
Backup transactions may lead to privacy leaks which will make all efforts on improving it on the statecoin ledger side fruitless. Therefore an important feature of the Operator should be blind signing of backup transactions similarly to the Mercury layer. However it also means that schemes with splitting of shielded coins denominations with simultaneous backing similar to Spark’s are likely impractical when joined with blind signing. In this situation we propose to preserve privacy benefits while addressing shielded coins’ fungibility via market based mechanics when circulating shielded notes may be merged and exchanged privately inside a shielded pool with support of pre-programmed circuits implementing dedicated smart contract functionality.
The transaction structure of the original ZK Rollup architecture assumes 2-input, 2-output transactions and allows merging and splitting notes with change by design. For notes of “statecoin” kind rules may define 1 padding “zero” note in the input and the output correspondingly and such simple rules could be enforced via dedicated UTXO circuit which could be programmable.
For an illustration, let’s consider an existing code snippet, a simple check for various types of notes: if note facilitates regular transfer, mint (gets into the pool) or burn (exits shielded pool).
if (kind == 1) {
//SEND
assert(input_value == output_value, "Input and output totals do not match");
} else if (kind == 2) {
// MINT
// Assert mint utxo is balanced:
// - \`output_value\` is checked above
// - \`input_value\` is checked as it must have previously been an output value
// - \`msg_value\` is checked above (but also using that to overflow would be detrimental to the
// attacker)
assert(output_value == input_value + msg_value, "Mint output must match value message");
// Assert mint hash
assert(mint_hash == msg_hash, "Mint hash must match message");
// Assert note kind
assert(output_notes\[0\].kind == msg_note_kind, "Mint note kind must match message")
} else if (kind == 3) {
// BURN
// Prevent frontrunning the txn and changing the evm address
assert(pmessage4 == burn_addr, "messages\[4\] must match private input");
// Assert burn hash
assert(burn_hash == msg_hash, "Burn hash must match message");
// Assert burn utxo is balanced:
// - \`output_value\` is checked above
// - \`input_value\` is checked as it must have previously been an output value
// - \`msg_value\` is checked above
assert(input_value == output_value + msg_value, "Burn output must match value message");
// Assert burn kind
assert(input_notes\[0\].note.kind == msg_note_kind, "Burn note kind must match message")
} else {
assert(false, "Invalid kind");
}
This way we could define more types and more checks. More importantly, we envision building a market place for peg-outs where whole pre-signed UTXO could be traded against shielded fungible tokens. Marked based approach assumes the existence of notes that may be detached from the corresponding backup transactions and therefore requiring less interactive process for regular private transfers.
Nostr-based Relaying
The original Moore’s and Gandhi work mentions “Encrypted Registry” which should help sending payments over the network when the Sender and Receiver are not online at the same time. During their absence, the transaction data could be stored in the Encrypted Registry, and this is an optional component of the network.
As mentioned earlier, using Nostr allows achieving a “push” payments user experience while not changing the existing method for sending coins. On a higher level, sending a payment to a selected Nostr public key specifies a resilient and sufficiently decentralized way to broadcast an encrypted transaction and possibly gain additional privacy because financial transactions will be relayed along with tons of different encrypted data, including regular text messages to this user.
Besides that, relaying a message broadly via several Nostr relays may allow duplication of the original message. Because Nostr is becoming a modular sophisticated protocol, the goal of a sharded decentralised encrypted registry, where the encrypted data is split into chunks and blindly stored across multiple nodes may be achieved independently from ZK Ledger development goals.
Conclusion
Previous works around Bitcoin Statechains suggest a degree of freedom when it comes to implementing a ledger for tracking statecoin transfers and keeping the Operator accountable. We have attempted to replace implied UTXO-based ledger with the simplest possible flavor of the ZK Rollup that was previously developed for Ethereum. The eventual design becomes a rather zero-knowledge based smart contract execution layer for Bitcoin, with opportunities for unilateral exit and censorship resistance stemming from leveraging ZK technology stack.
The proposed architecture occupies an intermediate position between Statechains and ShieldedCSV or ZKCoins. The latter omits on/off ramping into shielded pools while the former lacks privacy. However, options for using BitVM as for bridging coins back and forth are mentioned both in ShieldedCSV paper and ZKCoins as well. It makes the ZK execution layer an interesting opportunity to experiment with programmable market-based mechanics for on/off ramping into shielded pools. The closest example here might be the “pragmatic rollup” design implemented in Signet and completely unknown to the Bitcoin community. Its design suggest instant swaps and atomicity for cross-chain transactions which when applied to ZK Statechain would mean “one in, one out” rule facilitated with the help of “privacy arbitrators” who are ready to post UTXO for exits or take ownership and possibly lift timelocks for entering participants.
Acknowledgments
I greatly appreciate the thorough review by Janusz and Gus Gotoski. I also thank SuperTestnet and fiatjaf for their valuable feedback.