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.