В базовую поставку обычно входит:
Мы разрабатываем криптобиржи с 2015 года и за это время прогнали через продакшн десятки конфигураций — от простого инстант-обменника до платформы уровня BingX со спотом, маржой и деривативами. В этой статье разбираем, что реально входит в скрипт, сколько это стоит по нашим текущим расчётам и какие архитектурные решения выдерживают нагрузку, а какие ломаются на первой тысяче активных трейдеров.
Разница между «купить готовое решение» и «написать с нуля» — это не только время. По нашим текущим расчётам на модульную платформу (спот + маржа + фьючерсы + инстант-конвертация + фиат-интеграция):
| Пакет | Готовое решение | Разработка с нуля | Срок |
| Basic | $36 000 | $48 000 | 1.5–2 месяца |
| Standard | $49 000 | $64 000 | 2 месяца |
| Advanced | $64 000 | $81 000 | 2–3 месяца |
Готовое решение экономит 20–25% бюджета и 3–4 недели за счёт того, что торговый движок, кошельки и админ-панель уже прошли продакшн-тестирование на реальных активах — мы не тестируем депозит и вывод на тестнет-монетах, только на настоящих BTC, ETH и USDT, потому что поведение сети под реальной нагрузкой mempool отличается от тестового.
Если вам нужна не полноценная биржа, а просто механизм конвертации без стакана заявок, отдельный продукт instant exchange (backend + admin + веб-интерфейс) обходится от $29 000 — почти вдвое дешевле полной биржи и логичная точка входа при ограниченном бюджете. P2P-модуль с эскроу-логикой — отдельная позиция, $32 000–$53 000 в зависимости от пакета.
Если же в планах криптобиржа под ключ с деривативами, DEX-частью и governance-механикой уровня BingX, разработка с нуля обойдётся в $300 000–$500 000+ — на этом уровне сложности скрипт уже не покрывает весь стек, и мы прямо говорим об этом клиентам вместо того, чтобы продавать несуществующее решение. Детальную разбивку по бюджету и срокам для разных конфигураций мы разбирали в статье про то, сколько стоит создать криптобиржу.
Небольшой проект с архитектурой «всё в одном» дешевле в развёртывании, но упирается в потолок на объёмах в несколько тысяч сделок в день — order book и wallet-сервис конкурируют за один и тот же процесс. Средний проект уже требует микросервисной архитектуры с изолированными компонентами: торговый движок, кошельки, KYC-сервис и уведомления живут отдельно и масштабируются независимо.
Мы переводили одну из наших биржевых инфраструктур с монолитной VM на полноценный Kubernetes — вот что из этого вышло.
Ключевая задача: Монолит на VM не давал автоскейлить нагрузку избирательно — деплой любой фичи требовал остановки всего стека, а рост трафика упирался в потолок одного сервера.
Решение: Мы переписали 17 микросервисов в Docker-контейнеры с Helm-чартами, подключили HashiCorp Vault для секретов через GitLab CI и настроили Horizontal Pod Autoscaler отдельно на каждый сервис — но матчинг-энджин и wallet manager сознательно вывели из автоскейла из-за их state-зависимостей. Для межсервисной коммуникации подняли Redpanda (Kafka-совместимую шину сообщений).
Результат: Деплой новых фич больше не трогает торговое ядро, стейтлес-слой (API gateway, уведомления) масштабируется автоматически под пиковую нагрузку, а матчинг-энджин остаётся предсказуемым и без даунтайма.
Нужна scaling policy, которая явно разделяет stateless-сервисы (API gateway, notification service) и stateful (wallet manager, matching engine) ещё до того, как вы напишете первый Helm-чарт. Для действительно крупных бирж к этому добавляется распределённая изолированная модель с балансировкой нагрузки и Cloudflare на входе — простой в трейдинговой системе означает прямые финансовые потери для пользователей, а не просто недовольство.
Пустой order book в первые недели — главная причина, почему новые биржи теряют доверие трейдеров ещё до старта. Скрипт сам по себе не решает эту проблему — нужна либо связка с локальными маркет-мейкерами, либо подключение к провайдеру ликвидности криптовалют уровня Kraken или Binance.
Ключевая задача: Новая биржа с пустым order book не может конкурировать по глубине рынка и теряет трейдеров в первую неделю после запуска.
Решение: Мы реализовали order book mirroring с внешней биржей: при ордере на продажу платформа параллельно берёт займ на эквивалентную сумму на стороне провайдера (с маржой ~3x), исполняет сделку там, зачисляет пользователю баланс в USDT и асинхронно закрывает займ. Real-time мониторинг margin utilization и borrow limits с алертами в Telegram и Slack на критические пороги идёт в комплекте.
Результат: Order book выглядит заполненным с первого дня работы платформы, при этом за время наблюдения не было ни одного проваленного сделки из-за исчерпания лимита маржи.
Комбинированный подход — локальные маркет-мейкеры плюс синхронизация с внешним рынком — даёт максимальную устойчивость при высокой волатильности и остаётся стандартом для средних и крупных бирж.
Требования к фиат-биржам продолжают ужесточаться, и модуль KYC/AML нужен, как только в платформе появляется фиатная валюта — доллар, евро или любая другая регулируемая. Для чисто крипто-крипто пар это не обязательно, но для лицензии для криптобиржи в большинстве юрисдикций — критично.
Ключевая задача: Стандартная практика — проверять KYC один раз при регистрации — оставляет дыру: скомпрометированный кошелёк или подозрительный входящий депозит проходит незамеченным, пока клиент не пожалуется постфактум.
Решение: Мы внедрили KYT на уровне каждой входящей транзакции — каждый депозит получает AML risk score до момента зачисления баланса. При превышении порога система автоматически замораживает депозит и создаёт задачу для compliance-офицера. Дополнительно реализовали forced wallet regeneration: при флаге риска платформа генерирует новый адрес депозита по всем поддерживаемым сетям, а старый — карантинит без раскрытия причины пользователю.
Результат: Рискованные транзакции изолируются до зачисления средств, а не после, и соответствие требованиям AML-регуляторов обеспечивается на транзакционном уровне без лишнего трения для добросовестных пользователей.
Если фиатный банкинг в целевом регионе ограничен, P2P-модуль с эскроу-логикой (заморозка средств на 15–30 минут на время сделки) даёт резервный канал ликвидности, который работает даже когда банки не работают. Мы подробно разбирали механику запуска в статье о том, как открыть p2p обменник.
Инстант-обменник (конвертер) технически проще полноценной биржи, но сложность прячется в слое ликвидности: мы обычно подключаем два внешних провайдера параллельно и даём админу выбор — жёстко привязать пару к конкретному провайдеру или маршрутизировать по лучшему курсу. Курс и баланс обновляются через WebSocket-соединения к обоим провайдерам одновременно, чтобы пользователь не видел устаревшую цену.
Гибридная wallet-архитектура — часть активов на собственных нодах, часть через внешние RPC-провайдеры — обычный компромисс между безопасностью и стоимостью инфраструктуры. Мультичейн-поддержка (Ethereum, Tron, BNB Chain, Solana) закрывает основные объёмы торгов, а полная синхронизация Bitcoin-ноды занимает 5–10 дней на выделенном железе — это стоит закладывать в план проекта с первого дня, параллельно с разработкой, а не после неё.
На стороне безопасности: 2FA (email, телефон, Google Authenticator), ручное подтверждение крупных выводов в бэк-офисе и приватные ключи вне прямого доступа команды разработки — если разработчик может добраться до приватного ключа, уязвимость уже существует независимо от качества кода.
| Вариант | Плюсы | Риски |
| Бесплатный open-source | Нулевая стоимость входа, подходит для изучения архитектуры | Уязвимости без аудита кода, не рассчитан на реальную нагрузку |
| Дешёвый скрипт (WordPress-база) | Быстрый запуск для теста ниши | Минимальная кастомизация, потолок по трафику |
| White-label от подрядчика | Продакшн-протестированный движок, готовая поддержка | Ограниченная глубина кастомизации под уникальные требования |
| Кастомная разработка | Полный контроль над архитектурой и нагрузкой | Выше бюджет и срок — см. таблицу цен выше |
Отдельно стоит присмотреться к скрипту бинарных опционов, если целевая аудитория пересекается с трейдингом на short-term контрактах — у нас есть готовая база для white-label деплоя такой платформы: скрипт бинарных опционов разворачивается на отдельном сервере со своими API-ключами платёжных провайдеров за 2 недели от договора до продакшна, потому что база продукта уже прошла годы эксплуатации у других клиентов.
Готовый скрипт закрывает 80–90% случаев запуска — от инстант-обменника за $29 000 до полноценной биржи со спотом, маржой и фьючерсами за $36 000–$64 000. Кастомная разработка с нуля оправдана только когда требования выходят за пределы модульной архитектуры — DEX-часть, governance-механики, уникальный risk-engine. Дальше вопрос не «купить или разработать», а какая конкретно конфигурация модулей закрывает вашу нагрузку и юрисдикцию.
Готовое модульное решение (спот + маржа + фьючерсы + инстант-обмен) стоит от $36 000 до $64 000 в зависимости от пакета, срок разработки — 1.5–3 месяца. Отдельный инстант-обменник дешевле — от $29 000.
Тот же торговый движок и архитектура, но без месяцев на написание и продакшн-тестирование заново. По нашим расчётам разница в бюджете — 20–25% в пользу готового решения на сопоставимом наборе модулей.
Микросервисная архитектура с изолированными компонентами (order book, кошельки, KYC-сервис отдельно), где автоскейл настроен только для stateless-сервисов, а матчинг-энджин и wallet manager масштабируются вручную из-за их state-зависимостей.
Да, через order book mirroring с внешним провайдером или подключение к Tier-1 бирже — это закрывает проблему пустого стакана заявок в первые недели работы платформы.