Order books, RFQ, intents and solvers

Four ways to fill a trade

An AMM swap is only one way a trade is filled onchain, and for large or frequent traders it is often not the cheapest. There are four families, and modern routers mix several of them into a single quote.

The pricing mechanics of the first family are in AMM math. This guide covers the other three and how routers combine them.

Order books, offchain and onchain

A central limit order book holds resting buy and sell orders at explicit prices. A taker who crosses the spread fills against them in price then time priority, walking up the book until the size is done. Suppose ETH is bid at 2,999.50 and offered at 3,000.50 with these asks resting:

The buy averages 3,001.42, about 4.7 basis points above the 3,000 mid, plus the venue's taker fee. Unlike an AMM, depth here is not a formula. It is whatever market makers chose to post, and they can pull it in milliseconds when volatility rises.

That last property is the hard part of putting a book onchain. A maker must be able to cancel faster than informed traders can hit stale quotes, and on a general purpose chain every cancel is a paid transaction competing for the same block as the order that would pick it off. Three designs show the range of answers:

Sources: the Hyperliquid order book docs and the dYdX limit order book docs. Venue profiles are on the Hyperliquid page and in the DEX versus CEX comparison.

Request for quote: a market maker signs a price

In an RFQ system your wallet asks a set of professional market makers for a firm price on your exact size. The best responder signs a quote that a settlement contract will honor for a short window. There is no pool curve to walk: the maker prices from its own inventory and hedges elsewhere, often on a centralized exchange, so for a large trade in a major pair RFQ can beat any pool on the chain.

The weakness is that the maker holds an option. Between quoting and settling the market moves, and a maker whose quote has gone stale may decline to fill. UniswapX calls this fading, and its system can ignore quotes from quoters who fade too often. Every RFQ design needs a fallback for exactly this moment.

Two current examples show RFQ sitting inside broader routers. On Ethereum, UniswapX first collects quotes from a permissioned set of quoters known to Uniswap Labs. The winner of the final hard quote gets an exclusivity window, currently about 24 seconds (two blocks), and if it fades, the order falls through to an open Dutch auction anyone can fill. On Solana, Jupiter's meta aggregator lets its routing engines compete for each order, including its onchain router Metis and its RFQ engine JupiterZ, alongside third party routers.

Intents: sign the outcome, not the path

An intent is a signed message that says what you will accept rather than how to get it: sell this amount of this token, receive at least that amount of another, before this deadline. You do not submit a transaction. A solver (also called a filler or resolver) does, and the settlement contract checks your signature and enforces your minimum. If the solver cannot deliver at least what you signed for, the fill reverts, the solver absorbs the gas and you pay nothing.

Three things change. Gas becomes the solver's problem, folded into your price. MEV protection is built in, because no swap of yours sits in a public mempool waiting to be sandwiched. And price discovery becomes a competition among solvers who can draw on AMMs, private inventory, centralized exchanges and other users' orders at once. The Intermediate guide to limit orders, DCA and TWAP shows the same machinery used for orders that wait for a price.

Dutch auctions: UniswapX and 1inch Fusion

A Dutch auction starts at a price that is good for you and worsens step by step until someone takes it. The first filler for whom the current price is profitable wins, so competition pushes the fill toward the best filler's true cost. Take an order to sell 10 ETH that starts at 30,000 USDC out and decays by 15 USDC a block to a floor of 29,850, a 0.5% tolerance. Filler A can sell the ETH elsewhere for 30,000 and has about 13 of gas and required margin to cover, so it breaks even at an output of 29,987. Filler B has worse access and breaks even only at 29,972.

You receive 29,985 USDC. Without Filler A you would have received 29,970 a block later. The auction discovers the best filler's price without anyone revealing it, and the step size is the price of that discovery: coarser steps leave more on the table, finer ones take longer.

UniswapX runs this RFQ plus exclusive Dutch auction model on every chain it supports. On Ethereum the exclusivity window and decay are measured in time; on the others, including Arbitrum, Base and Unichain, in blocks. A cosigner, currently Uniswap Labs for its own interface and API, updates the auction start to current prices within the bounds you signed. The details are in the UniswapX auction documentation.

1inch Fusion uses the same shape with a gated set of takers. Per the 1inch help center, resolvers are approved addresses that stake 1INCH, must hold at least 5% of total Unicorn Power, and at most 10 are listed; priority fees are capped, with escalating suspensions for resolvers who break the cap. A Fusion order that nobody fills before it expires can be resubmitted at no cost.

Batch auctions and coincidence of wants

CoW Protocol collects signed orders offchain and auctions them in batches to bonded solvers. Its current mechanism, which it calls a fair combinatorial batch auction and which was formalized in a 2024 paper, lets a solver bid on single orders or on groups of orders. The protocol discards batched bids that give any order less than it could get alone, then picks the combination of bids that delivers the most surplus to users. Two properties follow.

Uniform directed clearing prices. Every order selling ETH for USDC in the same batch gets the same price, and so does every order going the other way. Position inside the batch stops mattering, so there is nothing to front run.

Coincidence of wants. If Alice sells 100 ETH and Bob buys 40 ETH in the same batch, 40 ETH can pass directly between them at the clearing price. At a 0.05% pool fee and a price of 3,000, each saves 60 USDC of LP fees on the matched part, plus the impact those 40 ETH would have caused in each direction, and only Alice's remaining 60 ETH needs a pool. Rings of three or more traders across several tokens are possible too.

Aggregators and split routing

An aggregator solves a smaller version of the same problem for one order: how to divide it across pools and venues so the total output is highest. For pools with the same fee and the same starting price, the answer is to split in proportion to depth, which leaves every pool at the same marginal price afterward.

The split gains about 0.128 ETH, roughly 385 dollars, for one extra pool interaction. Real routers add fee tiers, concentrated liquidity ranges, multi hop paths through a third token and the gas of each extra hop, which is why two routers can quote the same trade differently. A meta aggregator goes one level up: it asks several routers, RFQ systems included, and takes the best answer.

Cross chain intents

Intents suit cross chain transfers especially well. In the common escrow design you lock funds on the origin chain with an order stating what must arrive on the destination chain. A solver delivers from its own inventory there, often within seconds, then claims your locked funds once the fill is verified. You wait seconds instead of a bridge's settlement time, and the solver carries the capital and the settlement risk. ERC-7683, a draft standard created in April 2024, defines a common solver facing interface so one solver can serve many intent protocols. The trust question moves to how the origin chain verifies the fill, which is the subject of cross chain security.

The tradeoffs, and how these systems fail

• Solver concentration. Many taker sets are permissioned, capped or bonded, and the edge from private inventory and hedging access favors large, well capitalized firms. Competition protects you only while there is enough of it.
• Fading and expiry. In a sharp move quotes go stale and auctions decay to your floor or expire. Your minimum protects the price; nothing ensures the fill.
• Offchain dependencies. Order feeds, RFQ servers and cosigners are run by companies. If one is down, orders do not fill, though your funds stay in your wallet.
• Censorship. A solver set can decline an order, and a permissioned one can be instructed to. A direct onchain transaction remains the fallback.
• Contract risk. Settlement contracts hold approvals and route funds. Your signed limits are enforced onchain, but a bug in that contract is a risk in the path like any other.

Choosing a mechanism for a trade

Compare venue by venue on the Uniswap versus 1inch and Jupiter versus Raydium pages, and see the MEV guide for what happens to swaps that take the public route.

Common questions

Where to go next