Mapping the Flow of DEX Swap Execution: Allium’s Orderflow Explorer
The Orderflow Explorer, built by Allium through a Uniswap Foundation grant, maps the complete path of every DEX swap across Ethereum, Arbitrum, Base, and Unichain. This post covers what the Orderflow Explorer does, how we built the underlying schema, and how we validated it.
Contributors: Soon Guan Tan (Data Analyst, Allium), Soo Hyung Choe (Data Analyst, Allium), Jackie Zhang (Head of Data Science, Uniswap Foundation)
Summary
When a user swaps on Ethereum, the transaction often passes through multiple intermediaries (wallets, meta-aggregators, solvers, aggregators) before reaching liquidity pools. Each layer serves a purpose, but the complexity has made it difficult for researchers and analysts to trace who facilitated the trade and where liquidity actually came from.
The Orderflow Explorer, built by Allium through a Uniswap Foundation grant, maps the complete path of every DEX swap across Ethereum, Arbitrum, Base, and Unichain. This post covers what the Orderflow Explorer does, how we built the underlying schema, and how we validated it.
What is the Orderflow Explorer?
This project offers a generalized model to map the flow of a swap execution, from its origin, through the intermediary routing systems like meta aggregators, aggregators, or solvers, to the decentralized exchanges’ liquidity pools and vaults that settle it. For every trade, users can see:
- Where trades originate: Wallets, dApps, bot contracts, interfaces
- How they are routed: Via aggregators, meta-aggregators, or intent-based systems
- Where liquidity is sourced: DEX protocols and pools that ultimately settle the swap
Coverage includes meta-aggregators, aggregators, solvers, private market makers (PMMs), AMM liquidity pools, and Uniswap v4 hooks.
How We Built It
Allium indexes raw blockchain data (blocks, logs, transactions, and traces) for EVM-compatible chains. From this, we decode DEX activity into two core abstractions:
These two models form the foundation for the data schema. From this dataset, we aim to identify the following entities that are involved:
Within a transaction, we classify each project and protocol from the dex.trades and dex.aggregator trades into one of the entities above based on the DEX mechanism (intent-based, meta-aggregator, simple aggregator, AMMs). We aggregate all entities involved in the transaction and use priority ranking and event order to decide which project takes precedence over the other.
What We Capture
The final schema captures five dimensions:
- Frontend: Origin & Integrators: Aggregators emit frontend data in their event logs (KyberSwap's ClientData, LiFi's integrator tags). We aggregate these signals and normalize raw identifiers to recognizable names.
- Meta-Aggregator & Aggregator: What protocol made the routing decisions? Meta-aggregator captures protocols coordinating across multiple aggregators. Aggregator captures standard routing when no meta-aggregator is present.
- Solvers & Market Makers: For intent-based protocols, the solver that won the batch auction (CoW) or filled the Dutch auction (Uniswap X). For RFQ systems, the PMM provides liquidity outside traditional pools.
- The Swapper: Usually the transaction initiator. For intent-based protocols where the sender might be a relayer, we extract the actual token owner using protocol-specific logic.
- Liquidity Details: Every underlying pool interaction: project, pool address, token pair, USD volume, log index, and Hook ID for Uniswap V4. This allows users to trace the pools or vaults utilised for each transaction.
How We Validated the Schema
DEX swaps range from simple single-pool trades to complex multi-layer routes. We profiled swap complexity by the number of distinct projects involved in each transaction:
For each swap type, we ran consistency checks:
Simple AMM Swaps: No meta-aggregator, aggregator, PMM, or integrator fields should be populated. Liquidity source should match the AMM project in dex.trades.
Aggregator Swaps: Aggregator fields must match dex.aggregator_trades. Liquidity sources must match AMM projects in dex.trades.
Meta-Aggregator Swaps: Validates routing from meta-aggregator → aggregator → AMM. Meta-aggregator field must match the project in dex.aggregator_trades.
Intent-Based Swaps: Validates routing from intent protocol → meta-aggregator → aggregator → AMM. Intent field must match the protocol in dex.aggregator_trades.
Each check is translated into SQL to verify the transformation layer.
Current limitations:
- Some protocols are not yet indexed (Bebop, LiquidMesh, MetaMask as aggregator, Angstrom V4; these are planned for Q1 2026).
- Frontend attribution relies on metadata that varies across aggregators, creating bias toward well-tagged frontends.
This schema is not static, but adapts as the DEX landscape evolves. We'll continue adding new protocols, routers, and solver frameworks as they appear on-chain, and welcome feedback from researchers using the data.
Explore the Data and Get in Touch
The Orderflow Explorer is live on DEX Analytics. Explore Orderflows →
Uniswap Foundation supports the growth and sustainability of the Uniswap protocol through grants, research, and ecosystem development.
Allium provides onchain data infrastructure for enterprises, ingesting raw data across 100+ chains and serving it via databases, datashares, and live APIs and data streams. Get in touch.
