RFQ, AMM and order books: three ways to arrive at a price

Where does the price at which a trade executes come from? There are three common answers. In an order book, the price is set by other participants' orders, lined up in a queue. In an automated market maker (AMM), a formula computes it from the pool's reserves. In the request for quote (RFQ) model, a market maker names it in response to a specific request.

These are not three versions of one mechanism but three different answers to the question of who takes on the risk and who sees what before the trade. So it is more useful to compare the models by principle — who sets the price, what is known in advance, what limits size — than by which one is “better.” Below is a section on each model, followed by a summary table.

Order book: a price from a queue of other people's orders

In a central limit order book (CLOB), the price is set by participants who have posted limit orders to buy and sell in advance. A trade happens when a new order meets one already resting on the opposite side.

There are two roles. The maker posts a limit order and waits, adding liquidity to the book. The taker sends an order that executes immediately against the best resting orders, removing liquidity. The same participant can play either role in different trades.

Orders are matched by a matching engine. One common rule is price-time priority. The description of the CME Globex matching algorithms says the FIFO algorithm uses only price and time: among orders at the same price, the one that arrived first is filled first, and an order whose size is increased or whose price is changed loses its place in the queue (CME Group). The same source describes other rules, such as pro-rata allocation, so “price, then time” is typical but not the only option.

Order book depth is the total size of orders at different price levels. If there are few orders, a large order walks through several levels and fills at a worse average price. A report by the Markets Committee of the Bank for International Settlements (BIS) describes the order book as a queue of orders executed in a set sequence and notes that on interdealer venues it is usually transparent before the trade: a participant can see the prices at which they can buy and sell (BIS).

The model's weak point is its dependence on whether anyone is there to post orders. In new and thinly traded markets, the book can be thin: the spread is wide, depth is shallow and every sizable trade moves the price.

AMM: a price from a formula and pool reserves

In an AMM there is no opposing order: the trader trades against a pool holding reserves of two tokens, and a formula computes the price. The reserves are deposited by liquidity providers (LPs).

The Uniswap documentation describes a pool as reserves of two ERC-20 tokens; anyone who deposits a pair of tokens can become a liquidity provider. In Uniswap v2, a provider receives fungible pool tokens representing their share of the reserves, and the pool's trading fees accrue to providers.

The price is set by the constant product formula x·y=k, where x and y are the token reserves and k is an invariant that must stay the same or grow after every trade. It follows that the larger a trade is relative to the pool's depth, the more it moves the price; the documentation calls this price impact. In Uniswap v3 and v4, the same formula applies within the price range the provider has chosen.

This means a liquidity provider in an AMM does not set the price themselves, as the author of a limit order in an order book does. They accept that the formula will recalculate the price after every trade and that the mix of reserves holding their share will shift along with it. The role that makers play in an order book is split here between providers, who supply capital, and the formula, which quotes.

The model has its own risks. On a public blockchain, a swap transaction is visible in the queue of unconfirmed transactions (the mempool) before it is included in a block. ethereum.org describes a “sandwich” attack: someone spots a large swap on a DEX, buys right before it and sells right after — at a price moved by the other trade. This is one form of maximal extractable value (MEV). In addition, the price in a pool changes only through trades with it, so its divergence from other venues is closed by arbitrageurs; the same page cites arbitrage between DEXs as the simplest example of MEV.

RFQ: a price on request

In the RFQ model, the taker first signals that they want to trade, and one or more makers respond with quotes. The price is named by the maker for a specific request — not by a resting order and not by a formula.

The model has long been used in over-the-counter (OTC) markets. A 2016 BIS report on electronic bond trading notes that dealer-to-client platforms are usually built on RFQ: the user asks market makers for a price on a trade of a given size. Systems differ in whether the parties disclose their names and the direction of the trade, how many participants receive the request and whether quotes are executable or only indicative. In most such systems in the bond market, the client polls only dealers, and only a small number of them.

The same report explains why the model persists: in some segments of the bond market, instruments trade too rarely to sustain a continuous order book, and platforms build various versions of RFQ. According to the report, most trades in the interest rate swap market were also made in response to a request for quote rather than through an order book, with banks remaining the main market makers. In other words, RFQ fits where standing opposing orders are scarce and a maker is willing to price each request and manage the resulting risk itself.

A characteristic element of RFQ is the last look. The FX Global Code defines it as a practice in which a participant receiving a trade request has a final opportunity to accept or reject it at its quoted price (GFXC). The Code requires disclosing to clients how last look is applied and states plainly that if a request is rejected, the market risk stays with the client.

RFQ at the Variational protocol level

Variational's documentation calls the protocol an RFQ protocol that does not use an order book. The general process, as described in the project's documentation, looks like this:

1. The taker creates a request for a specific instrument and sends it to all makers or to a selected list.
2. Makers respond with quotes: a price (two-sided or one-sided) plus settlement pool terms — margin requirements, liquidation penalties and other parameters.
3. The taker chooses a quote and approves the smart contract calls to transfer collateral, but no funds move yet at this stage.
4. The maker performs a last look. Once it confirms, both sides' collateral is moved into the pool and the trade is recorded in the pool's ledger.

This means that in the protocol version, a quote is not just a price but also an offer of the terms under which the position will live from then on. What happens to collateral after confirmation is covered in “What happens in on-chain settlement: a trade's path from quote to ledger.” The Variational Pro application, intended for institutional participants in OTC derivatives, has not launched as of October 2026, according to the documentation.

Simplified RFQ in Omni

In the Omni application, whose mainnet is in private beta as of October 2026, the same mechanism is reduced to a single maker. According to the documentation, the only permitted maker is the Omni Liquidity Provider (OLP), and a quote consists of the price alone: the pool, margin requirements and penalties are set in advance and are the same for everyone.

After the user accepts a quote, two checks take place. OLP performs its last look, checking the trade against its risk limits. Then the execution price is checked against the slippage limit the user has set. Only after that is collateral moved from OLP's vault into the user's settlement pool. According to the project's description, the whole cycle takes seconds. The documentation calls the prices the interface shows before an order is submitted indicative: OLP forms a firm quote at the moment of submission, and it may differ from the displayed price in either direction.

The simplification removes negotiation over terms and the choice of counterparty: within the application there are no quotes from several makers to compare, and the price and available size depend on a single participant. This is a different point of compromise: uniform terms are simpler, but liquidity is concentrated with one counterparty. What limits such a maker's capacity is covered in “Where liquidity comes from and why it is finite.”

Comparing the principles

The table summarizes the models across four questions. It describes architectures, not venues: in practice, hybrids exist — the same BIS report mentions platforms that combine RFQ and an order book.

Each row has a flip side. A public order book offers transparency but does not guarantee that orders will stay in place. An AMM formula returns a price for any size within the reserves, but that price worsens as the trade grows. An RFQ quote accounts for the size and the maker's risks, but the maker keeps the right to decline. For more on the term, see the glossary: last look.

Bottom line: choosing a model means choosing a trade-off

The three models solve the same problem in different ways: finding the other side and a price. An order book makes the price public but depends on how many participants are willing to keep orders posted. An AMM provides a price as long as the pool has reserves, but pays for it with price impact and with the fact that on a public network transactions are visible before execution. RFQ lets a maker price a specific size but shifts to the taker the risk of rejection and dependence on a small number of makers.

So to understand a particular venue, it is more useful to ask not “which model does it use” but who takes on the risk, what data is visible before the trade and who can back out of the trade at the last moment. For a model with a single maker, one more question is added: what an outside observer can compare its quotes against. The architecture itself provides no such reference point. Other articles in this section are in “Technology”.