What Are Cross-Layer Swaps?
Bitcoin operates across multiple protocol layers, each built for a different purpose. The Bitcoin mainchain provides final settlement with the strongest security guarantees in the network. The Lightning Network enables instant, low-fee payments. The Liquid Network adds Confidential Transactions (hiding both asset types and transaction amounts) and one-minute block times.
These layers are not isolated from each other. Cross-layer swaps allow you to move bitcoin between them, converting from one layer's format to another without selling or depositing into an exchange. When you perform a Lightning ↔ Liquid swap, your Lightning bitcoin becomes LBTC on the Liquid Network. When you perform an on-chain ↔ Liquid swap, your mainnet bitcoin becomes LBTC, or vice versa.
The critical property of these swaps is atomicity. A well-designed cross-layer swap either completes in full or reverts entirely. You never end up in a state where you sent bitcoin on one layer but failed to receive it on another. This property comes from the same cryptographic primitives that secure Bitcoin itself.
Cross-layer swaps differ from cross-chain swaps. Cross-chain swaps exchange assets between entirely different blockchains (Bitcoin for Monero, for example). Cross-layer swaps move the same underlying asset between different layers of the Bitcoin protocol stack. You start with bitcoin and end with bitcoin.
Why Cross-Layer Swaps Matter
Each Bitcoin layer makes a different tradeoff.
The Bitcoin mainchain optimizes for security and finality. Every transaction is validated by the full network of nodes and miners. Once a transaction has six confirmations, it is practically irreversible. The cost: blocks arrive roughly every ten minutes, and fees vary with demand.
The Lightning Network optimizes for speed. Payments settle in seconds and cost fractions of a sat. The tradeoff is that funds must sit in payment channels, which require on-chain transactions to open and close.
The Liquid Network optimizes for privacy and settlement speed. Confidential Transactions hide both transaction amounts and asset types from outside observers. Blocks arrive every minute. The tradeoff is a federated security model: functionaries sign blocks and manage the peg between mainnet bitcoin and LBTC.
No single layer is the best choice for everything. A user who receives a Lightning payment might want to move it to Liquid for privacy or to mainchain for final settlement. A trader who holds mainnet bitcoin might need to move it to Liquid for fast, confidential trading. A user with LBTC who needs to pay a Lightning invoice needs to convert between layers instantly.
Without cross-layer swaps, each of these conversions would require a centralized exchange. Cross-layer swaps eliminate that friction and keep the user in control of their keys throughout.
Lightning ↔ Liquid Swaps
Lightning ↔ Liquid swaps convert between Lightning bitcoin and LBTC on the Liquid Network. These swaps are bidirectional: you can send Lightning and receive LBTC, or send LBTC and receive Lightning. The swap typically completes in under a minute.
How a Lightning ↔ Liquid Swap Works
The swap uses a swap provider that holds liquidity on both layers. The underlying protocol is a variant of a submarine swap, where Hash Time-Locked Contracts (HTLCs) coordinate payments across two different networks using a shared SHA-256 hash preimage. The HTLC construction on Lightning follows the format defined in BOLT 2 (peer protocol for channel operation) and BOLT 3 (transaction formats), while the Liquid-side HTLC uses Elements Script, which extends Bitcoin Script with Confidential Transaction support. Here is the process for converting Lightning bitcoin to LBTC:
- You initiate the swap, specifying the amount you want to convert.
- The swap provider generates a cryptographic hash and creates an HTLC on the Liquid Network, locking the equivalent LBTC.
- You pay a Lightning invoice that is locked to the same hash. Your Lightning payment can only be claimed by someone who knows the hash preimage.
- The swap provider reveals the preimage to claim your Lightning payment. Simultaneously, revealing the preimage allows you to claim the locked LBTC on Liquid.
- The swap is complete. You hold LBTC; the provider holds Lightning bitcoin.
The reverse direction (LBTC to Lightning) follows the same logic in mirror. You lock LBTC in an HTLC on Liquid, and the swap provider pays you via Lightning. The cryptographic lock ensures atomicity in both directions.
How Atomic Swaps Work Under the Hood
An atomic swap is an exchange of bitcoin between two parties or two layers that either completes in full or not at all, with no intermediate state where one side has been paid and the other has not. It uses a shared cryptographic lock so that claiming one side automatically enables the other side to be claimed, which removes the need to trust a custodian or exchange.
The atomicity of cross-layer swaps depends on a single cryptographic primitive: the hash preimage. Before the swap begins, one party generates a random 32-byte secret (the preimage) and computes its SHA-256 hash. This hash becomes the lock for both sides of the swap.
On the Lightning side, the hash is embedded in the payment invoice as the payment_hash field defined in BOLT 11 (invoice protocol). The Lightning sender's payment can only be claimed by a node that reveals the matching preimage. On the Liquid side, the same hash is used in a Script condition: OP_SHA256 <hash> OP_EQUAL, requiring the preimage to spend the locked LBTC output.
The timelocks are staggered to prevent race conditions. The HTLC on the first layer (where the swap initiator locks funds) has a longer timeout than the HTLC on the second layer. This ensures the initiator always has time to claim their funds after the preimage is revealed, even if the counterparty delays. In Lightning, timelocks are expressed in blocks via the cltv_expiry field (BOLT 2). On Liquid, timelocks use OP_CHECKLOCKTIMEVERIFY in Elements Script, with timeouts calculated against Liquid's one-minute block cadence.
If the preimage is never revealed, both HTLCs expire independently and each party reclaims their locked funds. There is no state where funds are stranded: either the preimage unlocks both sides, or the timelocks return both sides. This guarantee holds even if the swap provider goes offline mid-swap, because the refund path is enforced by the script itself, not by any third party.
The Blockstream app performs Lightning ↔ Liquid swaps from a single interface. The underlying HTLC mechanics are handled automatically. From the user's perspective, the process looks like sending bitcoin on one layer and receiving it on another within seconds.
Speed and Fees
Lightning ↔ Liquid swaps are fast because neither layer requires on-chain Bitcoin confirmation. The Lightning payment settles in seconds. The Liquid transaction confirms in approximately one minute. Total swap time is typically under one minute, with the Liquid confirmation being the bottleneck.
Fees include the Lightning routing fee (usually a few sats), the Liquid network fee (approximately 0.1 sat/vbyte), and the swap provider's service fee (typically 0.1-0.5% of the swap amount). Combined, these are substantially lower than centralized exchange fees, withdrawal fees, and spread costs.
On-Chain ↔ Liquid Swaps
On-chain ↔ Liquid swaps move bitcoin between the Bitcoin mainchain and the Liquid Network. The mechanisms differ depending on the direction.
Peg-In: Mainnet Bitcoin to LBTC
A peg-in converts mainnet bitcoin into LBTC. The process works through the Liquid Federation's multisig custody mechanism:
- You send bitcoin to the Liquid Federation's multisig address on the Bitcoin mainchain.
- The Bitcoin transaction requires 102 confirmations (approximately 17 hours) before the peg-in completes. This confirmation depth protects against deep chain reorganizations.
- After 102 confirmations, the Liquid Federation issues an equivalent amount of LBTC on the Liquid Network, minus a small fee.
- Your LBTC appears in your Liquid wallet, pegged 1:1 to the bitcoin you deposited.
The 102-confirmation requirement exists for security. A shorter confirmation window would expose the federation to the risk of issuing LBTC against a Bitcoin transaction that later gets reversed in a chain reorganization. For the Liquid peg to maintain its 1:1 backing, the depth of finality must be high.
Peg-Out: LBTC to Mainnet Bitcoin
A peg-out converts LBTC back to mainnet bitcoin. The process involves the Liquid Federation releasing bitcoin from its multisig:
- You initiate a peg-out on the Liquid Network, specifying the destination Bitcoin address.
- The Liquid Federation validates the peg-out request and constructs a Bitcoin transaction sending the equivalent bitcoin to your address.
- Federation functionaries sign the transaction using their distributed signing protocol. This requires a threshold of signatures from the federation members.
- The signed transaction is broadcast to the Bitcoin network. After confirmation, the bitcoin arrives at your mainnet address.
Peg-outs are typically processed in batches by the federation. Total peg-out time ranges from around 20 minutes to a few hours, depending on batch timing and Bitcoin network congestion.
Simplified On-Chain ↔ Liquid in Practice
The Blockstream app simplifies on-chain ↔ Liquid conversion with built-in chain swaps. Rather than manually constructing peg transactions and tracking confirmations, the app handles the conversion. You select the amount, confirm the swap, and wait for it to complete.
For users who need faster on-chain ↔ Liquid conversion than the 102-confirmation peg-in allows, swap providers can facilitate instant swaps using their own LBTC reserves. The provider sends you LBTC immediately while waiting for the peg-in to settle. This is functionally a swap against the provider's liquidity, not a true peg-in, but the result is the same: you hold LBTC within minutes rather than hours.
On-Chain ↔ Lightning
Moving bitcoin between the mainchain and the Lightning Network can happen through two mechanisms: channel operations and submarine swaps.
Channel Operations
The native way to move bitcoin onto Lightning is to open a payment channel. This requires an on-chain transaction that locks bitcoin into a 2-of-2 multisig output shared between you and your channel partner. Once confirmed on-chain, the locked bitcoin becomes available for Lightning payments.
Moving bitcoin off Lightning means closing a channel. The final channel state is broadcast as an on-chain transaction, and the settled balance returns to each party's on-chain wallet. Cooperative channel closes confirm quickly. Force-closes require waiting for a timelock to expire (typically one to two weeks).
Channel operations are effective but slow. Every open and close requires on-chain confirmation, which makes channel operations impractical for quick one-off conversions.
Submarine Swaps
Submarine swaps provide a faster, more flexible mechanism for on-chain ↔ Lightning conversion. A submarine swap uses an HTLC to atomically exchange on-chain bitcoin for a Lightning payment (or vice versa) through a swap provider. The on-chain HTLC is a standard Bitcoin Script output using OP_SHA256 and OP_CHECKLOCKTIMEVERIFY, while the Lightning HTLC follows the construction defined in BOLT 3 (commitment transaction format). The term "submarine" refers to the fact that one leg of the swap is "submerged" off-chain on Lightning, invisible to the blockchain.
For on-chain to Lightning:
- You want to receive a Lightning payment but only have on-chain bitcoin.
- A swap provider generates a Lightning invoice and a corresponding HTLC on-chain.
- You pay the on-chain HTLC. Once confirmed, the provider pays the Lightning invoice on your behalf.
- The hash preimage links both transactions, ensuring atomicity.
For Lightning to on-chain (reverse submarine swap):
- You want on-chain bitcoin but only have Lightning balance.
- A swap provider creates an on-chain HTLC locked to a hash.
- You pay a Lightning invoice locked to the same hash.
- The provider reveals the preimage to claim your Lightning payment and the on-chain HTLC releases bitcoin to your address.
Submarine swaps inherit the speed characteristics of both layers: the Lightning side settles instantly, but the on-chain side requires confirmation. Total swap time is typically ten minutes to an hour, dominated by the Bitcoin mainchain confirmation.
The Technical Mechanics
Cross-layer swaps rely on a small set of cryptographic primitives. Understanding these primitives reveals why the swaps work without trust.
Hash Time-Locked Contracts (HTLCs)
An HTLC is a conditional payment: "I will pay you X bitcoin if you can produce the preimage of this hash within T blocks." The contract has two spending paths:
- Hash lock path: The recipient can claim the funds by revealing a value (the preimage) whose SHA-256 hash matches the hash embedded in the contract.
- Time lock path: If the preimage is not revealed before the timelock expires, the sender can reclaim the funds.
By linking HTLCs across different layers using the same hash, swaps become atomic. Revealing the preimage on one layer necessarily makes it available on the other, since the same preimage satisfies both HTLCs. Either both parties get their funds or both get refunded.
Atomic Swap Guarantees
The atomicity guarantee comes from the relationship between the hash lock and the preimage. Consider a Lightning ↔ Liquid swap:
- Party A locks LBTC on Liquid with hash H.
- Party B locks Lightning bitcoin with the same hash H.
- If Party A claims the Lightning bitcoin by revealing preimage P, then Party B can use the same preimage P to claim the LBTC.
- If neither party reveals the preimage before the timelock, both parties reclaim their funds.
There is no intermediate state where one party has both assets. The mathematics of hash functions make it computationally infeasible to claim one side without exposing the preimage needed to claim the other.
Trust Minimization
Different swap types have different trust profiles:
- Lightning ↔ Liquid (via HTLC): Trustless between the two parties. The swap provider cannot steal funds because they cannot claim the HTLC without revealing the preimage, which simultaneously enables the counterparty to claim their side. The only trust assumption is standard Lightning and Liquid network operation.
- On-chain ↔ Liquid (peg-in): You trust the Liquid Federation to honor peg-ins after 102 confirmations. The federation is a distributed group of functionaries, and issuing LBTC requires a threshold of their signatures. No single functionary can block or steal a peg-in.
- On-chain ↔ Liquid (peg-out): You trust the federation to process peg-out requests and release the corresponding mainnet bitcoin. The same threshold signing requirement applies.
- Submarine swaps: Trustless via HTLC. The swap provider has no opportunity to steal funds because the cryptographic lock governs the exchange.
In all cases, the trust requirements are dramatically lower than using a centralized exchange, where you surrender full custody of your bitcoin to a third party.
Practical Scenarios
The value of cross-layer swaps becomes clear in real usage patterns. Each scenario below traces a complete journey from start to finish.
Receiving Lightning, Storing on Hardware Wallet
You receive a payment over Lightning. The sats are in your Lightning balance, which is a hot wallet on your phone. You want to move them into cold storage secured by your hardware wallet.
Using a Lightning ↔ Liquid swap, the Lightning bitcoin converts to LBTC and lands in your Liquid wallet. If that Liquid wallet is secured by a Jade Plus ($149-169), the funds are now protected by hardware wallet security: air-gapped QR code signing, the blind oracle PIN verification model, and offline key storage. The swap takes under one minute. At no point do you send your bitcoin to an exchange or give up custody.
This is a pattern the Blockstream app and Jade Plus enable directly. You receive Lightning payments in the app, swap to Liquid, and secure the LBTC with your Jade Plus. The entire flow happens in one interface.
Mainnet Bitcoin to Fast Liquid Trading
You hold bitcoin on the mainchain and want to trade on a Liquid-based marketplace or exchange. On-chain transactions take ten minutes or more per confirmation, and mainchain trading platforms are subject to high fees and slow settlement.
You peg in your mainnet bitcoin to Liquid, converting it to LBTC. Once on Liquid, trades settle in one-minute blocks with Confidential Transactions hiding your amounts and asset types. You trade, and when you are done, you peg out back to mainnet bitcoin for long-term cold storage.
LBTC to Lightning Payment
Someone sends you a Lightning invoice for a service. Your bitcoin sits on the Liquid Network as LBTC. Rather than pegging out to mainchain and then funding a Lightning channel (a process that could take hours), you perform a Liquid ↔ Lightning swap. The LBTC converts to a Lightning payment that settles the invoice in seconds.
Privacy-First Storage
You receive bitcoin on the mainchain, where the transaction amount and your address are visible to anyone with a block explorer. You want to hold your bitcoin more privately.
You swap your mainnet bitcoin to Liquid. On the Liquid Network, Confidential Transactions hide both the amount and the asset type of your holdings. Outside observers can see that a transaction occurred, but they cannot determine how much you hold or what type of asset it is. For users concerned about on-chain surveillance, this is a meaningful privacy improvement.
Moving Between Layers for Different Needs
The general pattern: use each layer for what it does best, and swap between them as needs change.
- Long-term savings: Mainnet bitcoin. Maximum security, final settlement, full decentralization.
- Spending and payments: Lightning. Instant settlement, sub-sat fees, ideal for day-to-day transactions.
- Privacy and faster settlement: Liquid. Confidential Transactions, one-minute blocks, compatible with hardware wallet security.
Cross-layer swaps make this multi-layer strategy practical instead of theoretical. You keep your savings on mainchain, move spending money to Lightning, and use Liquid when privacy or settlement speed matters.
Fees and Tradeoffs
Every swap type has a different cost structure and set of tradeoffs. Understanding these helps you choose the right swap for the situation.
| Swap Type | Typical Fee | Speed | Trust Model | Best For |
|---|---|---|---|---|
| Lightning ↔ Liquid | 0.1-0.5% + routing fee | Under 1 minute | Trustless (HTLC) | Quick conversions, hardware wallet storage of Lightning receipts |
| On-chain ↔ Liquid (peg-in) | On-chain fee + small Liquid fee | ~17 hours (102 confirmations) | Federation trust | Large amounts moving to Liquid for trading or privacy |
| On-chain ↔ Liquid (peg-out) | On-chain fee + federation batch fee | 20 min to a few hours | Federation trust | Moving LBTC back to mainchain for final settlement |
| On-chain ↔ Lightning (submarine swap) | 0.1-1% + on-chain fee | 10 min to 1 hour | Trustless (HTLC) | Funding Lightning without opening channels, converting Lightning to on-chain |
| On-chain ↔ Lightning (channel open/close) | On-chain transaction fee | 10 min to 2 weeks (force close) | Trustless (Bitcoin Script) | Establishing long-term Lightning capacity |
Key Tradeoffs
Speed vs. trust: Lightning ↔ Liquid swaps are the fastest and fully trustless via HTLCs. Peg-ins are the slowest but use the strongest security model (102 Bitcoin confirmations). Submarine swaps fall in between.
Fee variability: On-chain fees fluctuate with Bitcoin mempool demand. During high-fee environments, Lightning ↔ Liquid swaps become relatively cheaper because they avoid on-chain transactions entirely. This makes the Lightning ↔ Liquid path particularly efficient during periods of mainchain congestion.
Amount limits: Lightning swaps are constrained by channel liquidity, both yours and the swap provider's. Liquid peg-ins have no practical minimum beyond the on-chain dust limit, but the 17-hour wait makes them impractical for small amounts. Choose the swap type based on both amount and urgency.
Privacy: Liquid swaps offer the strongest privacy because Confidential Transactions hide amounts and asset types. Lightning payments reveal amounts to routing nodes along the payment path. On-chain transactions reveal amounts publicly. If privacy is the priority, swapping to Liquid provides the most protection.
Cross-Layer Swaps vs. Traditional Exchanges
Before cross-layer swaps, moving bitcoin between layers meant using a centralized exchange as an intermediary.
| Cross-Layer Swaps | Centralized Exchange | |
|---|---|---|
| Custody | Self-custodial throughout. Your keys, your bitcoin. | You deposit bitcoin and trust the exchange to return it. |
| KYC | None required. | Government ID, proof of address, income verification. |
| Counterparty risk | None (HTLC-based) or minimal (federation-based). | Full counterparty risk. Exchange can freeze funds, get hacked, or go insolvent. |
| Speed | Seconds to minutes (Lightning ↔ Liquid). Hours for peg operations. | Deposit confirmation + processing + withdrawal. Often 30 minutes to 24+ hours. |
| Fees | Network fees + small swap fee (0.1-0.5%). | Trading fee (0.1-0.5%) + deposit fee + withdrawal fee + potential spread. |
| Privacy | No account. No personal data submitted. Liquid adds Confidential Transactions. | Full identity linked to every transaction. Transaction history stored by the exchange. |
| Availability | 24/7, no scheduled maintenance windows. | Subject to maintenance, outages, and regional restrictions. |
| Atomicity | Cryptographically guaranteed. Swap completes or reverts. | Multi-step process. Partial failures possible (deposit succeeds, withdrawal fails). |
The fundamental difference is custody. A cross-layer swap never requires you to hand your bitcoin to someone else. The swap completes atomically through cryptographic guarantees, or it does not happen at all. An exchange requires you to deposit, trust the exchange to process your trade correctly, and trust that it will let you withdraw.
Institutional Considerations
Cross-layer swap infrastructure has implications beyond individual users.
Liquidity Management Across Layers
Institutions holding bitcoin across multiple layers need efficient mechanisms to rebalance. A trading firm might keep operational bitcoin on Liquid for fast settlement and larger reserves on mainchain for custody security. Cross-layer swaps enable programmatic rebalancing between these pools without routing through external exchanges, which introduces counterparty risk and regulatory complexity.
Cross-layer swaps also affect capital efficiency. Bitcoin locked in a Lightning channel cannot simultaneously serve as collateral on Liquid. Cross-layer swaps let institutions move bitcoin to where it generates the most value, when it needs to be there.
Compliance and Layer Selection
Different jurisdictions and compliance frameworks may treat different layers differently. On-chain Bitcoin transactions are fully transparent and auditable. Liquid transactions use Confidential Transactions; senders and receivers can grant auditors or regulators selective visibility by sharing blinding keys. Lightning payments have different observability characteristics.
Institutional users can select layers based on compliance requirements for specific transactions or counterparties, using cross-layer swaps to move between them. A compliance-heavy transaction might settle on-chain for full auditability, while routine operational transfers might use Liquid for speed and privacy.
The Future of Cross-Layer Interoperability
Cross-layer swap infrastructure is still maturing. Several developments will shape how these swaps evolve.
Improved Swap Routing
Current cross-layer swaps typically involve a single swap provider. Future implementations could route swaps through multiple providers or liquidity pools, reducing dependence on any single entity and improving price competition. Automated routing could find the cheapest or fastest path across layers for a given swap.
Multi-Layer Wallets as Standard
The trend toward wallets that manage multiple layers from a single interface will make cross-layer swaps invisible to end users. Rather than thinking "I need to perform a Lightning ↔ Liquid swap", a user would simply send a payment, and the wallet selects the optimal layer and performs any necessary swaps automatically. The Blockstream app already moves in this direction by supporting Bitcoin, Lightning, and Liquid from one interface.
Faster Peg Operations
The 102-confirmation peg-in requirement is the largest friction point in on-chain ↔ Liquid interoperability. Research into alternative peg mechanisms, including optimistic pegs with fraud proofs and covenant-based peg designs, could significantly reduce this waiting period while maintaining security guarantees.
Protocol-Level Improvements
Bitcoin protocol upgrades like OP_CAT and other covenant proposals could enable more sophisticated cross-layer contracts directly in Bitcoin Script, expanding the types of atomic swaps possible and reducing contract complexity.
Frequently Asked Questions
Can I lose bitcoin during a cross-layer swap?
In a properly implemented atomic swap, no. HTLCs ensure that either both sides of the swap complete or neither does. If the swap fails for any reason (timeout, network issue, provider going offline), the time lock expires and your funds return to you. The cryptographic guarantees prevent any intermediate state where funds are lost. Specifically, the refund path in each HTLC is enforced by OP_CHECKLOCKTIMEVERIFY in the script itself, so reclaiming funds after a timeout does not depend on any third party being online or cooperative.
What is the difference between a cross-layer swap and a cross-chain swap?
A cross-layer swap moves bitcoin between different layers of the Bitcoin protocol stack (mainchain, Lightning, Liquid). The underlying asset is always bitcoin. A cross-chain swap exchanges assets between entirely different blockchains. Cross-layer swaps are generally faster, simpler, and more reliable because all layers share the same base protocol and the same cryptographic primitives. Both types use HTLCs for atomicity, but cross-layer swaps benefit from shared hash functions (SHA-256) and compatible scripting environments, which simplifies the preimage exchange and reduces the window for timing attacks.
Why does a Liquid peg-in take 102 confirmations?
The 102-confirmation requirement protects the Liquid peg's 1:1 backing. If the federation issued LBTC after only a few confirmations, a deep Bitcoin chain reorganization could reverse the deposit transaction while the LBTC remains in circulation. This would break the peg. The 102-confirmation depth makes such a reorganization economically infeasible, protecting all LBTC holders.
Do I need to run a node to perform cross-layer swaps?
No. Wallets like the Blockstream app handle the swap mechanics on your behalf, connecting to swap providers and managing the HTLC process. You maintain custody of your keys throughout. Running your own Lightning or Liquid node gives you more control and privacy, but it is not required for basic swap functionality.
Are cross-layer swaps private?
Privacy varies by layer. Swaps that involve the Liquid Network benefit from Confidential Transactions, which hide both amounts and asset types. Lightning payments reveal amounts to routing nodes along the route but not to the broader network; onion routing (defined in BOLT 4) ensures no single routing node knows both the sender and the final recipient. On-chain transactions are publicly visible. The highest privacy comes from swapping to Liquid, where Confidential Transactions protect your transaction details from outside observers. You can verify the on-chain legs of swap transactions using Blockstream Explorer, which supports Bitcoin (including the transactions that open and close Lightning channels) and Liquid.
What are the minimum and maximum amounts for cross-layer swaps?
Limits depend on the swap type and provider. Lightning ↔ Liquid swaps are constrained by channel liquidity and the provider's Liquid reserves. On-chain peg-ins have a very low minimum (above the dust limit) but the 17-hour wait makes small amounts impractical. Submarine swaps are limited by the provider's liquidity on both sides. Check your wallet's swap interface for current limits.