mercury-layer-primary-sources-2026-05-14

Mercury Layer primary sources

Reviewed: 2026-05-14 UTC

Official site overview

• https://mercurylayer.com/
  • Best concise public framing for what Mercury Layer says it is.
  • Used to confirm that Mercury describes itself as a blind co-signing and key-update service enabling Bitcoin statechains, with instant and zero-marginal-cost ownership transfer of UTXOs while retaining owner custody.

Intro / architecture summary

• https://docs.mercurylayer.com/docs/intro/
  • Best single entry point for the system model.
  • Used to confirm the narrow role of the Mercury blind server, the claim that all Bitcoin transaction operations and statechain verification are performed client side, the decrementing-nLocktime backup mechanism, and the blindness claims around UTXO identity and final signatures.

Main statechain protocol

• https://docs.mercurylayer.com/docs/mercury-protocol/main-protocol/
  • Best source for the step-by-step ownership-transfer mechanics.
  • Used to confirm the token_id-gated session initialization, shared public key construction from owner plus server key shares, backup-transaction generation, blind partial-signature flow, receiver-side verification requirements, key-share reassignment, orderly closure, and backup closure.

Atomic multi-coin transfer layer

• https://docs.mercurylayer.com/docs/mercury-protocol/atomic-transfer/
  • Best source for the project’s all-or-none transfer coordination layer.
  • Used to confirm the batch_id locking model, timeout behavior, sender/receiver unlock workflow, and the rule that no transfer in the batch completes unless all participants verify and unlock within the timeout window.

Lightning-coupled transfer layer

• https://docs.mercurylayer.com/docs/mercury-protocol/lightning-latch/
  • Best source for the Lightning integration that is analytically distinct from the base statechain.
  • Used to confirm that Mercury couples a statecoin transfer to a Lightning hodl invoice, generates and later releases the payment preimage, and explicitly documents that the server is trusted in this path even though it does not custody assets or learn payment contents.

Mainnet service-access and fee gating

• https://docs.mercurylayer.com/docs/token-payment/token-payment-process/
  • Best source for the operator-controlled service layer.
  • Used to confirm that mainnet use requires accepting terms and conditions, obtaining a token_id, and paying a fee, with verification then enabling initialization of a shared-key session.

Main takeaways from this pass

• Mercury Layer clears the corpus bar because it makes the statechain model unusually legible as separate layers: blind server-assisted signing, client-side backup verification, unilateral exit, and optional atomic / Lightning-coupled coordination.
• The strongest comparison is not to generic payment wallets but to Spark, Ark-style systems, and other Bitcoin offchain-ownership-transfer designs: Mercury keeps one UTXO in place and changes effective ownership through server-mediated key-share cycling instead of round-based VTXO creation or a broader token-issuance stack.
• The most important practical insight is that blindness pushes verification burden outward. Because the server cannot inspect what it signs, the receiver must verify the full backup history and signature count, so the core trust question is not custody alone but whether clients correctly validate history and whether the server really discards obsolete key shares.
• The Lightning Latch and atomic-transfer docs matter because they show Mercury is not only a statechain implementation but also a coordination layer for private barter, payment-versus-transfer, and all-or-none offchain exchange flows.