Submarine Swap зазвичай обмінює on-chain біткоїн на платіж Lightning; Reverse Submarine Swap працює навпаки. Хешові й часові умови пов’язують гілки, щоб клієнт із правильною перевіркою не передавав сервісу необмеженого зберігання основної суми.
У звичайному свопі користувач блокує on-chain біткоїн, а сервіс оплачує його рахунок Lightning. У Reverse Submarine Swap він надає умовний платіж Lightning та отримує on-chain вихід. Це не обов’язково обмін на іншу валюту чи просте закриття власного каналу. [Boltz — Swap types and states]
Preimage, що відповідає хешу SHA256, дозволяє завершити пов’язаний платіж і отримати заблокований вихід. У зворотному процесі клієнт створює preimage, а сервіс тримає HTLC Lightning в очікуванні до розкриття. On-chain claim може розкрити секрет; кооперативний шлях може передати його сервісу поза ланцюгом. Незавершений платіж не є остаточним розрахунком. [Boltz — Swap types and states] [Lightning Loop — Architecture]
До фінансування клієнт має перевірити мережу, суми з комісіями, хеш, ключі, строк і прив’язку скрипту або дерева Taproot до цільової адреси. Рахунок має відповідати погодженому хешу та сумі. Правильна криптографія не допоможе, якщо застосунок без перевірки платить на довільну адресу з API. [Boltz — Client verification]
Свопи Taproot можуть використовувати підпис MuSig2 key-path обох сторін, заощаджуючи місце й приховуючи скрипт. Якщо інша сторона не співпрацює, клієнт має підтримувати відповідний script-path claim або refund. Швидке кооперативне повернення додає можливість, а не скасовує часову умову одностороннього відновлення. [Boltz — Claims and refunds] [Lightning Loop — Architecture]
Для невдалого звичайного свопу з уже заблокованими on-chain коштами клієнт активно створює й транслює refund-транзакцію; односторонній шлях чекає на timelock. Для нерозрахованого зворотного платежу Lightning HTLC може скасуватися й розблокувати кошти без такої транзакції користувача. Після розкриття preimage не можна очікувати автоматичного повернення вже розрахованого платежу. [Boltz — Swap types and states] [Boltz — Claims and refunds]
Своп має сервісні, маршрутні й on-chain витрати; невдалий звичайний своп може додати комісію повернення. Розкриття preimage до підтвердження claim створює перегони зі строком. Loop прямо описує, що підвищення комісії sweep поблизу timeout може перевищити початкову межу. Оцінка ціни не є безумовним обмеженням усіх ризиків. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]
Зберігайте refund-ключ або rescue key і дані свопу відповідно до клієнта; звичайний seed іншого гаманця не є універсальним відновленням свопу. Boltz restore виводить ключі й шукає свопи, але сам xpub не підписує. Важливі також скрипт, вихід і timeout, а не лише ідентифікатор сервісу. [Boltz — Swap restore] [Boltz — Claims and refunds]
У зворотному процесі Boltz invoice.settled може означати розрахунок рахунку Lightning після розкриття preimage, тоді як Boltz не відстежує, чи клієнт транслював claim. Перевірте свій цільовий вихід і потрібні підтвердження перед завершенням або повторенням платежу. Taproot key-path зменшує видимість скрипту, а не знання провайдера про суми й час. [Boltz — Swap types and states] [Boltz — Client verification]
Для повної картини прочитайте також Lightning Network, HTLC, Inbound Liquidity, Taproot, MuSig2, CHECKLOCKTIMEVERIFY. На цю статтю також посилаються Ліквідність Lightning, Inbound Liquidity, Boltz.