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 (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique users who traded binary options on Buffer Finance within any 7-day rolling window. This metric answers the business question: "How many distinct users are actively trading options on Buffer Finance each week?" The calculation uses HyperLogLog probabilistic counting to efficiently handle large-scale user deduplication across multiple contract versions and blockchain networks, providing WAU breakdowns by project, chain, user type, and product dimensions.

## 2. Data sources

The calculation relies on these underlying data sources:

- **Blockchain events**: Parsed `Create` events from Buffer Finance binary options trading contracts across Arbitrum and Polygon networks
- **Contract events**: Events from multiple contract versions including USDC binary options (versions 1-22), ARB binary options (versions 1-18), BFR binary options (versions 1-10), and polygon binary options (versions 1-18)
- **Transaction data**: Arbitrum and Polygon transaction records containing block timestamps and transaction hashes for event context
- **External data**: Chain availability configuration data to ensure data quality across supported networks
- **Metadata**: Table modification timestamps for incremental processing optimization

## 3. Step-by-step calculation

### Component A: Raw user activity extraction
- **Purpose**: Identifies all users who created binary options positions on Buffer Finance
- **Logic**: Extracts user addresses from `Create` events emitted by Buffer Finance binary options contracts across Arbitrum and Polygon. The events are collected from multiple contract versions covering different asset types (USDC, ARB, BFR tokens) and different trading pools. Each event contains an `account` parameter that identifies the user creating the option position. All users are classified as 'Option Trader' user type since Buffer Finance focuses solely on binary options trading. Additional metadata includes chain identification, market sector ('derivatives'), and business segment ('option').
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for uniqueness, `account` as user identifier, `chain` for network classification

### Component B: Daily active users aggregation
- **Purpose**: Calculates daily unique user counts using probabilistic data structures for efficiency
- **Logic**: Aggregates the raw user activity by truncating timestamps to daily boundaries and collecting unique user addresses per day. Uses HyperLogLog sketches with 15-bit precision to efficiently handle large-scale user deduplication without storing individual user addresses. The aggregation maintains dimensional attributes including chain, user type, and product identifiers for downstream breakdowns. Chain availability filters are applied to ensure data quality across supported networks.
- **Key fields**: `timestamp` (daily truncated), `timestamp_grain` ('day'), `chain`, `user_type`, `product_id`, `user_dau` (HyperLogLog sketch)

### Component C: Rolling window construction
- **Purpose**: Creates 7-day rolling windows for each day to calculate weekly active users
- **Logic**: Generates a complete datespine covering all days from the earliest available data to yesterday to ensure no missing timestamps. For each day in the datespine, creates a 7-day rolling window by joining with the previous 6 days using timestamp arrays. This approach ensures that every day has a complete 7-day lookback window for WAU calculation, even when some days have no activity. The window construction uses inner joins to connect each day with its corresponding daily HyperLogLog sketches.
- **Key fields**: `timestamp` (window end date), `joinday` (constituent days within window), `hll` (daily HyperLogLog sketches)

### Component D: Weekly active users calculation
- **Purpose**: Computes unique user counts across 7-day windows using HyperLogLog merging
- **Logic**: For each 7-day window, merges the HyperLogLog sketches from all constituent days to calculate the total unique users who were active at least once during that week. This approach handles user deduplication across multiple days efficiently without needing to store or process individual user addresses. The calculation maintains all dimensional attributes (chain, user type, product) for downstream breakdowns.
- **Key fields**: `timestamp` (window end date), `hll` (merged HyperLogLog sketch), dimensional attributes

### Component E: Dimensional breakdowns
- **Purpose**: Provides WAU metrics across different business dimensions for analysis flexibility
- **Logic**: Creates four separate dimensional views of the WAU data: project-level (aggregating all users regardless of chain or product), chain-level (separate counts for Arbitrum and Polygon), user-type-level (currently all 'Option Trader'), and product-level (currently null but structured for future products). Each breakdown uses HyperLogLog merging to aggregate across the non-relevant dimensions while preserving the target dimension. Non-applicable dimension fields are set to null using SAFE_CAST.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_wau` (final count)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analytical perspectives in a single table
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily timestamp boundaries with 7-day rolling windows, ensuring each day represents the count of unique users active in that day plus the previous 6 days
- **Final calculation**: Applies the `finalize_metric_user_wau` macro with zero-filling strategy to ensure continuous time series data and proper schema formatting for downstream consumption. Incremental processing uses a 29+ day lookback buffer to ensure data completeness and handle late-arriving events.

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

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

Buffer FinanceBFR

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown