RFQ Flow

The RFQ (Request for Quote) system enables users to trade options directly with the Main Market Maker (MMM). Unlike the limit order book where users trade against each other, RFQ provides instant execution at prices quoted by professional market makers.

---

Overview

RFQ trading combines off-chain quoting with on-chain settlement:

Key Benefits:

• Instant execution — No waiting for order book matching
• Professional pricing — MMMs provide competitive, market-aware quotes
• Atomic settlement — Positions created in a single transaction
• Flexible sizing — Partial fills supported

---

Participants

Main Market Maker (MMM)

The MMM is a privileged address that:

The MMM is registered by the protocol owner and can be queried via the PositionManager.

User (Quote Taker)

The user:

1. Requests quotes from MMM off-chain (via API, chat, etc.)
2. Receives a signed quote with price, size, and expiry
3. Submits the quote on-chain to execute the trade
4. optionBalance and premiumBalance updated for both parties
5. Receives a long or short position — settlement at expiry determines actual cash flow

---

Quote Structure

An RFQ quote contains all parameters needed for on-chain execution:

Quote Fields

Series Parameters

The quote also includes full series parameters for lazy registration:

Series ID Verification:

$$\text{seriesId} = \text{keccak256}(\text{pairId}, \text{strike}, \text{optionExpiry}, \text{isCall})$$

The contract verifies that the provided seriesId matches the hash of the series parameters. This prevents the MMM from accidentally signing for the wrong series.

---

Execution Flow

High-Level Flow

Off-Chain Phase:

1. User requests a quote from the MMM (e.g., "I want to buy 10 ETH-USDC calls, strike $3000, Dec 31")
2. MMM calculates the price, creates a quote (e.g., $150 per contract, size = 10), and signs it with EIP-712
3. MMM sends the signed quote to the user

On-Chain Phase: 4. User submits the quote to the RFQ contract 5. Contract validates: signature is from registered MMM, quote not expired, series not expired, nonce matches MMM's current nonce, fill amount ≤ remaining quote size, and taker is authorized (or quote allows anyone) 6. Contract executes: registers series if new (lazy creation), updates optionBalance and premiumBalance for buyer and seller, and collects RFQ fee from taker 7. Emits event with fill details

Validation Steps

The contract performs these checks before executing any trade:

---

Trade Direction

The takerIsBuying flag determines who gets which position:

Taker Buys Long (takerIsBuying = true)

The MMM creates a pair, gives the long position to the taker and keeps the short. Premium balances are updated for both parties.

After trade (Four-Instrument Model):

• Taker: +optionBalance (long), -premiumBalance (payer)
• MMM: -optionBalance (short), +premiumBalance (receiver)
• No premium changes hands (only fees; settlement at expiry determines actual P&L)

Taker Buys Short (takerIsBuying = false)

The MMM creates a pair, gives the short position to the taker and keeps the long. Premium balances are updated for both parties.

After trade (Four-Instrument Model):

• Taker: -optionBalance (short), +premiumBalance (receiver)
• MMM: +optionBalance (long), -premiumBalance (payer)
• No premium changes hands (only fees; settlement at expiry determines actual P&L)

---

Trade Examples

Example 1: User Buys Calls

User wants to buy 10 ETH-USDC $3000 calls at $150 premium each. Before the trade, the user has no position and $2,000 USDC deposited; the MMM has no position and $50,000 USDC deposited.

After the trade (takerIsBuying = true, fillAmount = 10):

• User: optionBalance = +10 (long), premiumBalance = -$1,500 (payer)
• MMM: optionBalance = -10 (short), premiumBalance = +$1,500 (receiver)
• Deposits unchanged: User still has $2,000, MMM still has $50,000

Example 2: User Sells Puts

User wants to sell 5 ETH-USDC $3000 puts at $200 premium each (user takes short). Before the trade, the user has no position and $5,000 USDC deposited; the MMM has no position and $50,000 USDC deposited.

After the trade (takerIsBuying = false, fillAmount = 5):

• User: optionBalance = -5 (short), premiumBalance = +$1,000 (receiver)
• MMM: optionBalance = +5 (long), premiumBalance = -$1,000 (payer)
• Deposits unchanged: User still has $5,000, MMM still has $50,000

---

Premium Balance Recording

No premium changes hands at trade time—only fees are transferred. Premium balances are updated:

$$\text{premiumDelta} = \frac{\text{price} \times \text{fillAmount}}{10^{18}}$$

At expiry, positions settle using the net settlement formula.

---

Fee Structure

RFQ trades have a dedicated fee rate. See Fee Structure for RFQ fee calculation and flow.

---

Nonce Management

Each MMM has an independent nonce counter for replay protection.

How Nonces Work

Quote Cancellation

Individual quotes cannot be explicitly cancelled. To invalidate quotes:

---

Partial Fills

Quotes support partial fills—the taker can fill less than the full quote size.

Fill Tracking

A quote can be filled multiple times by the same or different takers until fully filled.

---

Lazy Series Registration

RFQ supports lazy series registration—if the series doesn't exist when a quote is filled, it's created automatically. See Options Creation for validation rules and the creation flow.

---

Security Considerations

Signature Replay Protection

MMM Verification

• Only registered MMMs can have their quotes executed
• Signature must match the mmm address in the quote
• MMM status is checked on every fill

Taker Restriction

This allows MMMs to provide exclusive quotes to specific users.

Premium Balance Direction

The takerIsBuying flag creates unambiguous premium balance direction:

• Buyer gets negative premiumBalance (payer)
• Seller gets positive premiumBalance (receiver)
• No ambiguity about settlement obligations

---

Contract Integration

Storage

Dependencies

The DiffusalOptionsRFQ contract integrates with:

• DiffusalOptionsPositionManager: For isMMM(address) to verify MMM registration, and updatePosition() to update optionBalance and premiumBalance
• IERC20 (Collateral Token): For fee collection to feeRecipient

---

Summary

The RFQ system provides:

• Instant execution — No need to wait for order book matching
• Professional pricing — MMMs provide competitive quotes
• Atomic settlement — Positions created in a single transaction
• Flexible sizing — Partial fills supported via fillAmount
• Security — EIP-712 signatures, nonce protection, taker restrictions

---

Contract Implementation

---

Related

Protocol Documentation

• Order Book — Peer-to-peer limit order trading where anyone can be a maker
• Options Creation — How series are lazily registered on first trade
• Margin System — Collateral requirements for positions
• Fees — RFQ fee structure

Contract Documentation

• DiffusalOptionsRFQ — Core RFQ logic and EIP-712 validation
• DiffusalOptionsPositionManager — MMM registration and position creation
• DiffusalOptionsSeriesRegistry — Lazy series registration and validation
• DiffusalCollateralVault — Collateral for margin requirements