Liquidity providers deposit funds into BMX and receive trading fees from traders (supply-side fees).

BMX is a non-custodial exchange for spot and perpetual contracts built on Base. BMX has three product lines: Classic, Freestyle, and Based MediaX

BMX tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

twitter

discord

website

github

Derivative exchanges

# BMX Trade count Methodology

## 1. Overview

Trade count is measured as the total number of trades executed on Deliswap. This metric is used to track the frequency of asset exchange activity and user engagement within the BMX ecosystem. By monitoring the volume of individual swap transactions, the overall liquidity and usage of the decentralized exchange are assessed.

## 2. Data sources

- **Blockchain events**: `HookSwap` events from `DeliHookConstantProduct` contracts, `Swap` and `Initialize` events from `PoolManager` contracts, and `FeeCollected` events from `FeeProcessor` contracts, covering Base.

## 3. Step-by-step calculation

### Component A: Deliswap AMM hook trade extraction

- **Purpose**: Identify trades executed through the Automated Market Maker (AMM) hook mechanism.
- **Logic**: `HookSwap` events are parsed from `DeliHookConstantProduct` contracts. These events represent swap operations specifically handled by the constant product hook. Data points including the transaction hash, pool identifier, and asset amounts are extracted for each event.
- **Key fields**: `transaction_hash`, `pool_address`, `amount`

### Component B: Deliswap V4 hook trade extraction

- **Purpose**: Identify trades executed through the Uniswap V4 hook mechanism.
- **Logic**: `Swap` events are parsed from `PoolManager` contracts. These events represent trades routed through the V4 hook architecture. Asset amounts are adjusted to reflect the trader's perspective, and transaction details are captured for further validation.
- **Key fields**: `transaction_hash`, `pool_address`, `amount`

### Component C: Trade validation and filtering

- **Purpose**: Ensure only valid user trades are included while excluding internal protocol operations.
- **Logic**: Extracted trade events from both AMM and V4 hooks are joined with `FeeCollected` events from `FeeProcessor` contracts. This join is performed using the transaction hash and pool identifier to ensure that only fee-generating trades are counted. This process effectively filters out internal protocol buybacks, where accumulated fees are automatically used to purchase BMX assets.
- **Key fields**: `transaction_hash`, `poolId`

### Component D: Pool metadata integration

- **Purpose**: Map trades to specific asset pairs and verify pool legitimacy.
- **Logic**: Validated trades are joined with pool metadata derived from `Initialize` events from `PoolManager` contracts. This step ensures that each trade is associated with the correct asset addresses for the respective pool.
- **Key fields**: `pool_address`, `token_address`

### Component E: Final aggregation

- **Purpose**: Calculate the total daily trade count.
- **Logic**: The number of unique transaction hashes is counted and aggregated on a daily basis. The results are grouped by chain and product identifier. A zero-filling strategy is applied to ensure continuity in the time series data.
- **Key fields**: `transaction_hash`, `block_timestamp`

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Number of trades executed on a decentralized exchange.

BMXBMX

Archived

Trade count

Trade count

Competitive landscape

Chain breakdown