> ## Documentation Index
> Fetch the complete documentation index at: https://tokenterminal.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Metrics

> Daily volume, TVL, fees and flash-loan volume per pool and per pair.

DEX metrics are two daily tables. `metrics.dex_pools_daily` holds one row per pool per day, with every pool measure. `metrics.dex_pool_pairs_daily` splits the same volume by traded pair: one row per pool per pair per day. Every figure is in USD, converted with our token prices at the finest level and added up from there.

* `metrics.dex_pools_daily`: one row per pool per day.
* `metrics.dex_pool_pairs_daily`: one row per pool per traded pair per day.

## Tables

<Tabs>
  <Tab title="Pool">
    One row per pool per day, keyed `(dex_pool_id, timestamp)`. The table carries `trading_volume`, `tvl`, `fees` and `flash_loan_volume`, alongside the keys for the app, the protocol version, the project and the chain.

    <table>
      <thead>
        <tr>
          <th width="200">Column</th>
          <th width="130">Type</th>
          <th>Description</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td><code>timestamp</code></td>
          <td><code>TIMESTAMP</code></td>
          <td>Day the row aggregates, truncated to UTC midnight.</td>
        </tr>

        <tr>
          <td><code>dex\_pool\_id</code></td>
          <td><code>STRING</code></td>
          <td>Pool the row measures, keyed like <code>dimensions.dex\_pools</code>.</td>
        </tr>

        <tr>
          <td><code>deployment\_id</code></td>
          <td><code>STRING</code></td>
          <td>The operating app's deployment on the pool's chain.</td>
        </tr>

        <tr>
          <td><code>protocol\_id</code></td>
          <td><code>STRING</code></td>
          <td>The app operating the pool.</td>
        </tr>

        <tr>
          <td><code>project\_id</code></td>
          <td><code>STRING</code></td>
          <td>Project the operating app belongs to.</td>
        </tr>

        <tr>
          <td><code>chain\_id</code></td>
          <td><code>STRING</code></td>
          <td>Chain the pool lives on.</td>
        </tr>

        <tr>
          <td><code>trading\_volume</code></td>
          <td><code>BIGNUMERIC</code></td>
          <td>USD value of the day's swaps in the pool.</td>
        </tr>

        <tr>
          <td><code>tvl</code></td>
          <td><code>BIGNUMERIC</code></td>
          <td>Total value locked: the USD value of what the pool was holding at the end of the day.</td>
        </tr>

        <tr>
          <td><code>fees</code></td>
          <td><code>BIGNUMERIC</code></td>
          <td>USD value of the day's swap and flash-loan fees.</td>
        </tr>

        <tr>
          <td><code>flash\_loan\_volume</code></td>
          <td><code>BIGNUMERIC</code></td>
          <td>USD value of the day's flash loans drawn from the pool.</td>
        </tr>
      </tbody>
    </table>
  </Tab>

  <Tab title="Pair">
    One row per pool per traded pair per day, keyed `(dex_pool_id, dex_pair_id, timestamp)`. `dex_pair_id` is the two token addresses in sorted order joined with the chain, so the pair's two tokens are readable from the key itself and need no columns of their own.

    <table>
      <thead>
        <tr>
          <th width="200">Column</th>
          <th width="130">Type</th>
          <th>Description</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td><code>timestamp</code></td>
          <td><code>TIMESTAMP</code></td>
          <td>Day the row aggregates, truncated to UTC midnight.</td>
        </tr>

        <tr>
          <td><code>dex\_pool\_id</code></td>
          <td><code>STRING</code></td>
          <td>Pool the volume executed in.</td>
        </tr>

        <tr>
          <td><code>dex\_pair\_id</code></td>
          <td><code>STRING</code></td>
          <td>The two tokens that traded: their addresses in sorted order, joined with the chain.</td>
        </tr>

        <tr>
          <td><code>project\_id</code></td>
          <td><code>STRING</code></td>
          <td>Project the operating app belongs to.</td>
        </tr>

        <tr>
          <td><code>app\_id</code></td>
          <td><code>STRING</code></td>
          <td>The app operating the pool, read from the pool registry table.</td>
        </tr>

        <tr>
          <td><code>chain\_id</code></td>
          <td><code>STRING</code></td>
          <td>Chain the pool lives on.</td>
        </tr>

        <tr>
          <td><code>trading\_volume</code></td>
          <td><code>BIGNUMERIC</code></td>
          <td>USD value of the day's swaps in this pool between this pair.</td>
        </tr>
      </tbody>
    </table>
  </Tab>
</Tabs>

## Sample queries

<Tabs>
  <Tab title="One pool's series">
    **Read one pool's daily series.**

    ```sql theme={null}
    select
        timestamp,
        trading_volume,
        tvl,
        fees,
        flash_loan_volume
    from `metrics.dex_pools_daily`
    where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum'
      and timestamp >= timestamp('2026-06-01')
    order by timestamp
    ```

    `fees` is worked out from the same volume figure as `trading_volume`, so dividing one by the other gives back the pool's fee rate. It is not a second, independent measurement of what traders paid. Pool rows add up cleanly to the app's deployment on that chain, then the protocol version, then the project, because every level uses the same token prices.
  </Tab>

  <Tab title="Pools by volume">
    **Rank pools by trading volume on one day.**

    ```sql theme={null}
    select
        dex_pool_id,
        protocol_id,
        chain_id,
        trading_volume,
        tvl,
        fees
    from `metrics.dex_pools_daily`
    where timestamp = timestamp('2026-08-01')
      and trading_volume is not null
    order by trading_volume desc
    limit 25
    ```
  </Tab>

  <Tab title="Pair total across pools">
    **Total one pair's volume across every pool that trades it.** The same pair can trade in many pools, and it carries the same `dex_pair_id` in all of them, so a total across pools is a group by on that column.

    ```sql theme={null}
    select
        timestamp,
        sum(trading_volume) as trading_volume
    from `metrics.dex_pool_pairs_daily`
    where dex_pair_id = '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2-ethereum'
      and timestamp >= timestamp('2026-08-01')
    group by timestamp
    order by timestamp
    ```
  </Tab>

  <Tab title="Pool by pair breakdown">
    **Break one pool's volume down by pair.** A pool's pair rows add back up to its row on the pool table. A breakdown by single token would not: every swap involves two tokens, so counting it under each one counts it twice and the total stops matching the pool.

    ```sql theme={null}
    select
        dex_pair_id,
        sum(trading_volume) as trading_volume
    from `metrics.dex_pool_pairs_daily`
    where dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum'
      and timestamp >= timestamp('2026-08-01')
      and timestamp < timestamp('2026-08-08')
    group by dex_pair_id
    order by trading_volume desc
    ```
  </Tab>

  <Tab title="Sector total">
    **Sum the exchange sector's daily volume and fees.** There is no table holding the DEX sector as a single daily series: this groups the daily pool table, joined to `dimensions.projects`, by day. Check membership with `in unnest(...)` as below, or filter on `primary_market_sector`, where every project appears exactly once; grouping by the raw `market_sectors` list with `unnest` in the from clause counts a project once per sector it carries.

    ```sql theme={null}
    select
        panel.timestamp,
        sum(panel.trading_volume) as sector_volume,
        sum(panel.fees) as sector_fees
    from `metrics.dex_pools_daily` as panel
    join `dimensions.projects` as projects
        on projects.project_id = panel.project_id
    where 'exchange' in unnest(projects.market_sectors)
      and panel.timestamp >= timestamp('2026-08-01')
    group by panel.timestamp
    order by panel.timestamp
    ```
  </Tab>

  <Tab title="Pool vs pair check">
    **Check a pool's volume against the sum of its pairs.** The pool row is the sum of its pair rows rather than a second, separate measurement, so on any day the pool traded the two sides agree exactly.

    ```sql theme={null}
    select
        pools.timestamp,
        pools.trading_volume as pool_grain,
        pairs.summed as pair_grain
    from `metrics.dex_pools_daily` as pools
    join (
        select
            dex_pool_id,
            timestamp,
            sum(trading_volume) as summed
        from `metrics.dex_pool_pairs_daily`
        where timestamp >= timestamp('2026-08-01')
        group by dex_pool_id, timestamp
    ) as pairs
        using (dex_pool_id, timestamp)
    where pools.dex_pool_id = '0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640-ethereum'
      and pools.timestamp >= timestamp('2026-08-01')
    order by pools.timestamp
    ```
  </Tab>
</Tabs>

## Notes

Amounts add up: volume, fees and flash-loan volume are dollar figures, so a total across pools or days means something. Counts of distinct traders do not. One address that traded in five pools is one trader, but adding those five pools' daily counts makes it five. A trader count for anything wider than one pool on one day has to be worked out from the addresses themselves.