Краткий ответ

Торговым платформам и сетям расчетов необходимо работать вместе, поскольку они решают разные задачи в рамках одной и той же транзакции. Платформа обеспечивает доступ к рынку, прием ордеров, поиск цены, сопоставление заявок, принятие решений по марже и ликвидации. Сеть предоставляет общую запись данных о залоге и завершенных переводах. Если эти уровни не согласованы, трейдер может увидеть исполненную сделку, которую невозможно провести через расчеты, временно неверный баланс или ликвидацию на основе устаревшего состояния. Поэтому надежная архитектура должна содержать четкие правила того, когда сделка становится обязательной, как финальность в сети обновляет балансы счетов и что происходит, если любой из уровней замедляется или выходит из строя.

Торговля и расчеты — разные задачи

Рыночная транзакция выглядит как одно действие: нажать кнопку покупки, получить исполнение и увидеть обновление позиции. Однако внутри системы платформа принимает ордер, проверяет маржу, находит совпадение, рассчитывает комиссии и обновляет позицию. Затем расчеты делают соответствующий перевод или обязательство окончательным.

Такое разделение характерно не только для криптовалют. Традиционные рынки различают торговые площадки, клиринговые организации, центральных контрагентов, депозитарии ценных бумаг, кастодианов и платежные системы. Принципы CPMI-IOSCO для инфраструктур финансового рынка рассматривают финальность расчетов, риск ликвидности, операционный риск, управление и управление дефолтами как отдельные обязанности инфраструктуры.

Блокчейн-рынки меняют эту организацию, но соответствующие обязанности сохраняются. Рекомендации IOSCO по политике в сфере DeFi описывают архитектуры, в которых децентрализованная биржа направляет сопоставленный ордер для исполнения и расчетов в блокчейне. Поиск совпадения и завершение соответствующего перехода состояния могут происходить в связанных, но отдельных компонентах.

Торговая платформа организует намерения

Ордера выражают намерение, а не окончательное право собственности. Лимитный ордер означает, что трейдер готов совершить сделку по указанной цене. Платформа должна аутентифицировать эту инструкцию, применить рыночные правила, сопоставить ее с другими ордерами и определить, существует ли совпадение. Для деривативов она также должна проверить обеспечение и лимиты позиций, прежде чем принимать дополнительный риск.

Эти задачи выигрывают от низкой задержки. Книга ордеров обрабатывает отмены, частичные исполнения и изменение цен чаще, чем пользователи перемещают активы через расчетную систему. Если заставить каждое промежуточное сообщение ждать финальности в сети, рынок может замедлиться без улучшения итогового перевода.

Расчетная сеть делает состояние авторитетным

Расчетная сеть отвечает на другой вопрос: какие изменения активов и залога стали необратимыми в соответствии с правилами сети? Она упорядочивает транзакции, исполняет инструкции смарт-контрактов и предоставляет приложениям каноническое состояние, на основе которого можно продолжать работу.

Обзор системы Arc иллюстрирует это разделение внутри сети. Ее исполнительный уровень Reth обрабатывает транзакции и поддерживает состояние, а консенсусный уровень Malachite упорядочивает и финализирует блоки. Торговое приложение добавляет еще один уровень над этой инфраструктурой.

Почему два уровня работают по разным часам

Рынки реагируют за миллисекунды, тогда как блокчейны финализируют пакеты транзакций в соответствии с правилами консенсуса. Даже быстрая расчетная сеть имеет цикл создания блоков и финальности. Поэтому торговая платформа работает как минимум с двумя часами: быстрым потоком ордеров и исполнений и последовательностью финализированных изменений состояния в сети.

Подтверждение исполнения — не финальность расчетов

Подтверждение исполнения означает, что платформа сопоставила ордер. Финальность расчетов означает, что соответствующий перевод больше нельзя отменить в рамках обычной работы расчетной системы. Смешение этих понятий создает скрытый кредитный риск.

Предположим, платформа позволяет трейдеру немедленно использовать средства от исполненной сделки. Если расчетная транзакция впоследствии не пройдет, платформа фактически предоставила кредит под еще не завершенный расчет. Это может быть осознанным элементом архитектуры, но тогда необходимы лимиты, резервы и процедура восстановления. Простая маркировка площадки как «работающей ончейн» не устраняет этот разрыв.

Финальность определяет, когда состояние можно безопасно использовать повторно

Текущая документация Arc о финальности описывает архитектуру сети, обеспечивающую необратимые расчеты менее чем за одну секунду. Детерминированная финальность дает приложению четкий момент, когда транзакцию можно считать завершенной, вместо ожидания вероятностного числа подтверждений.

Это свойство может сократить период, в течение которого платформе необходимо управлять предварительным состоянием. Однако оно не устраняет ошибки приложения, уязвимости контрактов, некорректные данные оракулов или рыночный убыток трейдера. Финальность делает принятое состояние устойчивым, но не гарантирует, что каждая инструкция, попавшая в это состояние, была экономически разумной.

Непрерывность рынка требует режима деградации

Платформе также нужны правила на случай, когда сеть перегружена, недоступна или выдает неожиданные ответы. Продолжение сопоставления ордеров при задержке расчетов может привести к накоплению обязательств. Немедленная остановка способна защитить балансы, но нарушить формирование цены и не позволить трейдерам снизить риск.

Площадка может снизить лимиты позиций, отключить вывод средств, перейти в режим только отмены ордеров, увеличить буферы риска или приостановить отдельные рынки. Важно, чтобы переход был определен до инцидента и последовательно доведен до пользователей.

Что должна координировать надежная интеграция

Интерфейс между исполнением и расчетами — это не одна отправка транзакции. Это конечный автомат, который должен поддерживать согласованность нескольких фактов: что внес трейдер, что зарезервировала платформа, какие ордера были исполнены, какие комиссии начислены, какие позиции остаются открытыми и что именно сеть финализировала.

Каждая расчетная инструкция должна иметь защиту от повторного воспроизведения и уникальный идентификатор, чтобы повторная попытка не провела расчеты по одному и тому же исполнению дважды. Порядок транзакций также должен сохранять зависимости: вывод средств не должен быть финализирован до депозита или прибыли, которые его финансируют. Неудачные транзакции требуют явно определенного разрешения, а не незаметных повторных попыток.

Механизм управления риском может резервировать залог под открытые ордера, даже если баланс в сети еще не изменился. Интерфейс должен различать общий и доступный залог, ожидающие переводы и средства, выделенные под маржу. Один недифференцированный баланс создает условия для двойного расходования и ошибочных ликвидаций.

Как финальность меняет риски платформы

Более короткий период до финальности может уменьшить окно, в котором одна сторона уже выполнила свою часть, а другое обязательство остается незавершенным. Он также может позволить быстрее повторно использовать залог и сократить число предварительных записей, которые платформе необходимо сверять.

Однако более высокая скорость автоматически не означает большую безопасность. Ошибочная ликвидация, скомпрометированный ключ или некорректный вызов контракта также быстрее становятся окончательными. Контроли должны применяться раньше в рабочем процессе: моделирование транзакций, авторизация, лимиты частоты, проверка оракулов, правила вывода средств и аварийные выключатели становятся еще важнее, когда после отправки остается мало времени для вмешательства.

Архитектура расчетов также влияет на ликвидность. В своем обсуждении клиринга и расчетов на блокчейне DTCC предупреждала, что расчеты в режиме реального времени на валовой основе могут устранить преимущества неттинга и потребовать индивидуального финансирования транзакций. Платформа должна определить, какие обязательства следует рассчитывать немедленно, какие можно объединять для неттинга и где уместны кредитные или ликвидностные буферы.

Почему важны общие расчетные активы

Координация становится проще, когда комиссии, залог и расчеты используют активы с совместимым учетом. Если трейдер вносит один актив, платит газ другим, а прибыль и убыток рассчитываются в третьем, платформа должна управлять конвертацией, волатильностью цен и минимальными балансами по всем трем активам.

Документация Arc называет USDC газовым токеном сети и представляет Arc как нативный для стейблкоинов блокчейн первого уровня; это заявления об архитектуре, а не доказательство фактической эффективности приложения. В документации о газе и комиссиях объясняется модель комиссий сети, номинированных в USDC. Для рынка с маржой в USDC это может сократить одно из операционных несоответствий между приложением и сетью.

Это не означает, что общая стоимость торговли становится фиксированной. Спреды, ценовое воздействие, финансирование, штрафы за ликвидацию, комиссии приложения и затраты на доступ к USDC остаются отдельными факторами. Единая номинация снижает учетные издержки, но не устраняет рыночный риск и не гарантирует низкую стоимость исполнения.

Архитектурные решения и компромиссы

Размещение большего объема логики ончейн может упростить проверку правил и переходов состояния, но подвергает приложение ограничениям пропускной способности блоков, порядку транзакций и сетевым комиссиям. Специализированный уровень исполнения может реагировать быстрее и поддерживать сложные типы ордеров, однако пользователи должны понимать, кто им управляет, как авторизуются сообщения и каким образом его записи можно сверять с сетью.

Отчет BIS/CPMI о токенизации подчеркивает, что токенизированные системы по-прежнему требуют надежного управления, контроля рисков и совместимости. Модульность полезна только тогда, когда модули используют четкие стандарты и имеют однозначно распределенные обязанности. В противном случае сложность переносится в интерфейсы, где сбои бывает труднее заметить.

Что может пойти не так между исполнением и расчетами

Наиболее опасные сбои часто происходят на границе между уровнями. Задержавшийся индексатор может показать старый баланс залога. Дублированное сообщение может отправить одно и то же действие дважды. Реорганизация сети или ошибочное предположение о финальности может привести к тому, что платформа признает депозит слишком рано. Оракул может обновиться на одном уровне раньше другого. Выпуск программного обеспечения может изменить правила округления или расчета комиссий только на одной стороне.

Надежная система публикует практические последствия сбоев: приостанавливается ли торговля, доступен ли режим только отмены ордеров, как обрабатываются ожидающие выводы средств, кто может активировать аварийные средства управления и как финальное состояние проверяется независимо.

Резюме для инвесторов

Торговые платформы и расчетные сети — взаимодополняющая инфраструктура. Платформа превращает ордера в рыночные результаты. Сеть превращает авторизованные изменения состояния в долговечную общую запись. Ни один из этих уровней нельзя оценивать изолированно.

Инвесторам и трейдерам следует рассматривать качество исполнения, ликвидность, контроль залога, предположения о финальности, архитектуру оракулов, правила вывода средств, управление и восстановление после инцидентов как единую систему. Лучшая архитектура не обязательно та, в которой каждое действие выполняется ончейн. Это архитектура, в которой ответственность каждого уровня ясна, а сами уровни сохраняют согласованность как в нормальных, так и в стрессовых условиях.

Итоговый вывод

Торговая платформа может сделать рынки быстрыми, но только надежный процесс расчетов способен сделать завершенные обязательства окончательными. Расчетная сеть может сделать состояние долговечным, но не может определить, ликвидна ли книга ордеров, справедлива ли цена или надежна ли политика ликвидации.

Два уровня работают согласованно, когда исполнение создает авторизованные обязательства в правильном порядке, а расчеты возвращают своевременное и однозначное состояние, которое платформа может безопасно использовать повторно. Эта координация, включая действия при сбоях, и есть настоящая инфраструктура торговли ончейн.

Торгуйте бессрочными рынками на edgeX с расчетами через Arc

Задействуйте свои USDC на рыночном уровне, созданном для активных трейдеров. edgeX переносит торговый опыт с книгой ордеров на бессрочные рынки криптовалют, акций США, сырьевых товаров и валютных пар; в его техническом документе описывается стек исполнения, лежащий в основе платформы. Arc призван обеспечить расположенную ниже среду расчетов, нативную для стейблкоинов. Объявленная интеграция призвана сохранить маржу и расчеты в нативном USDC, чтобы торговый процесс и расчетный актив работали вместе, а не были разделены между несвязанными системами.

Готовы торговать не только на одном рынке? Изучите edgeX, чтобы найти платформу и доступные бессрочные рынки. Чтобы воспользоваться направлением, связанным с Arc, посмотрите edgeX на Arc и следите за объявленным запуском. edgeX объявила о планах запустить новые бессрочные контракты на валютные пары наряду с уже существующими рынками; запуск основной сети Arc запланирован на 16 сентября 2026 года. Доступность, рынки и детали запуска могут измениться.

Бессрочные контракты предназначены для трейдеров, которым нужен гибкий постоянный доступ к рынку, но это не пассивные продукты. На результаты могут влиять кредитное плечо, ставки финансирования, архитектура оракулов, ликвидность и ликвидации. Перед торговлей ознакомьтесь с условиями продукта и средствами контроля рисков.

Часто задаваемые вопросы

В чем разница между исполнением сделки и расчетами?

Исполнение происходит, когда инструкции на покупку и продажу сопоставляются в соответствии с рыночными правилами платформы. Расчеты завершают соответствующий перевод, обновление залога или договорное обязательство. Эти события могут происходить почти одновременно, но это не одно и то же событие.

Должна ли книга ордеров работать непосредственно в блокчейне?

Нет. Платформа может обрабатывать часть сообщений об ордерах на специализированном уровне исполнения, а авторизованные результаты рассчитывать в блокчейне. Архитектура должна раскрывать, кто управляет каждым компонентом, как авторизуются ордера и каким образом записи платформы сверяются с финальным состоянием сети.

Почему финальность блокчейна важна для торговой платформы?

Финальность показывает платформе, когда депозит, вывод средств, перевод залога или обновление контракта становятся необратимыми в соответствии с правилами сети. Более быстрая детерминированная финальность может сократить объем предварительного состояния, однако платформе по-прежнему нужны средства контроля некорректных инструкций, сбоев и отказов на уровне приложения.

Снижает ли более быстрый расчет все виды рисков?

Нет. Он может уменьшить расчетный риск и объем сверки, но одновременно повысить потребность в предварительном финансировании и привести к тому, что ошибочные транзакции станут окончательными раньше. Риски ликвидности, смарт-контрактов, оракулов, хранения активов, управления и операционной деятельности сохраняются.

Зачем использовать USDC и для маржи, и для расчетов?

Использование одной расчетной номинации может упростить учет залога и сократить количество конвертаций между волатильным газовым активом и номинированными в долларах рыночными обязательствами. Это не гарантирует стабильную рыночную цену, достаточную ликвидность или низкую общую стоимость торговли.