A generalized swap flow model mapping trade execution from origin, through intermediary routing systems, to the liquidity pools that settle it.
| Blockchains | Projects | Protocols | Tables |
|---|---|---|---|
arbitrum ethereum base unichain | Protocols supported in dex.trades and dex.aggregator_trades | Protocols supported in dex.trades and dex.aggregator_trades | ethereum.dex.orderflow_liquidity_view base.dex.orderflow_liquidity_view unichain.dex.orderflow_liquidity_view arbitrum.dex.orderflow_liquidity_view |
Overview
When a user executes a swap, the transaction often involves multiple layers of intermediaries before reaching the actual liquidity pools. A user might interact with a wallet like Rabby, which routes through LiFi, which uses 1inch, which finally pulls liquidity from Uniswap and Curve pools. Each layer serves a purpose—optimizing routes, aggregating liquidity, or providing user-friendly interfaces—but this complexity makes it challenging to understand who facilitated the trade and where the actual liquidity came from.
This model creates a generalized swap flow mapping trade execution from origin, through intermediary routing systems, to the liquidity pools that settle it. It allows users to understand:
- 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)
Key Entities
| Entity | Role | Examples |
|---|---|---|
| Frontend | User-facing interface that collects swap intent and submits transactions | Uniswap UI, MetaMask Swaps, Rainbow Wallet |
| Meta-Aggregator | Routes swaps across multiple aggregators; includes intent-based protocols | CoW Protocol, LiFi, KyberSwap |
| Aggregator | Optimizes trade execution across multiple DEX pools and liquidity sources | 1inch, OpenOcean, Paraswap |
| Liquidity Source | Pools or venues providing actual token liquidity for swaps | Uniswap V2/V3/V4, Curve, Balancer |
| PMM | Off-chain liquidity providers offering RFQ prices for large trades | Wintermute, Flowdesk |
| Solvers | Agents that determine optimal execution; can batch or net trades | CoW Protocol solvers, UniswapX fillers |
Data Sources
The orderflow schema is constructed by combining two core Allium tables:
| Table | What it Represents | Examples |
|---|---|---|
dex.trades |
AMM swaps emitted directly by liquidity pools, reflecting raw on-chain execution | Uniswap V2/V3/V4 pools, Curve pools, Balancer vaults |
dex.aggregator_trades |
Swaps routed through intermediaries (aggregators, intent-based protocols, RFQ systems) | 1inch, Odos, CoW Protocol, Uniswap X |
Methodology
Stage 1: Protocol Classification
We classify all DEX protocols into tiers based on their role in the execution mechanism:
| Priority | Category | Examples | Function |
|---|---|---|---|
| 1 | Intent-Based | CoW Protocol, Uniswap X, 0x Settler | Batch auctions and solver competitions |
| 2 | Meta-Aggregators | Bungee, LiFi, Kyber Aggregator v2 | Orchestrate multiple aggregators |
| 3 | Standard Aggregators | 1inch, Paraswap, OpenOcean, Odos | Route across liquidity sources |
| 4 | AMM / Vault Swaps | Uniswap, Curve, Balancer, Aerodrome | Actual liquidity pools |
Intent-based protocols receive highest priority because they use a fundamentally different execution model—relying on solvers or batch auctions rather than deterministic routing.
Stage 2: Transaction Origin Labeling
Most transactions don't explicitly encode which wallet or frontend the user employed. We infer origins from event logs and contract interactions:
| Protocol Type | Origin Attribution Method |
|---|---|
| Intent-based | Project name assigned if to_address matches the contract |
| Meta-aggregators | KyberSwap ClientData, LiFi integrator tags, Bungee routeName |
| Standard aggregators | 0x affiliate addresses, OpenOcean referrer, Paraswap partner, Odos referralCode |
| Fallback | Label the to_address contract from Allium's registry |
Stage 3: Conflict Resolution & Aggregation
Once each swap event is categorized, we aggregate at the transaction level using transaction_hash as the key. When multiple protocols appear in a single transaction, we apply:
- Priority ranking — Lowest rank number wins (Intent > Meta-Aggregator > Aggregator > AMM)
- Chronological order — Lowest
log_indexbreaks ties between same-priority protocols
The result is one row per transaction with: origin, meta_aggregator, aggregator, solver_address, pmm_address, and a liquidity_details array containing all AMM pools accessed.
Stage 4: Liquidity View Flattening
The orderflow_liquidity_view explodes the liquidity_details array into one row per liquidity source. If a swap splits across 4 AMM pools, it creates 4 rows—enabling Sankey chart visualization and queries like:
- "Which AMM pools does LiFi route through most frequently?"
- "What percentage of CoW Protocol swaps use Uniswap V3 vs V4?"
- "Which solvers access which PMMs?"
Key Output Fields
| Field | Description |
|---|---|
origin |
Frontend/wallet that initiated the swap (e.g., MetaMask, Jumper, DexTools) |
meta_aggregator |
Intent-based or meta-aggregator protocol (e.g., cow_protocol, lifi) |
aggregator |
Standard aggregator if no meta-aggregator present (e.g., 1inch, paraswap) |
solver_address |
Solver/filler address for intent-based protocols |
pmm_address |
Private market maker address for RFQ fills |
liquidity |
Normalized liquidity source name (e.g., Uniswap V3, Curve) |
liquidity_pool_address |
Pool contract address |
pair |
Trading pair identifier (e.g., WETH-USDC) |
usd_amount |
USD volume routed through this specific liquidity source |
usd_volume |
Largest single swap leg (approximates user's trade size) |
total_usd_volume |
Sum of all swap volumes including intermediate hops |
v4_id |
Uniswap V4 hook identifier (pool ID with hooks) |
Data Labels
| Entity | Labeling Approach | Source |
|---|---|---|
| Origin | Integrator fields from aggregators, or to_address contract labeling |
Allium internal repository + block explorers |
| PMMs & Solvers | Identified by addresses | Flashbots Maker List + public sources |
| Liquidity Source | DEX project from dex.trades |
Project field |
| Uniswap V4 Hooks | Hook ID and associated contract | Uniswap Foundation |
Limitations
Priority-Based Selection Sacrifices Nuance: When a transaction involves multiple routing layers, we collapse this complexity into a single representative intermediary at each tier. The meta-aggregator gets attribution even if understanding full routing requires knowing downstream aggregators.
Frontend Attribution Depends on Inconsistent Metadata: Integrator tags are incomplete across some aggregators. Some trades default to protocol level, underrepresenting smaller or less well-integrated frontends.
Ongoing Maintenance Required: DeFi infrastructure evolves constantly. Contract registries, event decoding, and classification rules require periodic updates as protocols deploy new versions.