Spot RFQ

Request-for-quote (RFQ) is one of the liquidity sources the Arcus spot router draws on — alongside on-chain AMM pools — when filling a spot trade. In the RFQ flow a taker asks for a price, professional makers respond with firm quotes, and the server settles the best firm pricing — which may combine quotes from several makers — against the taker’s signed intent in one atomic settlement transaction. Takers sign an intent that caps their downside; makers sign quotes that bind their terms; nothing settles unless every leg is satisfied at once.

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 pricing 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, including a slippageBps tolerance. The server requests indicative liquidity from makers, derives the minBuyAmount floor from slippageBps and the quoted price, and returns the intent for the taker to sign. slippageBps is validated server-side — invalid values are rejected.

Sign intent

The taker signs the intent (EIP-712 typed data) and returns it to the server.

Firm quote

The server forwards the intent to makers without minBuyAmount, so makers cannot price against the taker’s limit. Each maker is asked to quote the full sellAmount; the server ranks the firm quotes by price and may combine quotes from several makers to fill the trade, as long as the combined output meets minBuyAmount.

Submit

The server bundles the signed taker intent with the winning firm quote(s) and submits one transaction to the settlement contract. Every leg is atomic — all fill or none do.

Quote parameters

What the taker sends to request a quote. Makers receive a separate firm-quote request built from the trade fields; the server does not pass on slippageBps.

Param	Type	Required	Description
`chainId`	positive integer	No	Chain where settlement will occur. Optional for the taker — each router serves one chain and rejects a mismatch.
`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	No	Slippage tolerance in basis points; the server derives `minBuyAmount` from it.
`allowWrapped`	boolean	No	Opt in to wrapped-token settlement of the buy token. Defaults to `false`; bound into the signed intent.

Slippage protection is set with slippageBps: the server derives the taker-signed minBuyAmount floor from it (invalid values are rejected) and enforces that floor when ranking firm quotes.

Intent

The server builds the intent from maker indicative liquidity and returns it to the taker for signing.

Field	Purpose
`chainId`	Target chain for settlement.
`sellToken` / `buyToken`	Asset addresses.
`sellAmount`	Amount of `sellToken` in base units.
`minBuyAmount`	Minimum `buyToken` the taker will accept — derived server-side from `slippageBps`, and never sent to makers.
`allowWrapped`	Whether the taker accepts wrapped-token delivery.
`taker`	Taker wallet address.
`nonce`	Replay protection for the intent signature.
`deadline`	Unix timestamp after which the intent is void.
`toSign`	EIP-712 typed data (and/or permit structure) the taker must sign.

Correlation between the intent, each maker’s firm quote, and the fill status uses a router-issued per-maker quoteId (bytes32) — the taker does not sign it, and each maker sees only its own.

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 floor when ranking firm quotes.

Firm quote

A firm quote is a maker’s binding response. Each maker is asked for the full sellAmount; the server may settle firm quotes from several makers together to fill one trade.

Field	Purpose
`quoteId`	Echoes the router-issued per-maker id; correlates the firm-quote round and fill 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 `ArcusRfqQuote` witness).
`signature`	The maker’s EIP-712 signature over `signedPayload`.

Trade terms are bound inside signedPayload.message.witness:

Witness field	Purpose
`quoteId`	Must match the request’s router-issued id.
`taker`	Taker wallet from the intent.
`maker`	Must match the envelope `maker` and the signature.
`makerBuyToken` / `makerSellToken`	Asset addresses from the maker’s view — the maker buys what the taker sells (`makerBuyToken == sellToken`, `makerSellToken == buyToken`).
`makerBuyAmount` / `makerSellAmount`	Sizes in base units. `makerBuyAmount` is the sell-token size the maker will take (at most the intent’s `sellAmount`); `makerSellAmount` is the maker’s firm output.
`nonce`	Binds to the Permit2 `message.nonce`.
`validUntil`	Unix seconds after which the quote is void; bound to the Permit2 `message.deadline`.

chainId lives in signedPayload.domain.chainId. The Permit2 message.deadline must stay valid through settlement — the server drops firm quotes whose deadline leaves less than its minimum time-to-live, so it can submit before the deadline lapses.

Settlement guarantees

Atomic. The signed intent and the winning firm quote(s) settle in one transaction. If any leg fails, the whole trade reverts.
Slippage-bounded. The server only submits when the total 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.

Accounts & collateral

Perpetuals

Spot

Disclaimer and Terms

Why RFQ

Roles

The flow

Quote parameters

Intent

Firm quote

Settlement guarantees