> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcus.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Spot RFQ
> How Arcus prices and settles spot trades through a request-for-quote flow with off-chain makers and atomic on-chain settlement
Arcus settles spot trades through a **request-for-quote (RFQ)** flow rather than a continuous order book. A taker asks for a price, professional makers respond with firm quotes, and the server bundles the best quotes into a **single 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](/api-reference/introduction).
## 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
The taker sends quote parameters. The server requests **indicative liquidity** from makers and builds an **intent**, deriving `minBuyAmount` from `slippageBps` when present.
The taker signs the intent (EIP-712 typed data) and returns it to the server.
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`.
The server bundles the signed taker intent with the selected firm quotes and submits **one transaction** to the settlement contract. Every leg is atomic — all fill or none do.
```mermaid theme={null}
sequenceDiagram
participant Taker
participant Server
participant MakerA as Maker_A
participant MakerB as Maker_B
participant Settlement
Taker->>Server: quote request
Server->>MakerA: price request
Server->>MakerB: price request
MakerA->>Server: indicative liquidity
MakerB->>Server: indicative liquidity
Server->>Server: build intent
Server->>Taker: intent
Taker->>Taker: sign intent
Taker->>Server: signed intent
Server->>MakerA: intent without minBuyAmount
Server->>MakerB: intent without minBuyAmount
MakerA->>Server: firm quote
MakerB->>Server: firm quote
Server->>Server: combine best quotes to fulfill intent
Server->>Settlement: submit intent plus firm quotes
Settlement-->>Server: tx ack
Server-->>Taker: fill status
```
## 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`. |
Trade terms are bound inside `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.