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

Bancor is a non-custodial exchange protocol built on Ethereum. Bancor was founded by Galia Benartzi, Guy Benartzi, Eyal Hertzog, & Yudi Levi and launched in 2016.

BNT tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). Bancor's investors include DeFiance Capital, ParaFi Capital, Mechanism Capital, etc.

governance

github

twitter

discord

etherscan

website

Exchanges (DEX)

Bancor

# Bancor Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Bancor measures the number of unique addresses that performed trades on the Bancor protocol within any 30-day rolling period. This metric provides insight into user engagement and protocol adoption by tracking trading activity across different time windows. The calculation uses HyperLogLog sketches to efficiently count unique users over rolling 30-day periods, providing multiple dimensional breakdowns including project-level, chain-level, user type, and product ID perspectives.

## 2. Data sources

The calculation relies on these underlying data sources:
- **Bancor trading events**: Parsed `BancorNetwork_TokensTraded` events from Bancor v2.1 and `Converter_Conversion` events from Bancor v3 on Ethereum
- **Ethereum transaction records**: Transaction data containing user addresses and execution details
- **Chain availability metadata**: Configuration data defining which chains are supported for analysis

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Extracts and standardizes trading events from Bancor protocol versions
- **Logic**: Processes parsed trading events from two Bancor versions (v2.1 and v3) on Ethereum. For v2.1, uses `BancorNetwork_TokensTraded` events containing `sourceToken`, `targetToken`, `sourceAmount`, `targetAmount`, and `targetFeeAmount` fields. For v3, uses `Converter_Conversion` events with `_fromToken`, `_toToken`, `amount`, `return`, and `conversionFee` fields. Standardizes native ETH token identifiers (`0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee`) to WETH addresses (`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`) for consistency. Joins trading events with Ethereum transaction records to extract the actual user address from the `from_address` field rather than using contract addresses. Filters data to include only trades from June 16, 2020 onwards. Classifies all activity under 'DEX Aggregator' business line and 'exchanges' market sector.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for uniqueness, `user_address` for user identification, `chain` for blockchain identification

### Component B: Daily active user aggregation  
- **Purpose**: Counts unique trading users per day and converts to HyperLogLog sketches
- **Logic**: Aggregates the trade events to identify unique user addresses per day using `timestamp_trunc` on `block_timestamp` to day granularity. Groups users by day, chain, user type (all classified as 'Trader'), market sector, business segment, and product ID. Applies chain availability filtering to ensure only supported chains are included. Converts daily user counts into HyperLogLog sketches for memory-efficient aggregation in subsequent steps.
- **Key fields**: `timestamp` (daily), `chain`, `user_type`, `product_id`, `user_dau` (unique user address)

### Component C: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for MAU calculation using a datespine approach
- **Logic**: Generates a complete datespine covering all days from the earliest trade date to the current date to ensure no missing timestamps in the rolling window calculation. For each day in the datespine, creates a 30-day lookback period using `generate_timestamp_array` with 29 days prior to the current day plus the current day itself. Joins this window structure with the daily HyperLogLog sketches from Component B to populate each rolling window with the relevant daily user data.
- **Key fields**: `timestamp` (target date), `joinday` (days within the 30-day window), `hll` (HyperLogLog sketch for each day)

### Component D: Multi-dimensional MAU calculation
- **Purpose**: Calculates MAU across different dimensional breakdowns
- **Logic**: Merges HyperLogLog sketches across each 30-day period using `hll_count.merge_partial` to combine daily user sets, then extracts the final unique count using `hll_count.extract`. Creates four separate dimensional views: project-level aggregation (all dimensions collapsed), chain-level breakdown (grouped by `chain_id`), user type breakdown (grouped by `user_type`), and product ID breakdown (grouped by `product_id`). Each breakdown sets non-applicable dimension fields to null while preserving the relevant grouping dimension.
- **Key fields**: `timestamp`, `timestamp_grain`, `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_mau` (final unique user count)

### Final aggregation
- **Combining components**: Unions all four dimensional breakdowns (project-level, chain-level, user type, and product ID) into a single result set using `union all` operations
- **Time aggregation**: Uses daily timestamps as the basis for 30-day rolling calculations, with each day representing the end date of a rolling 30-day period
- **Final calculation**: The `user_mau` field contains the exact count of unique users who traded within the 30-day period ending on each timestamp, calculated by merging and extracting HyperLogLog sketches that efficiently handle user deduplication across the rolling window
- **Schema standardization**: Applies the `finalize_metric_user_mau` macro with 'bancor' data ID and 'fill_zeros' strategy to standardize the output schema and fill any missing periods with zero values

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

Unique revenue-generating users over a rolling 30-day window.

BancorBNT

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown