Orderflow

​

Overview

The goal of the orderflow schema is to represent the path of a trading intent — from the frontend/contract origin, through the intermediaries, and to the liquidity sources in DEXs or Private Market Makers (PMMs). This model will allow users to explore:

• Where trades originate (e.g. 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)

​

Models

​

Methdology

​

Data Lineage

The orderflow schema is constructed from 2 base models:

• dex.trades: AMM swaps are emitted directly by liquidity pools.
• dex.aggregator_trades : Aggregator, intent-based protocols, and RFQs swaps that are executed via intermediaries like Odos, 1inch, or CoW Protocol solvers. They tap on liquidity sources from AMMs or private market makers (PMMs) and/or solvers to execute a swap.

We categorize swaps according to intermediary type across the dex.trades and dex.aggregator_trades models. Each trade is assigned a rank, reflecting its intermediary type, with lower values representing higher priority for classification.

​

Identifying Swap Intermediaries

For each individual swap entry, we parse the following intermediary fields based on the dex protocol. For example, in Kyberswap Aggregator swaps, there is a corresponding ClientData event that tells us the integrator and the most probable frontend source of the swap. For each transaction, we parse out the following field:

• Frontend — The initiating interface or wallet for the transaction
• Meta-Aggregator — The routing protocol that may orchestrate multiple aggregators
• Aggregator — The standard routing protocol executing swaps across liquidity sources
• Solver / Filler Address — Applicable for intent-based protocols to track solvers or fillers
• PMM Address — Market-making addresses involved in routed swaps

​

Constructing the Orderflow Model

Swap events from both dex.trades and dex.aggregator_trades are aggregated at the transaction level using the transaction_hash as the aggregation key into the dex.unhydrated_orderflow/_v2 model. When multiple intermediaries are involved, including meta-aggregators and standard aggregators, the intermediary with the highest priority—represented by the lowest assigned rank—is selected to classify the transaction. Regardless of whether a swap is classified as intent-based or routed through an aggregator, all underlying DEX liquidity pools are recorded in liquidity_details field to ensure complete traceability. The liquidity_details field aggregates all individual swaps from dex.trades into a structured record, capturing the underlying dex event details. For v4 Uniswap, the pool id is also included.

​

Frontend Labeling

Broadly, we use a combination of contract interactions and the integrator field in dex.aggregator_tradesto identify the most probably frontend/source of the swap. Contract Interaction Labeling Internally, we maintain a mapping of key telegram bots, MEV contracts, and aggregator routers which we use to label the transaction by the most probable frontend by the transaction’s to_address. Event Log Labeling In the event logs of aggregator/router transactions, the aggregator may emit fields which tell us where the swap source is executed from. This can be from the details of the swap referrals or the actual name of the frontend that was used.

• In OpenOcean’s event swap log, the referrer field indicates the fee recipient and frontend integrator where the swap was executed from.
  • In this swap, the referrer points to the Rabby Fee Wallet.
• In Kyberswap Aggregator’s client data event log, the hex-decoded data will tell us the source of the swap: {"Source":"dextools","AmountInUSD":"27.418064752878504","AmountOutUSD":"25.55357350955812","Referral":"...}

These fields are parsed and used to label the integratorfields in the dex.aggregator_tradesmodel, which is then used to label the frontend field in the dex.orderflow_liquidity_view model. When integrator-related fields are present, we will use that as the default frontend label, otherwise we will use the to_address to label the frontend.

​

Model Columns

Model: dex.orderflow_liquidity_view (New) The dex.orderflow_liquidity_view model is a flattend view of the dex.unhydrated_orderflow/_v2 model, where all the relevant swap details are compressed within a unit of transaction hash. The entiites (frontend, meta-aggregator, aggregator, solver, pmm) labels are normalized to their respective project names. In this mode, a swap that originates from 1 frontend and is routed to 3 liquidity sources will be represented as 3 rows in the model. Model: dex.orderflow (Legacy)