# Anatomy of a DEX aggregator: the six stages between your input and your output

> Canonical: https://blazephoenix.xyz/learn/anatomy-of-an-aggregator
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-07-29

Aggregation is six problems wearing one button: discovery, filtering, pricing, allocation, execution and settlement guarantees. Almost every observable difference between two aggregators traces to one of those six answers — and each is checkable by observation, not trust.

From the outside, a swap aggregator is a box with an input and an output. Inside, it is six separate engineering problems, each with its own failure mode, and each of which a given implementation may solve on-chain, off-chain, or not at all. Almost every observable difference between two aggregators — price, reliability, trust assumptions — traces back to a decision at one of these six stages.

## Stage 1 — Discovery: which venues even exist

Before anything can be priced, the set of candidate pools must be found. Two approaches exist. A registry-driven aggregator maintains a list, which is fast but stale by construction: a pool deployed an hour ago is invisible until someone adds it. A derivation-driven one computes where a pool WOULD live given the factory and the token pair, then checks whether code exists at that address — permissionless, no list to maintain, and a new venue is visible the moment it is deployed.

The trade-off is cost: derivation costs reads, and reads cost gas or latency. A serious implementation does both and unions the results, because a registry alone goes stale and derivation alone rediscovers what it already knows.

## Stage 2 — Filtering: which candidates deserve a share

Not every discovered pool should receive part of your trade. Two independent tests apply, and conflating them is a classic error. The first is PRICE QUALITY: is this venue's rate consistent with the others, or is it mispriced? The second is CAPACITY: can it absorb your size at that rate?

The subtlety is what the price test should be measured against. A plain median across candidates can be poisoned: seed the set with several near-empty pools quoting a stale rate and the median moves toward the fiction. Anchoring the comparison on the venue with the largest real token balance fixes it, because moving that anchor requires depositing genuine capital — at which point the manipulator IS the deep pool and arbitrage corrects them.

## Stage 3 — Pricing: where the number comes from

This is the stage that most determines whether a displayed quote survives contact with execution. Three architectures are in use. Off-chain pricing computes the route on a private server and returns signed calldata: fast and flexible, but the number cannot be reproduced by anyone else and disappears when the server does. On-chain pricing computes the quote by calling the same contracts that will settle the trade: slower per request, reproducible by anyone with a node, and structurally unable to diverge from execution. Quoted pricing asks each venue for its own answer rather than re-implementing its curve.

Each has a genuine cost. The point is not that one is universally right — it is that the choice is invisible in the interface and decisive in the outcome, and a user is entitled to know which one produced the number on their screen.

## Stage 4 — Allocation: how much goes where

Given a filtered candidate set, how should the order be divided? The answer is a constrained optimisation with a clean solution: because impact is convex in size, splitting is never worse than a single fill, and the optimum is reached when every venue receiving a share pays the same marginal rate. Shares therefore track real depth, not venue count.

Two bounds apply in practice. Each additional leg costs gas and adds one more pool whose state can move before inclusion, so the leg budget should extend only while the expected saving exceeds the marginal cost. And the depth used for weighting must be comparable across venue families — a raw liquidity figure from one family is not the same quantity as a reserve balance from another.

## Stage 5 — Execution: the shapes a swap can take

Different venue families demand different interaction patterns. Some expect tokens pushed in first and then a swap call with the computed output; some call back into the caller mid-swap to collect payment; some require an approval and a named exchange function; some hold all assets in a singleton that must be unlocked, settled and drawn from in sequence.

Two properties separate a robust router from a fragile one here. First, it should measure what actually arrived rather than trusting the amount it requested, because fee-charging and rebasing tokens deliver something else. Second, it should end the transaction holding nothing: real execution leaves residuals — partial fills at a price limit, rounding across split legs — and those must be returned to the caller rather than accumulating in a contract where a later transaction can sweep them.

## Stage 6 — Settlement guarantees: what is promised, and by whom

The last stage is the one users feel and rarely inspect. A displayed quote is not a promise; the enforceable promise is the minimum output the settling contract will accept. Where that minimum comes from matters enormously. If it is supplied by the caller, anyone who can widen it can widen it to nothing. If it is re-derived on-chain from the real trade at execution time, it is a property of the system rather than a parameter of the request.

This is also where a wide slippage tolerance stops being a safety margin and becomes a disclosure: a pending transaction publishes exactly how much value can be extracted before it stops settling. The tightest honest configuration is a quote that equals execution plus a floor derived at settlement — the displayed number is real, and the worst case is bounded rather than open.

## Reading any aggregator through the six stages

The framework is diagnostic. For any implementation, ask: does it discover new venues or only listed ones; does it separate price quality from capacity; is the number computed by the code that settles or by a server; is allocation depth-weighted or naive; does execution measure delivery or trust the request; and is the minimum output derived on-chain or accepted from the caller.

Six questions, each answerable by observation rather than by trust. Most of what looks like a difference in "which aggregator is better" is one of these six answers, and every one of them can be checked without asking anybody's permission.

**Verify it yourself:** Take any aggregator and answer the six questions by observation — request a quote with its hosted surfaces unreachable to test stage 3, and compare its displayed number against what the transaction actually delivered to test stage 6

Related: https://blazephoenix.xyz/learn/on-chain-quoting · https://blazephoenix.xyz/learn/capital-anchored-split · https://blazephoenix.xyz/learn/split-routing-convexity · https://blazephoenix.xyz/learn/web25-vs-web30