Tornado Cash uses smart contracts that accept ETH & other token deposits from one address and enables their withdrawal from a different address. To preserve privacy a relayer can be used to withdraw to an address with no ETH balance.

Tornado Cash is a fully decentralized non-custodial protocol allowing private transactions on Ethereum and other adjacent blockchains. Tornado Cash was co-founded by Roman Semenov in 2019.

TORN token holders own and govern the protocol. They currently take a cut of the total withdrawal fees paid (revenue).

github

etherscan

Infrastructure

Tornado Cash

# Tornado Cash Active users (weekly) Methodology

## 1. Overview

The TornadoCash Weekly Active Users (WAU) metric measures the number of unique users who performed withdrawal transactions from TornadoCash mixing pools within a rolling 7-day period. This metric helps track user engagement with the privacy protocol by identifying distinct addresses that withdrew funds from various token pools across supported blockchains. The calculation uses HyperLogLog probabilistic data structures to efficiently compute distinct user counts across large datasets while maintaining accuracy.

## 2. Data sources

- **TornadoCash withdrawal events**: Parsed `Withdrawal` event logs from TornadoCash smart contracts across Ethereum, Arbitrum, Avalanche, BSC, Gnosis, Optimism, and Polygon networks
- **Token pool events**: Withdrawal events from various denomination pools including ETH (0.1, 1, 10, 100), DAI (100, 1000, 10000, 100000), USDC (100, 1000), USDT (100, 1000), WBTC (0.1, 1), BNB (0.1, 1, 10, 100), AVAX (10, 100, 500), MATIC (100, 1000, 10000, 100000), and XDAI (100, 1000, 10000, 100000)
- **Blockchain transaction metadata**: Block timestamps and transaction hashes from the underlying blockchain networks
- **Chain availability configuration**: Protocol deployment and operational status data for cross-chain reporting

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Identifies unique user addresses from TornadoCash withdrawal activities across all supported chains and token pools
- **Logic**: Extracts user addresses from parsed `Withdrawal` events across multiple TornadoCash token pools on seven blockchain networks. For each withdrawal event, captures the recipient address from the `to` parameter field, which represents the user receiving the mixed funds. Standardizes the data by adding chain identification, setting user type as 'Transactor', and preserving block timestamps. Includes events from various token denominations across different networks, ensuring comprehensive coverage of all TornadoCash withdrawal activity
- **Key fields**: `user_address` (recipient of withdrawn funds), `block_timestamp` (event timing), `chain` (blockchain network), `transaction_hash` (unique transaction identifier), `user_type` (always 'Transactor')

### Component B: Daily active user calculation  
- **Purpose**: Aggregates withdrawal events into daily distinct active user counts
- **Logic**: Takes the standardized user events and calculates daily active users by truncating block timestamps to day boundaries and selecting distinct user addresses per day. Groups data by date, chain, user type, and product to create daily snapshots of unique users who performed withdrawals. Applies chain availability filtering to ensure accurate reporting across different blockchain networks. This creates the foundation dataset where each row represents a unique user's activity on a specific day
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (set to 'day'), `chain`, `user_type`, `product_id`, `user_dau` (distinct user address)

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily user data into probabilistic data structures for efficient weekly aggregation
- **Logic**: Transforms daily active user data into HyperLogLog sketches using the `hll_count.init` function with 15-bit precision. This probabilistic approach allows efficient computation of distinct counts when merging data across multiple days. Groups daily data by timestamp, chain, user type, and product while initializing HLL sketches for each user set. This preprocessing step enables scalable weekly aggregation without storing individual user addresses
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch of daily users)

### Component D: Time window creation
- **Purpose**: Establishes complete time series coverage and creates 7-day rolling windows for weekly calculations
- **Logic**: Creates a complete datespine covering all days from first TornadoCash activity to present, ensuring no missing dates in the time series. For each day in the datespine, generates a 7-day lookback window including the current day plus the previous 6 days using timestamp array generation. This creates joinable relationships between each target date and its corresponding weekly window, enabling consistent WAU calculation even when some days have no activity
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component E: Weekly user aggregation
- **Purpose**: Combines daily HLL sketches across 7-day windows to compute weekly active users
- **Logic**: Joins the 7-day time windows with daily HLL sketches to create weekly aggregation windows. For each target date, collects HLL sketches from all days within its 7-day window. This creates the foundation for merging daily user sets into weekly distinct counts while preserving dimensional breakdowns by chain, user type, and product. Applies incremental processing filters to optimize performance during updates
- **Key fields**: `timestamp` (target week ending date), `chain_id`, `user_type`, `product_id`, `hll` (daily sketch for merging)

### Component F: Dimensional breakdowns
- **Purpose**: Creates multiple analytical perspectives by aggregating WAU across different dimensions
- **Logic**: Generates four separate dimensional views of weekly active users. Creates project-level aggregation by merging all HLL sketches regardless of chain or user type. Produces chain-level breakdown by merging sketches within each blockchain network. Generates user-type-level aggregation by merging sketches for each user classification. Creates product-level breakdown by merging sketches within each product category. Each breakdown uses `hll_count.merge_partial` to combine daily sketches and `hll_count.extract` to produce final distinct counts
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`, `user_wau` (weekly distinct count)

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project-level, chain-level, user-type-level, product-id-level) into a single comprehensive dataset with consistent schema
- **Time aggregation**: Uses rolling 7-day windows where each date represents the weekly active users ending on that date, ensuring consistent weekly periods without gaps
- **Final calculation**: Extracts distinct user counts from merged HyperLogLog sketches across 7-day periods, providing accurate weekly active user metrics while maintaining dimensional granularity. Applies the `finalize_metric_user_wau` macro to standardize output format and fill missing periods with zeros to ensure complete time series coverage

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

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

Tornado CashTORN

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown