This page explains the model and the message flow. It is conceptual — for the wire formats and endpoints, see the API reference.
Why RFQ
Spot markets for tokenized assets are often thin and fragmented. RFQ lets the exchange source liquidity from many makers on demand and pick the best combination per trade, instead of requiring makers to post resting depth. The taker gets one signed, slippage-bounded outcome; the maker only commits capital when its quote is actually selected.Roles
| Term | Meaning |
|---|---|
| Taker | The party requesting to trade — typically the end user or their wallet. |
| Maker | A liquidity provider that prices and fulfills the RFQ. |
| Server | Relays messages between the taker and makers, and submits the settlement transaction on-chain. |
| Settlement | The on-chain contract that finalizes the trade atomically. |
| Indicative liquidity | Non-binding price/size information from a maker; used to build the intent. |
| Intent | The trade the taker commits to, including minBuyAmount; signed by the taker. |
| Firm quote | A binding price and terms with an expiry — distinct from indicative liquidity. |
The flow
Quote
The taker sends quote parameters. The server requests indicative liquidity from makers and builds an intent, deriving
minBuyAmount from slippageBps when present.Firm quote
The server forwards the intent to makers without
minBuyAmount, so makers cannot price against the taker’s limit. Makers return firm quotes; the server combines the best ones to cover the full sellAmount while still meeting minBuyAmount.Quote parameters
What the taker sends to request a quote. The server forwards the same shape to each maker.| Param | Type | Required | Description |
|---|---|---|---|
chainId | positive integer | Yes | Chain where settlement will occur. |
sellToken | address | Yes | Token the taker is selling. |
buyToken | address | Yes | Token the taker is buying. |
sellAmount | positive integer string | Yes | Amount of sellToken in base units (fixed sell size). |
taker | address | Yes | Taker wallet address; included in the intent and signatures. |
slippageBps | integer 0..10000 | No | Used by the server to derive minBuyAmount on the intent. |
Intent
The server builds the intent from maker indicative liquidity and returns it to the taker for signing.| Field | Purpose |
|---|---|
takerIntentId | 32-byte hex id correlating price, intent, firm quotes, and status. Sent to makers. |
chainId | Target chain for settlement. |
sellToken / buyToken | Asset addresses. |
sellAmount | Amount of sellToken in base units. |
minBuyAmount | Minimum buyToken the taker will accept — never sent to makers. |
taker | Taker wallet address. |
validUntil | Unix timestamp or block after which the intent is void. |
toSign | EIP-712 typed data (and/or permit structure) the taker must sign. |
minBuyAmount is the taker’s protection against bad fills. Because it stays server-side, makers price the trade on its own merits and the server enforces the limit when assembling the fill plan.Firm quote
A firm quote is a maker’s binding response. The server may take all or part of each quote when building the fill plan.| Field | Purpose |
|---|---|
takerIntentId | Echoes the intent id; correlates intent, firm-quote round, and status. |
maker | Maker signer address; the server recovers signature and checks it matches. |
signedPayload | EIP-712 typed data the maker signed (a Permit2 PermitWitnessTransferFrom with an RfqOrder witness). |
signature | The maker’s EIP-712 signature over signedPayload. |
signedPayload.message.witness:
| Witness field | Purpose |
|---|---|
takerIntentId | Must match the intent and request. |
taker | Taker wallet from the intent. |
maker | Must match the envelope maker and the signature. |
sellToken / buyToken | Asset addresses (taker’s view: taker sells sellToken, buys buyToken). |
sellAmount / buyAmount | Sizes in base units. v1 is fixed-sell: sellAmount from the intent, buyAmount from the maker. |
expiry | Unix seconds after which the quote is void. |
chainId lives in signedPayload.domain.chainId. The Permit2 message.deadline must stay valid through settlement — makers enforce a minimum time-to-live so the server can submit before it lapses.
Settlement guarantees
- Atomic. The signed intent and the selected firm quotes settle in one transaction. If any leg fails, the whole trade reverts.
- Slippage-bounded. The server only submits a fill plan whose aggregate output meets the taker’s
minBuyAmount. - Non-custodial. Token movements are authorized by the taker’s intent signature and each maker’s Permit2 signature — no party pre-deposits funds with the exchange.