1inch is not an exchange in the usual sense: it holds almost no liquidity of its own. It finds the best way to fill a trade across many other venues, and later added an intent-based mode where professional resolvers compete to fill your order. Building something like it is mostly a data and optimization problem, with a thin but critical layer of smart contracts.
That distinction matters for planning. A Uniswap-style AMM lives or dies on liquidity. An aggregator lives or dies on the quality of its quotes, the freshness of its data and the safety of the contract users approve their tokens to.
The classic aggregation flow
When a user asks to swap 100,000 USDC for ETH, an aggregator does roughly this:
- Index liquidity. Off-chain services track the state of thousands of pools across AMMs, stable-swap curves, concentrated-liquidity ranges and order books on each supported chain.
- Search for a route. The router splits the order across venues and intermediate tokens, for example 60% through one ETH/USDC pool, 25% via a USDT hop and 15% through a Curve-style pool, so that the marginal price on each path is roughly equal. 1inch calls its routing engine Pathfinder.
- Account for gas. Each extra hop costs gas. On mainnet, a split that improves price by a few dollars can lose money after gas, so the optimizer has to price execution, not just quotes.
- Build calldata. The route is encoded into a single transaction to the aggregation router contract, along with a minimum output amount derived from the user's slippage tolerance.
- Execute atomically. The router contract pulls the input token, calls each venue in sequence, checks the final output against the minimum and reverts the whole thing if it falls short.
The smart contract part is small but high-stakes. Users grant token approvals to the router, so any bug in how it handles arbitrary calldata can drain wallets that approved it. Aggregator routers across the industry have been exploited this way. Keep the executor separated from the contract holding approvals, validate every external call, and consider supporting signature-based approvals like Permit2 so users do not leave unlimited allowances lying around.
Limit orders
The 1inch Limit Order Protocol lets a maker sign an order off-chain (an EIP-712 typed message) specifying assets, amounts and conditions. Anyone can submit it on-chain to fill it when profitable. Nothing is locked in a contract until the fill, so cancelling is cheap, and orders can carry predicates, such as only fillable after a certain time or when an oracle price crosses a level. This design is useful well beyond aggregators: it is the basis for many RFQ systems and on-chain order books.
Fusion: from routing to intents
Fusion mode changed the model. Instead of the user's wallet sending a transaction along a computed route, the user signs an order describing what they want. That order is auctioned to resolvers, whitelisted professional fillers, in a Dutch auction: the rate starts favorable to the user and decays over a short window until some resolver finds it profitable to fill. The resolver pays gas and can source liquidity anywhere, including its own inventory, centralized exchanges or on-chain pools.
The benefits for users are gasless swaps and better protection from sandwich attacks, since there is no public transaction with a loose slippage setting for a searcher to exploit. Fusion+ extends the idea across chains using escrow contracts on both sides with hashlocks and timelocks, so a resolver can only claim the source funds by revealing a secret that also releases the destination funds. The 1inch developer documentation covers the order format and resolver requirements.
Classic aggregation vs intent-based design
| Aspect | Classic router | Intent / resolver model |
|---|---|---|
| Who submits the transaction | User | Resolver |
| Who pays gas | User | Resolver, priced into the fill |
| Liquidity sources | On-chain venues only | On-chain plus private inventory |
| MEV exposure | Depends on slippage and private RPC use | Lower; no public pending swap |
| Hard part to build | Routing engine and data freshness | Auction design, resolver onboarding, settlement contracts |
| Cold-start problem | Small: you can route to existing pools on day one | Large: you need resolvers willing to compete |
What a builder should take from 1inch
- Start with classic aggregation. You can deliver real value on a new or underserved chain by routing across existing pools. Intents only work once you have enough order flow to attract fillers.
- Your moat is data. Fast state updates, accurate simulation of every pool type (including fee-on-transfer and rebasing tokens, which break naive math) and a gas model per chain. Simulate every quote against a forked node before returning it.
- Integrations are distribution. Much aggregator volume arrives through wallets and dApps calling an API, not through the aggregator's own site. Plan a stable, documented quote and swap API from the start.
- Be honest about fees. If you take a spread or a surplus share, show it. Users and integrators compare quotes across aggregators constantly.
Effort and team
A credible single-chain aggregator needs a backend engineer focused on indexing, someone strong in optimization for routing, a Solidity engineer for the router and executor, and a front-end developer. Expect several months to reach quotes that beat incumbents on even a subset of pairs, plus an audit of the router. Adding chains is incremental but never free, because every chain has its own DEX zoo. If you would rather run your own pools, compare this with the guide to choosing a DeFi exchange model or the white-label swap options.
Frequently asked questions
Does an aggregator need its own liquidity?
No. Classic aggregators route to existing pools. Intent-based systems rely on resolvers who may use their own inventory, but the aggregator itself still does not need to hold funds.
How do aggregators make money?
Common models are a small fee on swaps, a share of positive slippage or surplus, and fees charged to integrators or resolvers. Disclose whichever you use.
What is the biggest security risk?
The router contract that users approve. Arbitrary external calls, unchecked return values and leftover approvals have caused major losses across the sector.
Can I build cross-chain swaps without a bridge?
Hashlock and timelock escrows, as used in Fusion+, let a resolver move value across chains without a shared bridge, but they need resolvers with inventory on both chains and careful handling of timeouts.