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

<table> <thead> <tr> <th>Entity</th> <th>Role</th> <th>Examples</th> </tr> </thead> <tbody> <tr> <td><strong>Frontend</strong></td> <td>User-facing interface that collects swap intent and submits transactions</td> <td>Uniswap UI, MetaMask Swaps, Rainbow Wallet</td> </tr> <tr> <td><strong>Meta-Aggregator</strong></td> <td>Routes swaps across multiple aggregators; includes intent-based protocols</td> <td>CoW Protocol, LiFi, KyberSwap</td> </tr> <tr> <td><strong>Aggregator</strong></td> <td>Optimizes trade execution across multiple DEX pools and liquidity sources</td> <td>1inch, OpenOcean, Paraswap</td> </tr> <tr> <td><strong>Liquidity Source</strong></td> <td>Pools or venues providing actual token liquidity for swaps</td> <td>Uniswap V2/V3/V4, Curve, Balancer</td> </tr> <tr> <td><strong>PMM</strong></td> <td>Off-chain liquidity providers offering RFQ prices for large trades</td> <td>Wintermute, Flowdesk</td> </tr> <tr> <td><strong>Solvers</strong></td> <td>Agents that determine optimal execution; can batch or net trades</td> <td>CoW Protocol solvers, UniswapX fillers</td> </tr> </tbody> </table>

---

Data Sources

The orderflow schema is constructed by combining two core Allium tables:

<table> <thead> <tr> <th>Table</th> <th>What it Represents</th> <th>Examples</th> </tr> </thead> <tbody> <tr> <td><code>dex.trades</code></td> <td>AMM swaps emitted directly by liquidity pools, reflecting raw on-chain execution</td> <td>Uniswap V2/V3/V4 pools, Curve pools, Balancer vaults</td> </tr> <tr> <td><code>dex.aggregator_trades</code></td> <td>Swaps routed through intermediaries (aggregators, intent-based protocols, RFQ systems)</td> <td>1inch, Odos, CoW Protocol, Uniswap X</td> </tr> </tbody> </table>

---

Methodology

Stage 1: Protocol Classification

We classify all DEX protocols into tiers based on their role in the execution mechanism:

<table> <thead> <tr> <th>Priority</th> <th>Category</th> <th>Examples</th> <th>Function</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Intent-Based</td> <td>CoW Protocol, Uniswap X, 0x Settler</td> <td>Batch auctions and solver competitions</td> </tr> <tr> <td>2</td> <td>Meta-Aggregators</td> <td>Bungee, LiFi, Kyber Aggregator v2</td> <td>Orchestrate multiple aggregators</td> </tr> <tr> <td>3</td> <td>Standard Aggregators</td> <td>1inch, Paraswap, OpenOcean, Odos</td> <td>Route across liquidity sources</td> </tr> <tr> <td>4</td> <td>AMM / Vault Swaps</td> <td>Uniswap, Curve, Balancer, Aerodrome</td> <td>Actual liquidity pools</td> </tr> </tbody> </table>

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:

<table> <thead> <tr> <th>Protocol Type</th> <th>Origin Attribution Method</th> </tr> </thead> <tbody> <tr> <td>Intent-based</td> <td>Project name assigned if <code>to_address</code> matches the contract</td> </tr> <tr> <td>Meta-aggregators</td> <td>KyberSwap <code>ClientData</code>, LiFi <code>integrator</code> tags, Bungee <code>routeName</code></td> </tr> <tr> <td>Standard aggregators</td> <td>0x affiliate addresses, OpenOcean <code>referrer</code>, Paraswap <code>partner</code>, Odos <code>referralCode</code></td> </tr> <tr> <td>Fallback</td> <td>Label the <code>to_address</code> contract from Allium's registry</td> </tr> </tbody> </table>

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:

1. Priority ranking — Lowest rank number wins (Intent > Meta-Aggregator > Aggregator > AMM)
2. Chronological order — Lowest log_index breaks 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

<table> <thead> <tr> <th>Field</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td><code>origin</code></td> <td>Frontend/wallet that initiated the swap (e.g., MetaMask, Jumper, DexTools)</td> </tr> <tr> <td><code>meta_aggregator</code></td> <td>Intent-based or meta-aggregator protocol (e.g., cow_protocol, lifi)</td> </tr> <tr> <td><code>aggregator</code></td> <td>Standard aggregator if no meta-aggregator present (e.g., 1inch, paraswap)</td> </tr> <tr> <td><code>solver_address</code></td> <td>Solver/filler address for intent-based protocols</td> </tr> <tr> <td><code>pmm_address</code></td> <td>Private market maker address for RFQ fills</td> </tr> <tr> <td><code>liquidity</code></td> <td>Normalized liquidity source name (e.g., Uniswap V3, Curve)</td> </tr> <tr> <td><code>liquidity_pool_address</code></td> <td>Pool contract address</td> </tr> <tr> <td><code>pair</code></td> <td>Trading pair identifier (e.g., WETH-USDC)</td> </tr> <tr> <td><code>usd_amount</code></td> <td>USD volume routed through this specific liquidity source</td> </tr> <tr> <td><code>usd_volume</code></td> <td>Largest single swap leg (approximates user's trade size)</td> </tr> <tr> <td><code>total_usd_volume</code></td> <td>Sum of all swap volumes including intermediate hops</td> </tr> <tr> <td><code>v4_id</code></td> <td>Uniswap V4 hook identifier (pool ID with hooks)</td> </tr> </tbody> </table>

---

Data Labels

<table> <thead> <tr> <th>Entity</th> <th>Labeling Approach</th> <th>Source</th> </tr> </thead> <tbody> <tr> <td><strong>Origin</strong></td> <td>Integrator fields from aggregators, or <code>to_address</code> contract labeling</td> <td>Allium internal repository + block explorers</td> </tr> <tr> <td><strong>PMMs & Solvers</strong></td> <td>Identified by addresses</td> <td><a href="https://dune.com/queries/2812729">Flashbots Maker List</a> + public sources</td> </tr> <tr> <td><strong>Liquidity Source</strong></td> <td>DEX project from <code>dex.trades</code></td> <td>Project field</td> </tr> <tr> <td><strong>Uniswap V4 Hooks</strong></td> <td>Hook ID and associated contract</td> <td><a href="https://dune.com/queries/5293618/8688090">Uniswap Foundation</a></td> </tr> </tbody> </table>

---

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.