Submarine Swap biasanya menukar bitcoin on-chain dengan pembayaran Lightning; Reverse Submarine Swap berarah sebaliknya. Kondisi hash dan waktu menghubungkan kedua sisi agar klien yang memverifikasi dengan benar tidak perlu memberikan kustodi pokok tanpa batas kepada layanan.
Dalam swap biasa, pengguna mengunci bitcoin on-chain dan layanan membayar invoice Lightning miliknya. Pada Reverse Submarine Swap, pengguna memberikan pembayaran Lightning bersyarat dan mengklaim keluaran on-chain. Ini tidak selalu pertukaran ke mata uang lain atau sekadar menutup kanal sendiri. [Boltz — Swap types and states]
Preimage yang cocok dengan hash SHA256 memungkinkan pembayaran terkait selesai dan keluaran terkunci diklaim. Dalam alur terbalik, klien membuat preimage dan layanan menahan HTLC Lightning sebagai tertunda sebelum pengungkapan. Claim on-chain bisa mengungkap rahasia; jalur kooperatif dapat memberikannya ke layanan di luar rantai. Pembayaran tertunda belum merupakan penyelesaian akhir. [Boltz — Swap types and states] [Lightning Loop — Architecture]
Sebelum mendanai, klien harus memverifikasi jaringan, jumlah termasuk biaya, hash, kunci, tenggat dan ikatan skrip atau pohon Taproot ke alamat tujuan. Invoice harus sesuai hash dan jumlah yang disepakati. Kriptografi benar tidak membantu jika aplikasi tanpa pemeriksaan membayar alamat sembarang dari API. [Boltz — Client verification]
Swap Taproot dapat memakai tanda tangan MuSig2 key-path kedua pihak, menghemat ruang dan menyembunyikan skrip. Jika pihak lain tidak bekerja sama, klien harus mendukung claim atau refund script-path yang sesuai. Pengembalian kooperatif cepat menambah pilihan, bukan menghapus kondisi waktu pemulihan sepihak. [Boltz — Claims and refunds] [Lightning Loop — Architecture]
Pada swap biasa yang gagal dengan dana on-chain terkunci, klien aktif membuat dan menyiarkan transaksi refund; jalur sepihak menunggu timelock. Untuk pembayaran Lightning terbalik yang belum selesai, HTLC dapat dibatalkan dan dana dilepas tanpa transaksi pengembalian pengguna tersebut. Setelah preimage diungkap, jangan menganggap pembayaran yang sudah selesai otomatis kembali. [Boltz — Swap types and states] [Boltz — Claims and refunds]
Swap memiliki biaya layanan, perutean dan on-chain; swap biasa yang gagal bisa menambah biaya refund. Mengungkap preimage sebelum claim dikonfirmasi menciptakan perlombaan dengan tenggat. Loop secara tegas menjelaskan bahwa menaikkan biaya sweep mendekati timeout bisa melampaui batas awal. Perkiraan harga bukan batas tanpa syarat atas seluruh risiko. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]
Simpan kunci refund atau rescue key dan data swap sesuai klien yang digunakan; seed biasa dari dompet lain bukan pemulihan swap universal. Boltz restore menurunkan kunci dan mencari swap, tetapi xpub sendiri tidak bisa menandatangani. Skrip, keluaran dan timeout juga penting, bukan hanya pengenal layanan. [Boltz — Swap restore] [Boltz — Claims and refunds]
Dalam alur terbalik Boltz, invoice.settled dapat berarti invoice Lightning selesai setelah pengungkapan preimage, sementara Boltz tidak melacak apakah klien menyiarkan claim. Verifikasi keluaran tujuan sendiri dan konfirmasi yang diperlukan sebelum menandai selesai atau mengulang pembayaran. Taproot key-path mengurangi keterlihatan skrip, bukan pengetahuan penyedia tentang jumlah dan waktu. [Boltz — Swap types and states] [Boltz — Client verification]
Untuk gambaran yang lebih utuh, baca entri ini bersama Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CHECKLOCKTIMEVERIFY. Entri ini juga dirujuk dari Likuiditas Lightning, Inbound Liquidity, Boltz.