Как создать децентрализованную криптовалютную биржу: пошаговая структура
Обновлено: 15 сентября 2026 г.
Создание децентрализованной криптовалютной биржи не ограничивается развёртыванием смарт-контрактов. Для полноценной работы DEX также необходимы понятная торговая модель, надёжная ликвидность, рыночные данные, механизмы управления рисками, инфраструктура кошельков, мониторинг и прозрачный процесс обеспечения безопасности. Архитектура определяет, какие операции выполняются в блокчейне, какие компоненты остаются вне сети и каким элементам системы должны доверять пользователи.
В этом руководстве рассматриваются основные решения, связанные с созданием автоматизированного маркет-мейкера, биржи со стаканом заявок или гибридной платформы. Более широкое сравнение биржевых моделей представлено в нашем руководстве по централизованным и децентрализованным биржам.
Сравнение архитектур DEX
| Модель | Исполнение | Ликвидность | Основные требования |
|---|---|---|---|
| Автоматизированный маркет-мейкер | Пользователи торгуют с пулами токенов по заданной формуле ценообразования. | Поставщики ликвидности вносят активы в пулы. | Контракты пулов, маршрутизатор, логика ценообразования, учёт долей поставщиков ликвидности, фронтенд и индексатор. |
| Ончейн-стакан заявок | Заявки и их сопоставление записываются или исполняются в блокчейне. | Маркет-мейкеры поддерживают заявки на покупку и продажу на разных ценовых уровнях. | Контракты заявок, логика сопоставления, ретрансляция транзакций и рыночные данные в реальном времени. |
| Гибридный стакан заявок | Заявки обрабатываются или сопоставляются вне сети, а расчёты окончательно фиксируются в блокчейне. | Обычно требуются профессиональные маркет-мейкеры или другой надёжный источник глубины рынка. | Механизм сопоставления заявок, подписанные заявки, расчётные контракты, API, средства управления рисками и мониторинг. |
Ни одна модель по умолчанию не является полностью не требующей доверия. AMM зависят от логики смарт-контрактов и экономики пулов. Ончейн-стаканы заявок зависят от пропускной способности сети и порядка включения транзакций, поэтому на них особенно заметно, что такое MEV. Гибридные биржи также зависят от внешних по отношению к блокчейну сервисов, включая механизм сопоставления заявок, 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 % для тейкера, а кешбэк до 35 % может их только снизить. Перед началом торговли или интеграции читателям следует проверять актуальную структуру торговых комиссий.
EVEDEX — платформа для трейдинга — также поддерживает публичную организацию на GitHub. Открытые репозитории повышают прозрачность, но не доказывают, что каждый опубликованный файл используется в рабочей среде. Для более надёжной проверки необходимо связать адреса рабочих контрактов с верифицированным исходным кодом, коммитами репозитория и объёмом аудита.
В публичном профиле EVEDEX на CertiK указана проверка файла OwnableValidator.sol, проведённая с использованием ручного и статического анализа. В профиле также указана одна информационная проблема со статусом Acknowledged. Эта проверка относится только к названному файлу и не должна описываться как аудит всей платформы EVEDEX, механизма сопоставления заявок, системы ликвидации или всех смарт-контрактов, используемых в рабочей среде.
Заключение
Чтобы создать децентрализованную криптовалютную биржу, начните с узкого определения продукта и прозрачной модели доверия. Выберите архитектуру исполнения, соответствующую целевому рынку, обеспечьте надёжную ликвидность, опубликуйте правила управления рисками и сделайте каждое заявление о безопасности прослеживаемым до конкретного отчёта, версии кода и развёрнутого смарт-контракта.
Сильная DEX — не та, у которой самый длинный список функций. Это биржа, чьи механизмы исполнения, хранения активов, обеспечения ликвидности, управления разрешениями и подтверждения безопасности можно независимо понять и проверить.
