Submarine swap は HTLC を on-chain と Lightning に跨いで構成することで、両層間の atomic な資金移動を可能にする。 Loop (Lightning Labs) や Boltz がプロバイダとして動作し、ユーザーは on-chain → LN（Loop In）または LN → on-chain（Loop Out）の流動性転換が可能。 Channel rebalancing・on-ramp / off-ramp・LSP-free 流動性確保のための主要 primitive。
routing node が outbound に偏った channel を持つ場合、新規 inbound が必要。channel close なしで実現したい。
LN で稼いだ sats を cold storage / 取引所に移したい。channel close せずに実現。
on-chain BTC を LN に投入したいが、新 channel 開設は cost が高い。既存 channel に注入したい。
CEX 経由なら簡単だが信託リスク。暗号学的に atomicな解が欲しい。
HTLC の preimage 開示が on-chain でも LN でも同じ意味を持つこと（同一 hash）を活用し、 2 つの layer 間で同一 preimage に lock された支払いを構成する。受け取り側が preimage を開示すれば両側が同時に解錠される → atomic。
Submarine swap の暗号学的本質は 同じ payment_hash H に対する 2 つの HTLC を 2 layer に跨いで作ること。
routing node や mobile wallet が LN に蓄積した sats を on-chain で受け取りたいケース。channel を close せずに実現。channel の outbound liquidity が消費され、inbound liquidity が増える（rebalancing 効果も持つ）。
User の LN HTLC が timeout → refund。on-chain HTLC も timeout → Provider の resources lost。両者損失なしで cancel。
User がオフライン → on-chain HTLC の preimage 期限まで R を回収できない。User 側 fund 失うリスク。watchtower / 監視 service が必要。
Bitcoin mempool 混雑時、on-chain HTLC の confirmation 遅延 → CLTV 設計バッファが狭まる。
on-chain HTLC が pinning attack を受けると preimage path が closed できず資金 stuck。anchor outputs が部分対策。
Submarine swap は 暗号学的に atomic。Provider が rug-pull することはできない。 ただし on-chain で sweep する責任は user にあるため、長期 offline は危険。 実質的には Provider への liveness 信頼（最終的に preimage を出すこと）と user 側 watchtowerが必要。
| Provider | 運営 | Loop In | Loop Out | API | Wallet 統合 |
|---|---|---|---|---|---|
| Loop | Lightning Labs | ✓ | ✓ | gRPC + REST | LND CLI / 多くの wallet |
| Boltz | Boltz Exchange | ✓ | ✓ | REST + WS | BlueWallet / web |
| Boltz Reverse | Boltz | N/A | ✓ (no-account) | REST | 多数 (Phoenix 等) |
| 10101 | 10101 Finance | 部分 | 部分 | REST | 10101 wallet |
| Self-hosted (Boltz Pro) | 個人運営 | 構築要 | 構築要 | self | — |
Boltz の Reverse モードは特に重要。account-less で Loop Out を実現するため、web wallet や mobile wallet がワンタップで利用できる。 Phoenix・Mutiny・Strike の多くがこの方式を内部で使う。
| アプローチ | Counterparty | cost 構造 | 使用ケース | trust |
|---|---|---|---|---|
| Submarine Swap | Third-party (Loop/Boltz) | service fee + 2 on-chain TX | 個別の流動性転換 | Atomic (HTLC) — provider rug-pull 不可 |
| Splicing | Channel counterparty | 1 on-chain TX | capacity 増減 | counterparty 同意必須 |
| Close + Reopen | Channel counterparty | 2 on-chain TX | 大幅な channel 戦略変更 | scid 失う / down-time |
| Custodial swap (CEX) | Exchange | 取引所 fee | UX 重視 | 取引所信託 risk |
| シナリオ | 推奨 |
|---|---|
| routing node の inbound liquidity 確保 | Splicing（counterparty と OK）または Loop Out |
| 個人 wallet を on-chain wallet に移転 | Boltz Reverse |
| 大口 cold storage への移行 | Close + Reopen（節約優先） |
| Anonymity 重視 | Submarine Swap（third-party 経由） |
| UX 最優先（custodial OK） | CEX 経由（最後の手段） |