---
title: "Атомарный своп"
description: "Атомарный своп координирует условные требования и последующие возвраты в двух сетях, но не синхронизирует подтверждения и не устраняет комиссии, ценовой риск, мониторинг и риск тайм-аута."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Атомарный своп
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Атомарный своп — асинхронный протокол обмена активами, при котором один кастодиан не получает контроль над обеими сторонами сделки. В классической схеме хешированного контракта с временной блокировкой (`HTLC`) один прообраз разрешает оба требования, а неодинаковые сроки сохраняют последующие пути возврата. Атомарность условна: честная сторона не должна потерять основную сумму в пользу контрагента только из-за прерывания обмена. Она не означает одновременного подтверждения, автоматического или бесплатного возврата, справедливой рыночной цены, постоянной ликвидности или анонимности.
Каждая реализация должна однозначно связывать сеть, актив и контракт, сырую сумму и разрядность, ключи получателя и возврата, конструкцию хеша, точные байты прообраза, скрипт или байт-код и семантику временной блокировки. Две системы не становятся совместимыми лишь потому, что обе предоставляют хеш и часы. Абсолютные и относительные блокировки Bitcoin, временные метки EVM и финальность другой сети могут иметь существенно разные правила.
Классические свопы `HTLC` также дают стороне, действующей последней, некоторую ценовую опциональность: она может медлить, решая, выгодно ли еще исполнение. Адапторные подписи и другие бессценарные протоколы меняют ончейн-след и допущения, но не отменяют аудит идентичности, часов, комиссий, доступности и восстановления.
## Как это работает
1. Зафиксируйте обе сети, активы, суммы, обменный курс, ключи, кодировку хеша и прообраза, байты контракта или скрипта, единицы времени, плательщика комиссий и правила подтверждения или финальности.
2. Создайте одноразовый секрет с высокой энтропией `x`, офлайн вычислите `h = H(x)` и добейтесь, чтобы обе реализации получили тот же дайджест из одинаковых сырых байтов.
3. Инициатор финансирует сторону с более длинным тайм-аутом. Участник проверяет сеть, актив, сумму, ключи, хеш, код и срок, затем ждет согласованной глубины безопасности.
4. Участник финансирует сторону с более коротким тайм-аутом. Инициатор повторяет те же проверки и ждет требуемых подтверждений или финальности.
5. До более ранней операционной отсечки инициатор требует короткую сторону с помощью `x`, раскрывая точный прообраз в канонических данных транзакции.
6. Участник наблюдает требование, проверяет `H(x) = h` и требует длинную сторону, оставляя достаточно времени на создание, трансляцию, повышение комиссии и финальность.
7. Если любой контроль не пройден, прекратите увеличивать риск. После созревания соответствующей временной блокировки активно создайте или передайте транзакцию возврата и сверьте основную сумму, комиссии, длительность блокировки и доказательства обеих сетей.
Основной временной бюджет: `T_long - T_short >= observation + construction + broadcast + confirmation/finality + reorg/operations buffer`. Номинальные 48 и 24 часа — лишь примеры, а не универсально безопасные параметры. Временная блокировка только открывает путь возврата; она не передает транзакцию и не оплачивает ее комиссию.
## Пример
- **Байты хеша.** Только для обучения: строка UTF-8 `abc` соответствует сырым байтам `0x616263`; `SHA-256(0x616263) = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad`. Хеширование отображаемого текста `0x616263` даст другой дайджест. Рабочие секреты должны иметь криптографическую энтропию и не использоваться повторно.
- **Бюджет тайм-аута.** Пусть длинный возврат созревает через `48.0 h`, а короткий — через `24.0 h`. Если короткое требование подано через `22.0 h`, наблюдение занимает `0.5 h`, создание и трансляция — `0.5 h`, а подтверждение длинной сети — `1.5 h`, ожидаемое завершение наступит через `24.5 h`. Расчетный оставшийся запас длинной стороны равен `48.0 - 24.5 = 23.5 h`; это не гарантия выпуска блоков.
- **Ценовая опциональность.** При договоренности `1 BTC` по `$60,000` равен `20 ETH` по `$3,000`. При погашении BTC стоит `$63,000`, а ETH — `$2,800`; Алиса отдает `$63,000` и получает `20 x $2,800 = $56,000`, то есть разница с текущим рынком составляет `-$7,000` до комиссий. Атомарность протокола не фиксирует экономическую стоимость.
- **Учет прерывания.** Алиса платит `0.00020 BTC` за финансирование и `0.00025 BTC` за возврат, всего `0.00045 BTC`, или `$27` при `$60,000/BTC`. Боб платит `0.006 ETH` за финансирование и `0.004 ETH` за возврат, всего `0.010 ETH`, или `$30` при `$3,000/ETH`. Основная сумма возвращается позднее, но совокупные невозвратные сетевые расходы составляют `$57` плюс альтернативные издержки.
## Риски
- Неверный домен сети.
- Неверный нативный актив, контракт токена или разрядность.
- Неверная сумма, ключ требования или ключ возврата.
- Несовместимый алгоритм хеширования или кодировка байтов.
- Слабый, повторно используемый или преждевременно раскрытый секрет.
- Дефект пути требования, скрипта или байт-кода.
- Недействительный, недоступный или неподписанный путь возврата.
- Обратный порядок тайм-аутов или недостаточный запас.
- Неверная трактовка высоты, медианного времени, метки времени или относительной блокировки.
- Гонка короткого требования и возврата около истечения срока.
- Реорганизация удаляет финансирование, раскрытие или требование.
- Недостаточная политика подтверждения или финальности.
- Скачок комиссии, удаление из mempool, цензура или невозможность повысить комиссию.
- Сбой мониторинга, RPC, индексатора, кошелька или ключа.
- Задержка контрагента, грифинг и опциональность заблокированного капитала.
- Изменение курса, базиса и исполнимой ликвидности.
- Дефект вызова EVM, повторного входа, газа, прокси или обновления.
- Поведение обернутого актива, эмитента, моста, хука, ребейза или комиссии перевода.
- Межсетевое связывание по хешу, сумме и времени.
- Налоговый, санкционный, юридический, учетный сбой или отказ аварийного восстановления.
## Распространенные заблуждения
- **Атомарность означает одновременность.** Две сети развиваются независимо в упорядоченном асинхронном автомате состояний.
- **Прерывание автоматически все возвращает.** Обычно сторона должна дождаться срока, провести транзакцию и заплатить комиссию; сбой мониторинга или комиссии может продлить блокировку.
- **Любые две сети с хешами и временными блокировками совместимы.** Алгоритмы, кодировки, часы, скрипты, контракты и финальность должны совпадать фактически.
- **Отсутствие кастодиана исключает риск контрагента и цены.** Грифинг, опциональность, волатильность и операционная зависимость сохраняются.
- **Атомарные свопы дают ликвидность и приватность.** Они координируют условия расчета, но не создают котировки, глубину, контрагентов или несвязываемую активность.
## Связанные темы
- [Хешированный контракт с временной блокировкой](/ru/crypto/htlc/)
- [Межсетевой мост](/ru/crypto/cross-chain-bridge/)
- [Децентрализованная биржа](/ru/crypto/dex/)
## Источники
- [Atomic Cross-Chain Swaps](https://doi.org/10.1145/3212734.3212736) - Association for Computing Machinery (дата обращения: 2026-08-13)
- [On the optionality and fairness of Atomic Swaps](https://doi.org/10.1145/3318041.3355460) - Association for Computing Machinery (дата обращения: 2026-08-13)
- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-13)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-13)
- [Contracts](https://developer.bitcoin.org/devguide/contracts.html) - Bitcoin Developer Documentation (дата обращения: 2026-08-13)
- [Transactions](https://developer.bitcoin.org/devguide/transactions.html) - Bitcoin Developer Documentation (дата обращения: 2026-08-13)
- [Atomic Swaps](https://docs.decred.org/advanced/atomic-swap/) - Decred Documentation (дата обращения: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/atomic-swap/index.mdx