What is an intent-based DEX aggregator?
You sign the outcome you want, a solver competition executes it. Here is how intents differ from routers and RFQs, and why batch auctions change the trader's position.
Last updated:
The short version: an intent-based DEX aggregator lets you sign what you want (sell this token, receive at least that amount) instead of submitting a routed swap transaction yourself. Competing solvers execute the signed order, pay the gas, and cannot fill it below your signed limit. Uniform clearing prices per token pair and offchain submission mitigate common MEV; settlement itself can still be public. Ophis is an intent-based aggregator built on CoW Protocol's batch-auction design, extended for autonomous agents.
What is a trading intent?
A trading intent describes a desired outcome rather than a fixed route. A standard Ophis ERC-20 order is signed offchain with tokens, amounts, receiver, limit and expiry. The contract enforces those limits. Unfilled ERC-20 orders expire without moving unsold funds; native-token deposits and bridge routes have separate recovery rules.
How is that different from a classic DEX aggregator?
A classic aggregator quotes you a route, then hands you a transaction to submit yourself: you pay gas, the routing calldata is fixed at signing time, and the pending transaction is visible in the public mempool where slippage tolerance can be exploited. With an intent, you only sign the outcome. A solver builds and submits the settlement transaction, pays the gas, and absorbs the execution risk: if the market moves, the solver either fills you at your limit or better, or does not fill you at all.
What is a solver?
A solver is a professional execution party that competes to fill signed intents. In each batch, solvers propose settlements sourcing liquidity from on-chain AMMs, aggregators, and their own inventory; the solver offering the best execution wins the batch. Competition is what turns better routing into better prices for the trader instead of profit for the router.
What is batch-auction settlement?
Orders are collected into discrete batches and all trades of the same token pair in a batch settle at one uniform clearing price. There is no advantage to being ordered first or last inside the batch, which reduces common ordering advantages without eliminating every external-pool settlement risk. When two orders in a batch want opposite sides of the same pair, they can settle against each other directly, a coincidence of wants, without touching an AMM at all.
Where does RFQ liquidity fit in?
Request-for-quote systems ask professional market makers for a firm price on a specific size. Intents generalize this: solvers can incorporate RFQ quotes, AMM routes, and private inventory into one settlement, and the batch auction decides which combination wins. A trader does not choose between RFQ and on-chain routing; the solver competition does.
Is an intent-based aggregator custodial?
It depends on the flow. Standard signed ERC-20 orders keep funds in the wallet until settlement, with the signing key held locally. Native-token, bridge and OTC paths can involve deposits or escrow. Upstream audits cover shared code, not every Ophis change or external provider; see the security page for scope.
How Ophis implements this
Ophis adds a natural-language intent layer (describe the trade, the parser fills the order), a public MCP server so autonomous agents can trade with their own keys, and the @ophis/sdk safety helpers for building bounded orders. Fees are on the pricing page, the chain list on supported chains, and the custody and audit detail on the security page. For the MEV mechanics in depth, read MEV-protected swaps, explained.