A DEX aggregator finds the best way to fill a token trade across many decentralized exchanges and holds almost no liquidity of its own. This guide uses 1inch as the main example to explain classic routing, signed limit orders, intent-based swaps with resolvers, and the work behind DEX aggregator development.
An aggregator and an AMM succeed for different reasons. A Uniswap-style AMM depends on the liquidity in its pools. An aggregator depends on the quality of its quotes, the freshness of its data and the safety of the router contract that users approve.
How a DEX aggregator routes a trade
Suppose a user wants to swap 100,000 USDC for ETH. A classic aggregator takes five steps:
- Index liquidity. Off-chain services track the state of thousands of pools on each supported chain, including constant-product AMMs, stable-swap curves, concentrated liquidity ranges and order books.
- Search for a route. The routing engine splits the order across venues and intermediate tokens. For example, 60% may go through one ETH/USDC pool, 25% through a USDT hop and 15% through a stable-swap pool. The engine sizes each part so that the last dollar on each path gets about the same price. 1inch calls its routing engine Pathfinder.
- Count the gas. Each extra hop costs gas. On Ethereum mainnet, a split that improves the price by a few dollars can lose money after gas, so the optimizer must price the full execution cost.
- Build the calldata. The aggregator encodes the route into one transaction to its router contract, with a minimum output amount based on the user's slippage setting.
- Execute in one transaction. The router pulls the input token, calls each venue in order and checks the final output against the minimum. If the output falls short, the whole transaction reverts.
The smart contract layer is small, but a bug in it is costly. Users give the router permission to move their tokens, so a bug in the router's external calls can drain every wallet that gave that permission. Attackers have exploited aggregator routers in this way.
A safe router design follows four rules:
- The executor contract that calls venues is separate from the contract that holds user approvals.
- The router checks every external call and its return value.
- The router supports signature-based approvals such as Permit2, so users do not leave unlimited allowances open.
- An independent firm audits every router release.
1inch limit orders
The 1inch Limit Order Protocol lets a maker sign an order off the chain as an EIP-712 typed message that states the assets, the amounts and any conditions. Anyone can submit the signed order onchain and fill it when the trade is profitable.
The Limit Order Protocol locks no funds before the fill, so a cancel costs little. An order can carry conditions, such as a start time or an oracle price that must be reached. Many request-for-quote (RFQ) systems and onchain order books use the same signed-order design.
1inch Fusion: intents and resolvers
Fusion mode replaced the routed transaction with a signed intent: the user signs an order that states the trade, and the user's wallet sends no transaction. Professional fillers called resolvers compete for the order in a Dutch auction.
The auction starts at a rate that favors the user, and the rate falls over a short window. The first resolver that finds the rate profitable fills the order, pays the gas and can source liquidity anywhere, including its own inventory, centralized exchanges and onchain pools.
Users get swaps with no gas fee and better protection from sandwich attacks, in which a bot trades just before and just after a user's public pending swap. A Fusion order never appears as a public pending swap, so the bot has nothing to target. Resolvers sign up in the 1inch Business portal, where each one registers its filling contracts and proves onchain that it controls them.
Fusion+ applies the same model to swaps between chains. The user's tokens are locked in an escrow contract on the source chain, and the resolver's tokens are locked in an escrow contract on the destination chain. Each escrow uses a hashlock and a timelock. The resolver must reveal a secret to claim the user's funds on the source chain, and once the secret is public, it also releases the resolver's funds to the user on the destination chain. The 1inch Business documentation covers the order format and the resolver setup.
1inch Aqua: shared liquidity from wallets
1inch launched Aqua in July 2026. Aqua lets a liquidity provider set a pair, a price range and a fee while the tokens stay in the provider's wallet. The provider approves a token balance once, and Aqua records it, so one balance can back several positions.
When a swap matches a position, Aqua pulls the tokens from the wallet and returns the received tokens and fees in the same transaction. Pathfinder can route trades to Aqua positions, though at launch only verified 1inch resolvers could take Aqua liquidity.
Classic aggregation and intent-based design compared
| Feature | Classic router | Intent and resolver model |
|---|---|---|
| Who submits the transaction | The user | The resolver |
| Who pays gas | The user | The resolver, with the cost built into the fill price |
| Liquidity sources | Onchain venues only | Onchain venues plus private inventory |
| MEV exposure | Depends on the slippage limit and the use of a private RPC | Lower, because there is no public pending swap |
| Hardest part to build | The routing engine and fresh data | Auction design, resolver onboarding and settlement contracts |
| Start-up problem | Small, because existing pools are usable on the first day | Large, because the system needs resolvers that compete |
DEX aggregator development: what to build first
- Classic aggregation first. A new aggregator can serve a new or poorly served chain by routing across existing pools. An intent system works only after it has enough order flow to attract resolvers.
- Data as the main asset. The aggregator needs fast state updates and a gas model for each chain, and it must simulate every pool type exactly. Some tokens take a fee on each transfer or change their balances automatically, and these tokens break simple price math. Each quote should be tested on a private copy of the chain before the API returns it.
- An API for integrators. Much aggregator volume comes from wallets and dApps that call an API, not from the aggregator's own site. A stable, documented quote and swap API is part of the first release.
- Visible fees. Surplus is the part of the output above the quoted price. If the aggregator keeps a spread or a share of the surplus, the quote should show that amount.
Team, timeline and cost drivers
A single-chain aggregator usually needs four roles:
- A backend engineer for indexing.
- An engineer with optimization skills for routing.
- A Solidity engineer for the router and executor.
- A front-end developer.
The team typically needs several months before its quotes beat established aggregators on even a subset of pairs, and the router also needs an audit. Each new chain adds work, because each chain has its own set of DEXs to index and simulate.
A team that wants to run its own pools instead of an aggregator can compare the options in the DeFi exchange development guide, and the white label swap guide covers ready-made swap products.
Frequently asked questions
What is a DEX aggregator?
A DEX aggregator searches many decentralized exchanges for the best price on a trade. It can split the trade across several pools and executes the result in one transaction or through a resolver.
Does a DEX aggregator need its own liquidity?
No. A classic aggregator routes to existing pools. In an intent system, resolvers may use their own inventory, but the aggregator still holds no funds.
How do aggregators make money?
Common models are a small fee on each swap, a share of positive slippage or surplus, and fees paid by integrators or resolvers. The fee should appear in the quote.
What is the biggest security risk?
The router contract that users approve carries the biggest risk. Unchecked external calls, unchecked return values and leftover approvals have caused large losses across the sector.
Can cross-chain swaps work without a bridge?
Yes. Hashlock and timelock escrows, as used in Fusion+, let a resolver move value between chains without a shared bridge. The resolver needs inventory on both chains, and the contracts must handle timeouts with care.