Інституційний клієнт хоче продати 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-системи безкоштовно при укладенні договору.