Институциональный клиент хочет продать 500 BTC без проскальзывания. На обычной бирже такой ордер сдвинет стакан на десятки тысяч долларов. Решение — RFQ-система, где запрос отправляется нескольким маркет-мейкерам (MM), и они конкурируют за исполнение. Мы проектируем и разрабатываем такие системы для OTC-платформ: от проектирования протокола до деплоя в production с гарантированным проскальзыванием <0.1%. Наша команда — 7+ лет в Web3, 40+ проектов DeFi, 5 лет опыта разработки RFQ. Оценим ваш проект за 1-2 дня — свяжитесь для консультации.
Согласно Практической энциклопедии финансового рынка, RFQ-протокол используется для институциональной торговли крупными объёмами. В нашей реализации средняя экономия на проскальзывании для сделок от 50 BTC составляет более $10 000 по сравнению с order book.
Как работает RFQ Flow на практике?
1. Клиент → система: RFQ запрос {instrument: "BTC/USDC", side: "buy", quantity: 100, expiry: 30s, client_id: "inst_001"} 2. Система → маркет-мейкеры: broadcast запроса (одному или нескольким MM одновременно) 3. Маркет-мейкеры → система: котировки {bid: 67450.00, ask: 67480.00, valid_until: T+30s} 4. Система → клиент: лучшие котировки (или агрегация) 5. Клиент → система: принятие котировки {quote_id: "q_abc123", accept: true} 6. Система → MM: уведомление об исполнении 7. Settlement: обмен активами Управление котировками и агрегация
При нескольких MM система может агрегировать котировки несколькими способами:
- Best-of: показать клиенту лучший bid/ask от разных MM.
- NBBO (National Best Bid and Offer) в крипто-OTC контексте.
- Internalization: если деск может исполнить из собственного инвентаря по лучшей цене.
Каждая котировка имеет expiry (30–60 секунд). После истечения — auto-cancel. MM не хочет быть exposed на цену, которую дал минуту назад при движении рынка.
Partial fills: если MM даёт котировку на 100 BTC, а клиент хочет 50 BTC — split quote. Или клиент запрашивает 200 BTC, а один MM может дать только 100 — multi-venue fill.
Как мы управляем пулом маркет-мейкеров?
Система управляет пулом MM с помощью гибких правил:
- Routing rules: каким MM отправлять какие RFQ. Критерии: специализация по инструменту, размер сделки, исторический hit rate, spread competitiveness.
- Response time tracking: медианное время ответа каждого MM (обычно 50-200 мс). Slow responders de-prioritize.
- Quote quality metrics: fill rate (>90%), miss rate, stale quotes (<2%).
- Connectivity: WebSocket (низкая latency) или REST. Для институциональных интеграций — FIX 4.4.
Real-time state management
RFQ-система высоконагруженная и state-ful. Redis для hot state: активные RFQ и котировки хранятся с TTL (30-120 секунд), автоматически экспирируются. Pub/sub для real-time нотификаций участников. Event sourcing: все события пишутся в immutable log, что даёт audit trail из коробки.
Детали settlement
Settlement может быть on-chain (через смарт-контракты escrow) или off-chain (по договорённости). Для on-chain используем ERC-20 transfers с multi-call, что даёт атомарность и прозрачность.Как защитить систему от злоупотреблений?
Недобросовестные участники могут злоупотреблять системой. Мы внедряем несколько защитных механизмов:
- Last look: MM оставляет право отклонить принятую котировку. Клиенты не любят last look, но MM его требуют. Настраиваем баланс: таймаут 1 секунда, штраф за отклонение >10%.
- Rate limiting для RFQ запросов: клиент не должен делать сотни RFQ в секунду для "price discovery" без намерения торговать (лимит 10 запросов в секунду).
- Minimum trade size: только реальные институциональные сделки (от 1 BTC или эквивалент $50k).
- IP restrictions: только whitelisted институциональные клиенты.
RFQ-система сложнее простого matching engine, но обеспечивает institutional-grade trading experience для крупных объёмов. По сравнению с order book, RFQ даёт проскальзывание в 5-10 раз меньше при объёмах >50 BTC и защищает от MEV.
Почему RFQ лучше order book для крупных объёмов?
| Параметр | RFQ | Order Book |
|---|---|---|
| Прозрачность цены | Цена раскрывается только после запроса | Все ордера видны в стакане |
| Проскальзывание | Минимальное (MM конкурируют) | Высокое для крупных ордеров |
| Защита от MEV | Нет фронт-раннинга | Возможен sandwich-атаки |
| Скорость исполнения | 1-5 секунд | Миллисекунды |
| Идеальный объём | >100 BTC | <10 BTC |
Что входит в разработку RFQ-системы?
| Этап | Результат |
|---|---|
| Аналитика | Спецификация протокола, выбор стека, план интеграции с MM |
| Проектирование | Архитектура, контракты, схема потоков |
| Реализация | Смарт-контракты (Solidity/Foundry), бэкенд (Rust/Go), клиент |
| Тестирование | Unit-тесты, интеграционные тесты, аудит безопасности (Slither, Mythril, Echidna) |
| Деплой | Развёртывание в сеть, настройка мониторинга (Tenderly) |
Базовая версия разрабатывается от 4 недель, расширенная — до 12 недель. В deliverables входят: документация архитектуры, репозиторий с кодом, развёрнутая тестовая среда, инструкция по деплою, обучение команды, месяц поддержки. Свяжитесь с нами для оценки проекта — подберём оптимальное решение под ваш объём и ликвидность.
Закажите консультацию — оценим сложность и сроки за 2 дня. Получите архитектурную схему вашей RFQ-системы бесплатно при заключении договора.