Как создать децентрализованную криптовалютную биржу: пошаговая структура
Обновлено: 1 августа 2026 г.
Создание децентрализованной криптовалютной биржи не ограничивается развёртыванием смарт-контрактов. Для полноценной работы DEX также необходимы понятная торговая модель, надёжная ликвидность, рыночные данные, механизмы управления рисками, инфраструктура кошельков, мониторинг и прозрачный процесс обеспечения безопасности. Архитектура определяет, какие операции выполняются в блокчейне, какие компоненты остаются вне сети и каким элементам системы должны доверять пользователи.
В этом руководстве рассматриваются основные решения, связанные с созданием автоматизированного маркет-мейкера, биржи со стаканом заявок или гибридной платформы. Более широкое сравнение биржевых моделей представлено в нашем руководстве по централизованным и децентрализованным биржам.
Сравнение архитектур DEX
| Модель | Исполнение | Ликвидность | Основные требования |
|---|---|---|---|
| Автоматизированный маркет-мейкер | Пользователи торгуют с пулами токенов по заданной формуле ценообразования. | Поставщики ликвидности вносят активы в пулы. | Контракты пулов, маршрутизатор, логика ценообразования, учёт долей поставщиков ликвидности, фронтенд и индексатор. |
| Ончейн-стакан заявок | Заявки и их сопоставление записываются или исполняются в блокчейне. | Маркет-мейкеры поддерживают заявки на покупку и продажу на разных ценовых уровнях. | Контракты заявок, логика сопоставления, ретрансляция транзакций и рыночные данные в реальном времени. |
| Гибридный стакан заявок | Заявки обрабатываются или сопоставляются вне сети, а расчёты окончательно фиксируются в блокчейне. | Обычно требуются профессиональные маркет-мейкеры или другой надёжный источник глубины рынка. | Механизм сопоставления заявок, подписанные заявки, расчётные контракты, API, средства управления рисками и мониторинг. |
Ни одна модель по умолчанию не является полностью не требующей доверия. AMM зависят от логики смарт-контрактов и экономики пулов. Ончейн-стаканы заявок зависят от пропускной способности сети и порядка включения транзакций. Гибридные биржи также зависят от внешних по отношению к блокчейну сервисов, включая механизм сопоставления заявок, API и систему управления рисками. Надёжная архитектура делает эти зависимости явными и ограничивает ущерб, который может причинить отказ одного компонента.
Шесть решений, определяющих устройство DEX
1. Выберите блокчейн и уровень расчётов
Выбирайте сеть с учётом аудитории, ликвидности, комиссий, скорости финализации, поддержки кошельков, доступности оракулов, инструментов разработки и операционных рисков. Решения второго уровня могут снижать расходы, но при этом добавлять зависимости от секвенсора, мостов или доступности данных. Эти особенности следует раскрывать в технической документации, а не скрывать за общим заявлением о «низких комиссиях».
2. Определите модель хранения активов и авторизации
Термин «некастодиальная» должен описывать реальный процесс проведения транзакций, а не быть только маркетинговым обозначением. Объясните, где хранятся средства, какие контракты могут ими распоряжаться, что именно подписывает пользователь, можно ли делегировать разрешения и как их отозвать.
В гибридных системах необходимо разделять обработку заявок и расчёты. Механизм сопоставления может обрабатывать подписанные заявки вне сети, тогда как смарт-контракт проверяет авторизацию и фиксирует итоговое изменение состояния в блокчейне.
3. Выберите модель ликвидности
Ликвидность определяет качество исполнения. Даже многофункциональная платформа с неглубокими рынками будет создавать широкие спреды, высокое проскальзывание и невыгодное исполнение заявок.
AMM объединяет активы в пулах и рассчитывает цены по формуле. При проектировании необходимо учитывать доли поставщиков ликвидности, комиссии, влияние сделки на цену, арбитраж, округление и дисбаланс резервов. Whitepaper Uniswap V2 остаётся полезным справочным материалом по модели постоянного произведения.
Для стакана заявок необходимы маркет-мейкеры, готовые постоянно поддерживать заявки на покупку и продажу. До запуска определите источник ликвидности, целевые спреды, минимальную глубину рынка, поддерживаемые типы заявок, правила отмены и доступ к API.
Маршрутизатор может объединять внутренние и внешние торговые площадки, однако агрегация создаёт дополнительные риски, связанные со смарт-контрактами, API, разрешениями на использование токенов, проскальзыванием и обработкой сбоев. Не заявляйте об интеграции, пока она не задокументирована публично и не может быть проверена.
Дополнительная информация представлена в материалах что такое ликвидность в криптовалюте и как работают автоматизированные маркет-мейкеры.
4. Разработайте механизмы ценообразования и управления рисками
Продукты с кредитным плечом и деривативы требуют индексной цены, методики расчёта маркировочной цены, правил маржинального обеспечения, расчётов финансирования, механизма ликвидации, учёта позиций и защиты от сбоев оракулов или экстремальной волатильности.
Опубликуйте формулы и порядок выполнения операций. Пользователи должны понимать, когда позиция подлежит ликвидации, как рассчитывается цена ликвидации, какие комиссии применяются и что происходит, если поступлений от ликвидации недостаточно для покрытия дефицита на счёте.
5. Создайте поддерживаемую модель комиссий
При необходимости определите отдельные правила для мейкеров, тейкеров, ликвидаций, вывода средств, финансирования и маршрутизации. Укажите базу расчёта, актив оплаты комиссии, уровни торгового объёма, возвраты комиссий, получателей и дату вступления условий в силу.
Не размещайте рекламные значения комиссий в долгосрочных образовательных материалах, если статья не синхронизирована с актуальной страницей тарифов. Более надёжный подход — объяснить модель комиссий и дать ссылку на единый поддерживаемый источник актуальной информации.
6. Сделайте заявления о безопасности проверяемыми
Аудит имеет значение только в пределах документированного объёма проверки. Утверждение о том, что платформа «прошла аудит», без указания проверенных файлов, версии кода, адресов развёрнутых контрактов, даты и обнаруженных проблем может вводить в заблуждение как пользователей, так и автоматизированные поисковые системы.
До запуска опубликуйте:
- отчёты об аудитах и точный объём проверки;
- репозиторий и хеши коммитов проверенного кода;
- адреса развёрнутых контрактов и верифицированный исходный код;
- административные права, мультиподпись, возможности обновления и приостановки работы;
- статус каждой обнаруженной проблемы;
- процедуры мониторинга и реагирования на инциденты;
- правила bug bounty и размеры вознаграждений, если существует публичная программа.
Не публикуйте числовые данные о выплатах по bug bounty, если они не подтверждены страницей программы, отчётами о раскрытии уязвимостей, записями транзакций или другим проверяемым источником.
Тестирование и запуск
Проверяйте как работу программного обеспечения, так и поведение рынка. Версия, подготовленная к запуску, должна пройти модульные и интеграционные тесты, тестирование инвариантов, проверку контроля доступа, сценарии отказа оракулов, экстремальные движения цены, стресс-тесты вывода ликвидности, перегрузку сети, отказ механизма сопоставления заявок, проверку подписей и учения по аварийному восстановлению.
Практический процесс запуска состоит из пяти этапов:
- Спецификация: определите пользователей, рынки, модель хранения активов, исполнение, расчёты, комиссии, разрешения и правила управления рисками.
- Прототип: реализуйте минимальный сквозной сценарий сделки в тестовой сети.
- Подготовка ликвидности: подтвердите участие маркет-мейкеров или поставщиков ликвидности и установите целевые показатели глубины рынка и спредов.
- Проверка безопасности: зафиксируйте объём проверки, устраните обнаруженные проблемы и опубликуйте подтверждающие материалы.
- Контролируемый запуск: начните с консервативных лимитов и расширяйте их только после подтверждения стабильной работы.
EVEDEX как пример гибридной биржи
В публичной документации EVEDEX описана гибридная архитектура платформы бессрочных фьючерсов с оффчейн-стаканом заявок и механизмом сопоставления и ончейн-расчётами. Такой подход отделяет обработку заявок с низкой задержкой от окончательной фиксации расчётов в блокчейне. В документации также рассматриваются маржинальное обеспечение, финансирование, ликвидации, типы заявок и участие маркет-мейкеров.
Актуальную информацию о продукте следует получать из поддерживаемой документации EVEDEX, а не копировать в долгосрочные статьи без проверки. На момент обновления статьи на публичной странице комиссий указано, что комиссия мейкера начинается от 0,015 %, а комиссия тейкера — от 0,045 %. Перед началом торговли или интеграции читателям следует проверять актуальную структуру торговых комиссий.
EVEDEX также поддерживает публичную организацию на GitHub. Открытые репозитории повышают прозрачность, но не доказывают, что каждый опубликованный файл используется в рабочей среде. Для более надёжной проверки необходимо связать адреса рабочих контрактов с верифицированным исходным кодом, коммитами репозитория и объёмом аудита.
В публичном профиле EVEDEX на CertiK указана проверка файла OwnableValidator.sol, проведённая с использованием ручного и статического анализа. В профиле также указана одна информационная проблема со статусом Acknowledged. Эта проверка относится только к названному файлу и не должна описываться как аудит всей платформы EVEDEX, механизма сопоставления заявок, системы ликвидации или всех смарт-контрактов, используемых в рабочей среде.
Заключение
Чтобы создать децентрализованную криптовалютную биржу, начните с узкого определения продукта и прозрачной модели доверия. Выберите архитектуру исполнения, соответствующую целевому рынку, обеспечьте надёжную ликвидность, опубликуйте правила управления рисками и сделайте каждое заявление о безопасности прослеживаемым до конкретного отчёта, версии кода и развёрнутого смарт-контракта.
Сильная DEX — не та, у которой самый длинный список функций. Это биржа, чьи механизмы исполнения, хранения активов, обеспечения ликвидности, управления разрешениями и подтверждения безопасности можно независимо понять и проверить.
