Miners process transactions and receive fees from users (supply-side fees).

Bitcoin is a distributed ledger for transfer and store of value (a blockchain). Bitcoin was founded by a pseudonym Satoshi Nakamoto and launched in 2009.

BTC holders own and govern the protocol. They currently do not take a cut of the total transaction fees paid by users (revenue).

github

block explorer

Blockchains (L1)

Bitcoin

# Bitcoin Active users (weekly) Methodology

## 1. Overview

Bitcoin Weekly Active Users (WAU) measures the number of unique addresses that sent Bitcoin transactions within any 7-day rolling period. This metric answers the question "How many distinct users actively used the Bitcoin network as transaction senders over the past week?" The calculation uses HyperLogLog (HLL) data structures to efficiently count unique addresses across rolling 7-day windows, providing breakdowns by different dimensions including project-level, chain-level, user-type-level, and product-level aggregations.

## 2. Data sources

The calculation relies on:
- **Bitcoin blockchain transaction records**: Complete transaction history including transaction IDs, block timestamps, and transaction metadata
- **Bitcoin transaction input data**: Transaction input references that specify previous transaction outputs being spent
- **Bitcoin transaction output data**: Transaction outputs containing recipient addresses and scriptPubKey information
- **Transaction timestamp data**: Block timestamps for temporal aggregation and windowing

## 3. Step-by-step calculation

### Component A: Input address resolution
- **Purpose**: Resolves Bitcoin transaction inputs to actual sender addresses by creating a lookup table
- **Logic**: Bitcoin transactions reference inputs by previous transaction hash and output index rather than directly specifying sender addresses. The system processes all Bitcoin transaction outputs to create a mapping table that links each output (identified by `transaction_hash` and `output_index`) to its recipient address. This lookup table enables resolving transaction inputs back to their originating sender addresses.
- **Key fields**: `transaction_hash`, `output_index`, `user_address`, `block_timestamp`

### Component B: Historical user identification  
- **Purpose**: Identifies unique daily users from historical Bitcoin transactions (before 2019-01-01)
- **Logic**: Processes Bitcoin transactions prior to January 1, 2019, extracting transaction inputs and using the address resolution lookup to identify sender addresses. Groups transactions by day and deduplicates user addresses to create daily unique sender counts for the historical period.
- **Key fields**: `timestamp` (daily), `user_address`

### Component C: Recent user identification
- **Purpose**: Identifies unique daily users from recent Bitcoin transactions (2019-01-01 onwards)  
- **Logic**: Processes Bitcoin transactions from January 1, 2019 forward, following the same input resolution and daily aggregation logic as historical data. Uses incremental processing to efficiently handle new transaction data as it becomes available.
- **Key fields**: `timestamp` (daily), `user_address`

### Component D: Daily active users consolidation
- **Purpose**: Combines historical and recent user data into a unified daily user dataset
- **Logic**: Unions the historical and recent user datasets, creating a complete daily time series of unique Bitcoin transaction senders. Each record represents a unique address that sent at least one transaction on a given day, classified as user type "Transaction sender" on the "bitcoin" chain.
- **Key fields**: `timestamp`, `user_dau` (user address), `timestamp_grain` (day), `chain` (bitcoin), `user_type`

### Component E: HyperLogLog conversion
- **Purpose**: Converts daily user lists to HLL data structures for efficient unique counting
- **Logic**: Takes the daily user data and initializes HyperLogLog sketches for each day, grouped by timestamp, chain, user type, and product dimensions. Uses HLL precision of 15 bits to balance accuracy and storage efficiency. This enables approximate but highly accurate unique user counting in subsequent aggregation steps.
- **Key fields**: `timestamp`, `hll` (HyperLogLog sketch), `chain_id`, `user_type`, `product_id`

### Component F: Rolling window creation
- **Purpose**: Creates 7-day rolling windows for each date to calculate weekly active users
- **Logic**: Generates a complete datespine covering the full time range, then creates join relationships where each date is associated with itself plus the previous 6 days (creating 7-day windows). Uses cross joins with timestamp arrays to ensure no missing days in the time series, enabling consistent rolling window calculations even when some days have no transaction activity.
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component G: Window aggregation  
- **Purpose**: Aggregates HLL sketches across 7-day rolling windows
- **Logic**: Joins the rolling window structure with daily HLL data, grouping by target timestamp and other dimensions. For each 7-day window, merges all HLL sketches from the constituent days to create a single HLL representing unique users across the entire week.
- **Key fields**: `timestamp`, `hll` (merged weekly HLL), dimensional grouping fields

### Final aggregation
- **Combining components**: Creates separate aggregations for different dimensional breakdowns - project-level (no dimensional splits), chain-level (by chain), user-type-level (by user type), and product-level (by product). Each breakdown merges HLL sketches appropriately and extracts the final unique count.
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily boundaries with 7-day rolling windows, where each day's WAU represents unique users active within that day plus the previous 6 days
- **Final calculation**: Extracts unique user counts from merged HLL sketches using `hll_count.extract()`, providing the final weekly active user count for each timestamp and dimensional combination. Results are unioned across all dimensional breakdowns and processed through the `finalize_metric_user_wau` macro to standardize schema and fill missing periods with zeros.

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

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

BitcoinBTC

Active users (weekly)

Active users (weekly)

Competitive landscape