Executive Summary

CLOB and RFQ represent fundamentally different answers to the same question: should liquidity be public market state, or a private execution service?

• RFQ is liquidity-as-a-service: a taker requests a price, a dealer evaluates the request, and execution happens only if the dealer is willing to quote. This works well for large block trades, long-tail markets, TradFi assets, and flow that benefits from privacy.
• CLOB is liquidity-as-state: makers post executable orders before knowing who the taker will be, producing a book that is visible, competitive, and continuously available to traders, bots, vaults, liquidators, and smart contracts alike.

For RISE, this distinction matters: RISE is not only building a perp venue but a fully onchain orderbook primitive that other contracts can interact with synchronously. If the core thesis is atomic composability, liquidity must exist within the same execution environment as the contracts that consume it. RFQ can be useful for execution, but it is not shared onchain state, and for programmable markets, that is the difference that matters.

RFQ is an execution overlay. A composable financial system needs a state layer, and that state layer is the orderbook.

What RFQ Is and Why It Works

Before going further, let’s recall what a Request for Quotes (RFQ) is. RFQ gets applied loosely to several execution models with meaningfully different mechanics:

• Classical RFQ. A taker requests a firm, signed quote from one or more market makers and accepts the quote before it expires.
  • Hashflow and 0x are canonical spot examples.
  • Variational is the most famous perpetual alternative.
• Intent-based systems. A user signs an off-chain intent and solvers compete to fill it. UniswapX, 1inch Fusion, and CoW Protocol are often grouped near RFQ, but their solver-auction mechanics differ meaningfully.
• Hybrid systems. A CLOB as the primary execution layer, with RFQ added on top for institutional blocks, multi-leg trades, or complex structures. Paradex and Derive are useful examples.

This article focuses on classical RFQ versus CLOB in the perpetuals context, with Variational as the primary RFQ reference.

The taker experiences RFQ UX. The liquidity is dealer-intermediated, privately quoted, and usually hedged against deeper external markets (source: https://docs.variational.io/omni/the-omni-liquidity-provider-olp).

RFQ emerged as a response to AMM slippage. Instead of routing through a passive pool and accepting price impact, a taker asks a professional market maker for a live price. The market maker sees the asset, side, size, and often the taker identity, then decides whether to quote, how wide to quote, and how much size to make available. For the right trade this can be excellent execution: a large trader who does not want to walk through an orderbook can ask a dealer for a single price, a protocol listing an illiquid or exotic asset does not need to bootstrap a full two-sided book, and an institution can execute size without broadcasting its intention to the market.

For example, in the 0x’s RFQ system, off-chain liquidity is sourced from professional market makers, real-time quotes are requested, and RFQ orders are exclusive to the specified taker address.

Variational applies a similar logic to perpetuals through its Omni Liquidity Provider (OLP). OLP is a vertically integrated market maker and the counterparty to all Omni trades, combining a vault, market-making engine, and risk-management system into a single entity. This architecture gives RFQ a genuine advantage in long-tail markets: OLP can list any market for which it has a reliable price feed, a quoting strategy, and a hedging path, which is why Variational can support 450+ markets including assets that would be difficult to bootstrap as independent CLOBs.

RFQ Is Private Liquidity

Some might simplistically say that RFQ contributes no liquidity, it only routes existing liquidity to the right takers. In fact, RFQ market makers contribute something real: balance sheet, inventory warehousing, pricing infrastructure, routing, and risk management. They absorb the trade first and hedge later, and that service has genuine value.

A more correct argument should be: RFQ does not create a public, composable liquidity surface. In RFQ, liquidity exists inside a dealer’s risk system until requested and becomes executable only after the dealer chooses to quote. The taker sees a price, but the broader ecosystem does not see a public book, a transparent depth curve, or a reusable state object. Variational is explicit about this model: OLP uses proprietary algorithms and real-time data from external venues to determine fair prices, then hedges directional exposure through those venues as needed.

This makes RFQ discretionary rather than fake. If the dealer’s inventory is constrained, quotes widen. If hedging capacity is constrained, size shrinks. If volatility spikes, quotes can disappear. The same scalability ceiling that OKX Ventures identified in AMM-based perps, where open interest is capped by the pool’s TVL because the pool is the counterparty, applies to RFQ: dealer capital, inventory limits, hedging bandwidth, and external market depth define how much flow the system can absorb. The liquidity is real, but it is private, discretionary, and bounded by the dealer’s own capacity.

What CLOB Is

A Central Limit orderbook (CLOB) pre-exists the trade. Market makers post resting limit orders before knowing who the taker is, what size they need, or which direction they are trading, and takers execute against those resting orders at the posted price. The spread is public, depth is public, queue position is public, and the mid-price is a shared reference that other participants can see, compete against, and improve. This is why CLOBs are the dominant structure for liquid markets: not because every individual trade gets the best possible price, but because the system produces continuous public price discovery.

Market makers in a CLOB face adverse selection: they can be picked off by informed flow. They compensate by adjusting spreads, order size, and cancellation behavior. But because multiple makers compete in the same public market, spreads compress toward fair value. That competition is the price-discovery engine.

In contrast, RFQ compresses spreads differently. The dealer sees the request before committing capital, can identify the taker, evaluate the risk, and quote accordingly. In calm markets this can produce excellent prices, but the mechanism is counterparty selection rather than open competition. RFQ gets tighter by being selective. CLOB gets tighter by being competitive. For a trader doing one block trade, selectivity may be fine. For DeFi infrastructure, competition is the better foundation.

Where RFQ Still Wins

Before making the case for CLOB, we still need to acknowledge RFQ’s advantages.

• Large block trades. A $50M order may not move through an orderbook cleanly because the book is shallow and slippage is very high.
  • An RFQ market maker can internalize a large trade, warehouse risk, hedge over time, and offer a single bilateral price. For institutions moving size, this matters.
• Tight spreads in calm markets. Because market makers see intent before committing, their adverse-selection risk is lower. They can afford to quote tighter to flow they consider benign, and in quiet markets RFQ fill quality can be genuinely competitive.
• Institutional privacy. Some flow needs to be dark. Large directional trades that leak into a public book can move the market against the taker before execution.
• Taker simplicity and predictable UX. A trader does not need to understand orderbook dynamics, queue position, partial fills, or maker/taker fee tiers. He requests a price, then accepts or declines the offer he receives.
• Long-tail and TradFi listings (Cold-start problem). This is RFQ’s sharpest structural edge in perps.
  • Bootstrapping a CLOB requires two-sided flow: makers will not post without takers, and takers will not come without a liquid book. For BTC, ETH, and other high-volume crypto-native markets, this problem is solvable. For gold, oil, copper, FX, and long-tail alts, it is harder.
  • A dealer-led RFQ system can list markets as long as it can price and hedge them, which is exactly why Variational focuses on markets that would be difficult to bootstrap as independent CLOBs.

These advantages are real. They also point to where RFQ belongs: as specialized execution for certain markets and trade sizes, not as the base primitive for composable DeFi.

The Stress Test

When markets move violently, both models lose liquidity. The difference is how they fail.

In a CLOB, the failure is visible. Spreads widen, depth disappears from the top of book, and market impact increases, but takers can see deterioration before sending an order. That is not perfect, but it is legible. In RFQ, the failure can be invisible until the moment of request. The quote comes back wider, smaller, slower, or not at all. The market does not visibly thin, because there was no public market to inspect in the first place.

This matters because “zero slippage” can be misleading. A firm RFQ quote has no slippage within its validity window, and that is true once a quote exists. But a quote that never arrives, arrives too wide, or expires before settlement is the RFQ equivalent of slippage: the trader still fails to execute at the desired price. The experienced fill rate under stress is the product of (percent of requests that actually receive a quote) and (percent of quoted prices worth accepting), and both factors collapse simultaneously during volatile markets.

For single-dealer RFQ models, the risk is more concentrated. If the dealer cannot hedge fast enough, hits inventory limits, or pulls back during volatility, the entire venue can lose effective liquidity at once. A CLOB distributes liquidity across many independent makers with different balance sheets, risk limits, strategies, and time horizons. A single-OLP RFQ model concentrates the market behind one risk engine. That concentration is part of why RFQ can work: it simplifies market making, speeds up listing, and gives users a clean execution experience. But under stress, liquidity cuts both ways: a public book degrades; a private quote engine can vanish.

Why CLOB Wins: The Structural Arguments

Transparent Pricing

Prices, depth levels, slippage, funding rates are public signals on a CLOB, even at very thin liquidity. Every participant, from retail traders and protocols to aggregators, data analysts, liquidators, and market makers, can observe them. This creates price discovery: the competitive process by which the market determines what an asset is worth.

In an RFQ system, these signals are limited and mostly private. Each quote is a private agreement between specified counterparties. A taker receives a price, but the broader market does not receive a signal. At any given moment, different takers may hold different signals. A taker can shop multiple market makers, but the reference point itself remains private and the quote is consumed and disappears.

Permissioned vs Permissionless Market Making

Anyone can post a limit order on a CLOB: retail traders, protocol vaults, or algorithmic market makers. In practice, professional market makers dominate most liquid books because adverse selection punishes unsophisticated liquidity providers. But the door is structurally open, and allows anyone to become a market maker. For example, Hyperliquid’s HLP vault demonstrates this at scale: passive LPs participate in market making without running a full MM operation.

Being a market maker is permissionless on a CLOB. A snapshot of top market makers/vaults on Hyperliquid (source: https://app.hyperliquid.xyz/vaults).

RFQ gatekeeps by design, and that permissioning is not incidental but part of the spread-compression mechanism. In a CLOB, makers post blind and get picked off by informed takers, so they must price that risk into spreads. In RFQ, the maker sees the request first: it can refuse suspicious flow, quote wider to toxic flow, size down, or stop quoting altogether. That discretion allows tighter pricing in calm markets, but it also concentrates maker revenue and market access among the dealer set. RFQ’s permissioned structure is the source of both its strength and its structural limitation.

Flexible User Roles

In RFQ, the user is almost always a taker: they request liquidity, the dealer provides it, and the user pays the spread. Market making is a privileged role, controlled by the protocol or some whitelisted entities. There is no natural way for a normal user, vault, DAO treasury, or smart contract to post passive liquidity into the same system and earn the spread. On a CLOB, users are flexible in choosing the role. A trader wanting immediate execution crosses the spread (taker), and a trader willing to wait posts a limit order (maker).

This matters especially for RISEx. Instead of asking “can a trader get filled?”, we ask “can any EVM contract become a participant in the market?”. With RFQ, the answer is mostly no: the contract can consume a pre-fetched quote, but it cannot become part of the market’s liquidity surface. It is, however, possible with an onchain CLOB.

Equal Access

RFQ supporters often frame personalization as a feature, and they are right that sometimes it is. A dealer can quote better prices to flow it considers uninformed, quote wider to flow it considers toxic, and refuse to quote accounts that look risky. This is rational risk management. But it also means the market is structurally counterparty-specific. 0x RFQ orders, for example, are exclusive to the two counterparties and can only be filled by the specified taker address, which is useful for preventing front-running but also illustrates the basic nature of RFQ: every quote is bilateral.

In a CLOB, a displayed resting order is available to whoever reaches it first, subject to price, size, and queue priority. The maker does not get to reprice after seeing the taker. This does not mean CLOBs eliminate all forms of discrimination or adverse-selection management; makers can still cancel, resize, choose venues, and adjust their strategies. But executable liquidity itself is public. A posted order is a commitment to the market, not a private response to a selected counterparty. For DeFi, a smart contract should not need a relationship with a dealer to access liquidity. A liquidation engine should not be quoted differently because of who deployed it. A vault should not need permission to become a maker. Public markets are not always cheaper for every trade, but they are fairer as infrastructure.

Price Discovery Feeds Everything

RFQ pricing does not feed back into the ecosystem: it is private, bilateral, and ephemeral. This is the dark-pool problem in traditional finance, where private execution can improve outcomes for individual block trades but weaken the public price signal everyone depends on. Because CLOB spreads converge toward fair value through open competition, the mid-price becomes a useful reference for the broader ecosystem. Oracle designs can reference it, liquidation engines can use it, funding rates can derive from it, and options protocols can price against it. In fact, even RFQ’s market makers utilize CLOB’s signals to price against their takers.

Latency

RFQ latency is variable and market-maker-controlled. The round trip, from request sent to market maker pricing to taker acceptance to settlement, adds overhead in normal conditions. Under stress it gets worse: market makers may slow responses, size down, batch requests, or stop responding altogether.

For a human trader, variable latency may be acceptable. For a smart contract trying to execute a multi-step atomic strategy, it is not: a contract cannot wait for an off-chain market maker to respond mid-execution. CLOB execution latency can be somewhat deterministic and predictable. On RISEx specifically, the orderbook and matching engine sit inside the same synchronous execution environment and the matching latency is 1ms. Every action in the same transaction sees consistent orderbook state. This is in contrast to RFQ, where information lags between intent and execution.

The Composability Argument: RISEx’s Core Thesis

This is where the CLOB versus RFQ debate stops being abstract and becomes architectural.

DeFi’s value is not just individual protocols but protocols composing with each other: a lending position that atomically liquidates into a hedge, a vault that rebalances and hedges in one transaction, a structured product that packages perps exposure with yield, or an aggregator that routes across multiple venues inside a single operation. Composability is the mechanism that makes the whole greater than the sum of its parts, and for composability to work, primitives must be onchain state that other contracts can read and interact with atomically.

Why CLOB but not RFQ?

RFQ can settle onchain after a signed quote has already been fetched, and it would be wrong to say RFQ can never be part of an atomic transaction. A taker can request a quote off-chain, receive a signed order, pass that order into a transaction, and settle it atomically if the quote is still valid. But that is not synchronous composability. A smart contract cannot pause mid-execution, ask five market makers for fresh prices, wait for responses, compare quotes, select the best one, and then continue executing lending, margin, liquidation, vault accounting, and settlement logic inside the same transaction. The quote-request step lives outside the EVM, and that is the hard boundary. The properties that make RFQ useful, including market-maker discretion, request-specific pricing, off-chain latency, and ephemeral quotes, are the same properties that make it weak as composable infrastructure.

Dashed arrows: off-chain request/response. Solid arrows: synchronous onchain execution.

RISEx takes the opposite route: make the orderbook an EVM-native primitive. When liquidity is already state inside the same execution environment, contracts can read it, route through it, and settle against it synchronously.

• A lending protocol can atomically liquidate an undercollateralized account directly into the RISEx orderbook.
• A basis strategy vault can atomically buy spot and short perps in the same transaction.
• An aggregator can route through perps liquidity as part of a broader onchain strategy.
• A liquidation engine can know that either the entire sequence succeeds or the transaction reverts.

None of this is native to RFQ, not because RFQ implementations are bad, but because the architecture puts price discovery outside the transaction.

Fully Onchain Matters

Not every CLOB has the composability property described above. Hyperliquid, Lighter, and most centralized exchanges run CLOBs, but a CLOB is only synchronously composable with EVM contracts if the orderbook itself is available inside the same execution environment.

Hyperliquid has made major progress toward connecting HyperEVM contracts with HyperCore liquidity. CoreWriter enables smart contracts on HyperEVM to create transactions on HyperCore, but that is still an interaction between two execution domains: the EVM side and the specialized orderbook side. Lighter’s planned LighterEVM follows a similar pattern, separating the core matching engine from a sidecar VM with block-level or proof-dependent state sharing.

Both venues made a deliberate choice to optimize the order book separately from general computation, and for raw trading performance that tradeoff has merit. The cost is that the composability boundary remains. RISEx takes a different path: make the orderbook an onchain primitive from the start, so that any contract can interact with it atomically within a single transaction.

The Block Trade Exception

RFQ excels at large block trades with better prices than on any CLOB. A dealer can offer a single clean price with no impact by internalizing sizes, hedging over time, etc. This advantage is real and exactly why OTC desks or dark liquidity exist in traditional finance.

However, the question is narrower: does block trading define the right base architecture for DeFi perps?

The answer is no. Block trades are the exception, not the shape of the market. Take a look at Hyperliquid (the largest perpetual CLOB DEX), data in April showed that while daily active users tripled from ~20k to ~70k, the average perpetual trade size fell from a peak of ~$4.5k to $1.7k.

Source: AlliumLabs.

Most DeFi activity is not a single institution moving $50M in one click. It is liquidations, hedges, vault rebalances, arbitrage, retail flow, collateral management, strategy execution, and protocol-to-protocol interactions. These flows need predictable, transparent, composable access to liquidity. They do not need a dealer deciding whether to quote them. Optimizing the entire base layer for the $50M institutional block trade while most trades are under $5k is a category error.

The natural hierarchy is CLOB first, RFQ as a later overlay. The deep CLOB provides public price discovery, continuous liquidity, transparent depth, and composable state that the whole ecosystem depends on. With this foundation being set, an RFQ layer can later serve large block trades that should not be routed directly through the visible book. RFQ is useful at the edge, but it should not be the foundation.

TradFi Parallel: Exchanges vs Dark Pools

Traditional finance already ran this experiment. Public exchanges produce the reference price. Dark pools and OTC venues execute private flow around that reference. Dark execution can improve outcomes for individual block trades, but if too much activity migrates away from public markets, price discovery weakens. The private venue depends on the public market while simultaneously reducing the quality of the signal it consumes.

RFQ has the same relationship to CLOBs. It can provide better execution for certain takers in certain conditions, but it does not replace the public market as the source of price discovery. It routes around it, references it, and often hedges back into it. A financial system can support private execution, but it cannot be built entirely on private quotes.

Verdict: CLOB is the Right Choice for RISEx

RISEx’s thesis is that perps liquidity should be programmable state, not a dealer service. This is what makes RISEx useful as infrastructure rather than just as an exchange. Lending protocols, vaults, structured products, liquidators, aggregators, and market makers can all build on top of it. And every argument above leads to the same solution: CLOB.

An RFQ model cannot serve as the foundation not because it is badly designed, but because its core properties, off-chain quoting, request-specific pricing, etc. are structurally incompatible with synchronous onchain composability.

The previous articles (this, and this) in this series focused on where the orderbook lives: EVM-native on RISE, async or cross-domain elsewhere. This article is the same question at a higher level of abstraction: is liquidity something protocols can compose with, or something they must ask for? For RISEx, it has to be the former and everything else follows from that.

What About CLOB-RFQ Hybrids?

Venues like Paradex and Derive have demonstrated the hybrid model in practice: a CLOB as the primary execution layer, with RFQ added for large, complex, or institutional trades. In this hybrid model, execution sits on a frontier where CLOBs, RFQs, and dark pools each optimize for different axes: price, size, immediacy, information-leakage risk, execution complexity.

So should RISEx support RFQ? There is no definitive answer today. The right time to think about this is when the CLOB layer has enough liquidity depth that the remaining thing is to handle exceptional flow. Most hybrid venues built CLOB first then added RFQ when the demand proved it was worth the complexity. Investing heavily to optimize an edge case before the foundation is deep would be the wrong prioritization.

Conclusion

RFQ is a powerful execution model for specific use cases: large block trades, long-tail markets, RWA perps, institutional privacy, and dealer-intermediated flow. Variational has built a credible product around exactly that thesis. But RFQ is not the right foundation for composable DeFi. Its liquidity is private, discretionary, and dealer-mediated. Its quotes are bilateral and its maker role is permissioned.

CLOBs make a different tradeoff. They expose liquidity before the trade. They produce public price discovery. They let users choose between maker and taker roles. They degrade visibly under stress. And when implemented as EVM-native state, they become composable infrastructure. That is why RISEx is CLOB-first. RFQ is liquidity-as-a-service, RISEx is building liquidity as a globally-shared state which enables programmable markets.

RISEx is a fully onchain CLOB perp DEX built on RISE Chain. Read the previous articles in this series:

• RISEx vs. Hyperliquid
• *CLOB vs. AMM
• RISE vs. Lighter