An institutional client wants to sell 500 BTC without slippage. On a regular exchange, such an order would shift the order book by tens of thousands of dollars. The solution is an RFQ system, where a request is sent to several market makers (MMs) who compete for execution. We design and develop such systems for OTC platforms: from protocol design to production deployment with guaranteed slippage <0.1%. Our team has 7+ years in Web3, 40+ DeFi projects, 5 years of RFQ development experience. We'll evaluate your project in 1-2 days — contact us for a consultation.
According to the Practical Encyclopedia of Financial Markets, the RFQ protocol is used for institutional trading of large volumes. In our implementation, average slippage savings for trades from 50 BTC amount to over $10,000 compared to order books.
How the RFQ Flow Works in Practice
1. Client → system: RFQ request {instrument: "BTC/USDC", side: "buy", quantity: 100, expiry: 30s, client_id: "inst_001"} 2. System → market makers: broadcast request (to one or several MMs simultaneously) 3. Market makers → system: quotes {bid: 67450.00, ask: 67480.00, valid_until: T+30s} 4. System → client: best quotes (or aggregation) 5. Client → system: quote acceptance {quote_id: "q_abc123", accept: true} 6. System → MM: execution notification 7. Settlement: asset exchange Quote Management and Aggregation
With multiple MMs, the system can aggregate quotes in several ways:
- Best-of: show the client the best bid/ask from different MMs.
- NBBO (National Best Bid and Offer) in a crypto-OTC context.
- Internalization: if the desk can execute from its own inventory at a better price.
Each quote has an expiry (30–60 seconds). After expiry — auto-cancel. The MM does not want to be exposed to a price given a minute earlier when the market moves.
Partial fills: if an MM quotes 100 BTC, but the client wants 50 BTC — split quote. Or the client requests 200 BTC, but one MM can only provide 100 — multi-venue fill.
How Do We Manage the Market Maker Pool?
The system manages the MM pool with flexible rules:
- Routing rules: which MMs receive which RFQs. Criteria: instrument specialization, trade size, historical hit rate, spread competitiveness.
- Response time tracking: median response time of each MM (typically 50–200 ms). Slow responders are de-prioritized.
- Quote quality metrics: fill rate (>90%), miss rate, stale quotes (<2%).
- Connectivity: WebSocket (low latency) or REST. For institutional integrations — FIX 4.4.
Real-time State Management
An RFQ system is high-throughput and stateful. Redis for hot state: active RFQs and quotes are stored with TTL (30–120 seconds), automatically expired. Pub/sub for real-time notifications to participants. Event sourcing: all events are written to an immutable log, providing an audit trail out of the box.
Settlement Details
Settlement can be on-chain (via smart contract escrow) or off-chain (by agreement). For on-chain we use ERC-20 transfers with multi-call, providing atomicity and transparency.How to Protect the System from Abuse?
Bad actors can abuse the system. We implement several protective mechanisms:
- Last look: the MM retains the right to reject an accepted quote. Clients dislike last look, but MMs require it. We balance: 1-second timeout, penalty for >10% rejection.
- Rate limiting for RFQ requests: a client should not make hundreds of RFQs per second for "price discovery" without intent to trade (limit 10 requests per second).
- Minimum trade size: only real institutional trades (from 1 BTC or equivalent $50k).
- IP restrictions: only whitelisted institutional clients.
An RFQ system is more complex than a simple matching engine, but it provides an institutional-grade trading experience for large volumes. Compared to an order book, RFQ gives 5–10 times less slippage for volumes over 50 BTC and protects against MEV.
Why RFQ is Better Than an Order Book for Large Volumes
| Parameter | RFQ | Order Book |
|---|---|---|
| Price transparency | Price revealed only after request | All orders visible in the book |
| Slippage | Minimal (MMs compete) | High for large orders |
| Protection from MEV | No front-running | Possible sandwich attacks |
| Execution speed | 1–5 seconds | Milliseconds |
| Ideal volume | >100 BTC | <10 BTC |
What's Included in RFQ System Development
| Stage | Result |
|---|---|
| Analysis | Protocol specification, stack selection, MM integration plan |
| Design | Architecture, contracts, flow diagram |
| Implementation | Smart contracts (Solidity/Foundry), backend (Rust/Go), client |
| Testing | Unit tests, integration tests, security audit (Slither, Mythril, Echidna) |
| Deployment | Network deployment, monitoring setup (Tenderly) |
A basic version takes from 4 weeks, an extended version up to 12 weeks. Deliverables include: architecture documentation, code repository, deployed test environment, deployment guide, team training, and one month of support. Contact us for a project evaluation — we'll select the optimal solution for your volume and liquidity.
Request a consultation — we'll assess complexity and timeline within 2 days. Get a free architectural diagram of your RFQ system when signing a contract.