Mercury Layer
Status
Mainnet
Type
Statechain
Fee Token
BTC
BTC Supply
₿0
Mercury Layer is an implementation of the statechain protocol. Statechains enable the offchain transfer of UTXO ownership by transferring key shares from one entity to the next with support of a trusted third party, the statechain entity. A statecoin owner can unilaterally exit back to Bitcoin’s L1 network, given the statechain entity doesn’t collude with a previous statecoin owner. Mercury Layer utilizes an HSM server that leverages blind co-signing and key share updates. The system relies entirely on client-side software to manage the statechain transfer history and handle transaction validation.
CUSTODY
DATA AVAILABILITY
OPERATORS
FINALITY ASSURANCE
Trust Assumption Review
BTC Custody
Medium
⚠️
Mercury BTC
A locked UTXO is collaboratively managed between a trusted server and the statecoin owner, with full L1 UTXO ownership enforceable after a timelock expiry
The statechain setup involves locking a UTXO onchain with the private key shared between the operator and the current statecoin owner. Although the Mercury Layer server acts as a trusted entity, users are safeguarded against potential unresponsiveness by having the ability to unilaterally exit and enforce their UTXO ownership onchain as each transfer is secured by a decrementing timelock mechanism and a series of backup transactions.
We have assigned Mercury Layer a medium score due to situational differences in user custody.
We have assigned Mercury Layer a medium score due to situational differences in user custody.
Data Availability
Low
✅
Transaction verification and data transmission happens via a client-side validation model
Transaction data is self-hosted. The operator blindly signs and timestamps the individual statechain states and the transfer history gets passed on between clients. Due to the use of blind signing, the operator remains unaware of the transfer history.
Network Operators
High
🚨
The network operator is a single server
The Mercury Layer system employs a statechain entity that generates and updates key shares in addition to offering a blind signing service. Mercury Layer chooses a non-federated (i.e. centralized) setup for their service provider.
Finality Guarantees
Very High
🛑
Transaction settlement does not rely on onchain confirmations. Users are not safeguard against the statechain entity double-spending their coin
Offchain finality guarantees in Mercury Layer are provided by the statechain operator deleting their previous keyshare. When a user receives a statecoin, they receive a new keyshare together with the operator’s new keyshare.
⚠️ Users do not have assurance that the statechain operator deleted their previous keyshare with the past owner of the statecoin.
The statechain entity can collude with the past owner of the UTXO, create a withdrawal transaction and steal the current owner’s funds.
⚠️ Users do not have assurance that the statechain operator deleted their previous keyshare with the past owner of the statecoin.
The statechain entity can collude with the past owner of the UTXO, create a withdrawal transaction and steal the current owner’s funds.
Bitcoin Security
Bitcoin finalizes statechain initiation and closures
Transactions within the Mercury Layer protocol are executed completely offchain. However, when a user exits the protocol, their exit transaction is validated by bitcoin miners.
The protocol does not enable MEV on bitcoin. Transaction verification happens via a client-side validation mechanism
Transaction verification is conducted via a client-side validation model. The statechain operator is not included in transaction ordering or verification.
No alternative token is being introduced
Mercury Layer currently uses Bitcoin UTXOs as the main and only asset being transferred in the network. No other token is used for the operation of the protocol.
Mercury Layer does not contribute to the security budget
Statechain transfers occur offchain through key share updates and the pre-signing of backup transactions, with onchain fees incurred only during statechain initiation or closure.
Custom score assigned
Medium score assigned to Mercury Layer custody mechanism
Mercury Layer has been assigned a medium score for custody in the project assessment page. This is due to situational differences in custody. As noted in BTC Custody, a user retains custody of their funds when depositing into the protocol. But as noted in the finality section, they trust an honest operator to delete their previous keyshare.
If the operator does not do this, they can collude with a prior owner of the statechain UTXO to steal a user's funds
If the operator does not do this, they can collude with a prior owner of the statechain UTXO to steal a user's funds
Statechains only allow for fixed-value transfers
Mercury Layer facilitates the offline transfer of UTXO ownership through the transfer of private key shares. Ownership transfer and not involving Bitcoin L1 interaction implies that UTXOs cannot be split and must always be transferred as a whole.
Withdrawals
Users can unilaterally exit given the statechain entity doesn’t collude with a previous statecoin owner
Mercury Layer permits unilateral exits. To reclaim full UTXO ownership on bitcoin L1, the current owner can close the statechain by creating an onchain transaction that spends the UTXO. In an orderly closure, the statechain operator co-signs this transaction with its key share. In an uncooperative scenario, the statecoin owner can use their backup transaction to reclaim the UTXO onchain after a timelock expiry.
Technology
Blind signing server
Mercury Layer employs a blind signing server that has two functions. One, it can create partial blind signatures to co-sign statechain transfers together with the user using a variant of MuSig2. Second, the Mercury Layer server can update the key shares needed for co-signing.
The operator uses an HSM for key handling and key deletion after cosigning each new holder's withdrawal transaction.
The operator uses an HSM for key handling and key deletion after cosigning each new holder's withdrawal transaction.
Adding a decrementing timelock to the backup transaction
In the absence of covenants, which could invalidate old transactions, Mercury Layer employs nLocktime with decrementing timelocks to ensure users can reclaim their bitcoin L1 funds in case of server failure or attempted misbehavior of previous owners. Each time a statechain is transferred to a new owner, the timelock on the backup transaction is reduced. By progressively decreasing the timelock, Mercury Layer enables the current owner to claim the L1 funds before a previous owner can do so by publishing an old backup transaction.
Use Cases
Enhanced privacy with blind statechains
The blinding feature of MuSig2 prevents the statechain entity from learning about transaction details, such as the TxID, the full shared public key, the final signature it co-generates, or any information about statechain closure transactions.
Source Code
Code is open-source
Mercury Layer code is open-source available under the terms of the GNU General Public License.
Knowledge Bits
Learn more
Statechains Whitepaper by Ruben Somsen (GitHub, Oct 2018)
Statechains: Non-custodial Off-chain Bitcoin Transfer by Ruben Somsen (Medium, Jun 2019)
Mercury Layer's Lightning Latch Swap Protocol by Shinobi (BM, Mar 2024)
Nicholas Gregory on Mercury Layer, Lightning Network, and More | Bitfinex Talk (Youtube, May 2024)
Statechains: Non-custodial Off-chain Bitcoin Transfer by Ruben Somsen (Medium, Jun 2019)
Mercury Layer's Lightning Latch Swap Protocol by Shinobi (BM, Mar 2024)
Nicholas Gregory on Mercury Layer, Lightning Network, and More | Bitfinex Talk (Youtube, May 2024)