Liquidity providers deposit funds into Buffer Finance and receive trading fees from binary options traders (supply-side fees).

Buffer Finance is a non-custodial binary options exchange built on Arbitrum and Polygon. Buffer Finance was founded by an anonymous team and launched in 2021.

BFR token holders own and govern the protocol. They currently take a cut of the total trading fees paid by binary options traders (revenue).

github

twitter

discord

etherscan

website

Derivative exchanges

Buffer Finance

# Buffer Finance Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Buffer Finance measures the distinct number of unique users who traded binary options on the platform within any 30-day rolling window. This metric tracks user engagement in Buffer Finance's derivatives trading protocol, specifically focusing on option traders who create new positions. The calculation uses HyperLogLog data structures to efficiently count distinct users across overlapping time periods without double-counting users who were active on multiple days within the same month.

## 2. Data sources

- **Arbitrum blockchain event logs**: Parsed `Create` events from Buffer Finance binary options contracts, including USDC, ARB, and BFR denominated options pools
- **Polygon blockchain event logs**: Parsed `Create` events from Buffer Finance binary options contracts
- **Transaction data**: Block timestamps and transaction hashes for temporal aggregation and data integrity
- **Contract event logs**: Specific events from multiple Buffer Finance options pool contracts (numbered pools 1-22 for USDC, 1-18 for Polygon, 1-10 for BFR, etc.)

## 3. Step-by-step calculation

### Component A: User identification from trading events
- **Purpose**: Identifies unique users who create binary options positions on Buffer Finance
- **Logic**: Extracts user addresses from `Create` events emitted by Buffer Finance binary options contracts across Arbitrum and Polygon chains. Each `Create` event represents a user opening a new options position. Users are identified from the `account` parameter in these events and classified as 'Option Trader' user type. The system processes events from multiple contract versions including USDC-denominated options pools (numbered 1-22), ARB-denominated pools (numbered 1-18), BFR-denominated pools (numbered 1-10), and POL-denominated pools (numbered 1-4). All activity is categorized under the derivatives market sector with option business segment classification.
- **Key fields**: `account` (user address), `block_timestamp` (event timing), `transaction_hash` (unique transaction identifier), `chain` (blockchain network)

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates unique users per day across different dimensions
- **Logic**: Groups the identified trading events by day using timestamp truncation to daily granularity. Creates distinct user counts per day while maintaining dimensional breakdowns by chain, user type, market sector, business segment, and product ID. Each unique user address is counted once per day regardless of how many options positions they created on that day. The aggregation preserves chain-level distinctions between Arbitrum and Polygon activity.
- **Key fields**: `timestamp` (daily truncated), `user_address` (unique identifier), `chain` (network), `user_type` (classification), `product_id` (product categorization)

### Component C: 30-day rolling window construction
- **Purpose**: Creates overlapping 30-day periods for MAU calculation
- **Logic**: Generates a complete datespine covering all days from the earliest trading activity to the current date. For each date in the spine, creates a 30-day lookback window including the current day plus the previous 29 days. Uses cross-join logic to associate each calendar date with all relevant historical dates in its 30-day window. This approach ensures no missing dates and provides complete coverage for rolling MAU calculations even when there were no trading activities on specific days.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within the 30-day window)

### Component D: HyperLogLog aggregation for distinct counting
- **Purpose**: Efficiently counts distinct users across 30-day windows using probabilistic data structures
- **Logic**: Converts daily user lists into HyperLogLog (HLL) sketches with 15-bit precision for memory-efficient distinct user counting. For each day's data, initializes HLL sketches containing that day's unique users. Then merges HLL sketches across all days within each 30-day window to count distinct users without double-counting individuals who were active on multiple days. This probabilistic approach provides accurate distinct counts while handling large user sets efficiently.
- **Key fields**: `hll` (HyperLogLog sketch), `user_mau` (extracted distinct count)

### Component E: Multi-dimensional breakdown
- **Purpose**: Calculates MAU across different analytical dimensions
- **Logic**: Creates separate MAU calculations for four different dimensional breakdowns: project-level (overall Buffer Finance MAU), chain-level (Arbitrum vs Polygon), user-type-level (Option Trader segmentation), and product-level (different options products). Each breakdown merges the appropriate HLL sketches and extracts final distinct user counts. Non-relevant dimension fields are set to null for each breakdown to maintain consistent schema structure.
- **Key fields**: `dimensions` (breakdown type), `chain_id` (for chain breakdown), `user_type` (for user type breakdown), `product_id` (for product breakdown)

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single result set with consistent schema structure, allowing for flexible analytical queries across different grouping levels
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily grain timestamps with 30-day rolling windows, partitioned by month for efficient incremental processing
- **Final calculation**: Applies the `finalize_metric_user_mau` macro to standardize output schema, add metadata fields, and fill missing periods with zero values to ensure complete time series coverage

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

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

Buffer FinanceBFR

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown