Ankr operates a global network of both full and validator nodes on an array of blockchains. These nodes provide the basis for services like Ankr Staking which delegates users’ tokens to blockchain validators and delivers liquid staking rewards (supply-side fees) to users for their contributions to validation efforts.

Ankr is a web3 infrastructure provider of blockchain API/RPC connections, developer tools, and liquid staking products. Ankr was founded and launched in 2017 by Chandler Song, Ryan Fang, and Stanley Wu.

ANKR tokenholders own and govern the protocol. They currently take a cut of the total staking rewards earned by the protocol (revenue). Ankr’s investors include Binance Labs, Block VC, MapleBlock Capital, Bixin Ventures etc.

github

twitter

discord

etherscan

website

Liquid staking

Ankr

# Ankr Active users (weekly) Methodology

## 1. Overview

Ankr Weekly Active Users (WAU) measures the number of unique users who interact with Ankr's liquid staking protocols within rolling 7-day periods. This metric tracks user engagement across Ankr's ETH staking on Ethereum and BNB staking on BSC, capturing both staking and unstaking activities. The calculation uses HyperLogLog algorithms for efficient cardinality estimation across multiple dimensional breakdowns including chains, user types, and product segments.

## 2. Data sources

- **Ethereum staking events**: Parsed `StakeConfirmed` and `PendingUnstake` events from Ankr's ETH staking contracts on Ethereum
- **BSC staking events**: Parsed `Staked`, `UnstakePending`, and `Unstaked` events from Ankr's BNB staking contracts on BSC across multiple contract versions (V1, V2, V2.1)  
- **Blockchain transaction data**: Transaction metadata including timestamps, block numbers, transaction hashes, and log indices from Ethereum and BSC networks
- **Contract version data**: Block number boundaries used to differentiate between different versions of Ankr's staking contracts

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Identifies all users who interact with Ankr's liquid staking protocols
- **Logic**: Extracts user addresses from staking and unstaking events across Ethereum and BSC networks. For Ethereum, captures `staker` addresses from `StakeConfirmed` events and `receiverAddress` from `PendingUnstake` events. For BSC, extracts `delegator` addresses from `Staked` events and `claimer` addresses from `UnstakePending` events in V1/V2 contracts, and `staker`/`receiverAddress` from V2.1 contracts. Applies block number filters to separate contract versions: V1 uses blocks ≤ 23,545,403, V2 uses blocks 23,545,403 to 28,123,526, and V2.1 uses blocks > 28,123,526
- **Key fields**: `user_address`, `block_timestamp`, `chain`, `user_type` (ETH Staker, ETH Unstaker, BNB Staker, BNB Unstaker), `transaction_hash`, `log_index`

### Component B: Daily active user aggregation  
- **Purpose**: Calculates daily unique active users across all dimensions
- **Logic**: Truncates event timestamps to day boundaries and aggregates unique user addresses per day, chain, user type, and product. Groups users by these dimensions to create daily active user counts while preserving dimensional breakdowns for later analysis
- **Key fields**: `timestamp` (day-truncated), `timestamp_grain` (set to 'day'), `chain`, `user_type`, `product_id`, `user_dau` (unique user address)

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user counts to HyperLogLog sketches for efficient cardinality operations
- **Logic**: Initializes HLL sketches from daily user sets using 15-bit precision (32,768 buckets). This allows efficient merging of user sets across time windows without storing individual user addresses
- **Key fields**: `hll` (HyperLogLog sketch), maintaining all dimensional keys from daily aggregation

### Component D: Datespine and rolling window creation
- **Purpose**: Creates a continuous time series and defines 7-day rolling windows
- **Logic**: Generates a complete datespine from the earliest data timestamp to yesterday using daily intervals. For each date in the datespine, creates a 7-day window by joining with the previous 6 days plus the current day. This ensures every day has exactly 7 days of lookback data for WAU calculation
- **Key fields**: `timestamp` (target date), `joinday` (each of the 7 days in the window)

### Component E: Weekly user aggregation by dimensions
- **Purpose**: Calculates WAU across different dimensional breakdowns
- **Logic**: Merges HLL sketches across each 7-day window and extracts cardinality estimates to get unique user counts. Creates four separate breakdowns: project-level (all dimensions null), chain-level (chain_id populated), user_type-level (user_type populated), and product_id-level (product_id populated). Each breakdown maintains the timestamp and dimensions fields while nulling out non-relevant dimension columns
- **Key fields**: `user_wau` (extracted cardinality), `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) into a single result set with standardized schema
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 7-day windows calculated daily, where each day's WAU represents unique users active in that day plus the previous 6 days
- **Final calculation**: Extracts the final cardinality estimate from merged HLL sketches using `hll_count.extract(hll_count.merge_partial(hll))`, then applies the `finalize_metric_user_wau` macro to standardize schema, fill missing days with zeros, and ensure data quality

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

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

AnkrANKR

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown