Ink batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense).

Ink is an Ethereum Layer 2 (L2) blockchain built on Optimism's Superchain, focused on providing a secure, scalable infrastructure for Web3 applications.

Kraken team owns and governs the protocol. Kraken's investors include RIT Capital Partners, Hummingbird Ventures, Money Partners Group, etc.

github

website

twitter

discord

Blockchains (L2)

# Ink Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Ink represents the count of unique addresses that have sent at least one transaction within a rolling 30-day period ending on each given day. This metric uses HyperLogLog probabilistic data structures to efficiently calculate cardinality estimates across multiple dimensional breakdowns, providing insights into user engagement patterns at the project, chain, user type, and product levels.

## 2. Data sources

- **Ink blockchain transaction records**: Raw transaction data from the Ink blockchain including transaction metadata, timestamps, and participant addresses
- **Transaction sender addresses**: User addresses (`from_address`) that initiated transactions on the Ink network
- **Block timestamps**: Precise timing information for when each transaction was included in a block
- **Transaction identifiers**: Unique transaction hashes for deduplication and tracking

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identifies unique transaction senders per day as the foundation for MAU calculation
- **Logic**: Processes raw Ink transaction data to extract distinct sender addresses for each calendar day. Transactions are grouped by truncating `block_timestamp` to day boundaries, and each unique `user_address` (derived from `from_address`) represents one daily active user. Each user is classified as "Transaction sender" type and tagged with Ink chain metadata including market sector "blockchains_l2" and business segment "blockchain"
- **Key fields**: `timestamp` (daily boundary), `user_address`, `chain`, `user_type`, `product_id`

### Component B: HyperLogLog sketch creation
- **Purpose**: Converts daily user sets into probabilistic data structures for efficient cardinality estimation
- **Logic**: Takes the daily active user data and creates HyperLogLog sketches with 15-bit precision for each combination of day, chain, user type, and product. The HLL initialization uses `hll_count.init(user_dau, 15)` to create memory-efficient sketches that can estimate cardinality while consuming minimal storage space
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (sketch data structure)

### Component C: Date spine and window generation
- **Purpose**: Creates complete time series coverage and defines 30-day rolling windows
- **Logic**: Generates a continuous date spine from the earliest available data to the most recent complete day to ensure no timestamps are skipped. For each date in this spine, creates a 30-day lookback window by generating timestamps for the target date plus the previous 29 days using `generate_timestamp_array`. This produces a table where each row represents one day within a 30-day window ending on the primary timestamp
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within window)

### Component D: Window-based HLL merging
- **Purpose**: Combines daily user sketches across 30-day windows to identify unique users over rolling periods
- **Logic**: Joins the date spine windows with daily HLL sketches, matching each window day (`joinday`) to its corresponding daily sketch (`timestamp`). This creates a dataset where each target date has associated HLL sketches for all 30 days in its lookback window. The sketches are then merged using `hll_count.merge_partial(hll)` to combine user sets while maintaining uniqueness across the entire 30-day period
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, merged `hll` sketches

### Component E: Dimensional breakdowns
- **Purpose**: Creates multiple analytical perspectives on the MAU data
- **Logic**: Generates four separate dimensional views by grouping and merging HLL sketches differently. Project-level aggregates all users regardless of chain, user type, or product. Chain-level groups by `chain_id` only. User type groups by `user_type` classification. Product-level groups by `product_id` identifier. Each breakdown uses `hll_count.extract()` to convert merged sketches into final cardinality estimates while setting unused dimension fields to null
- **Key fields**: `dimensions` (breakdown type), `user_mau` (final count), dimension-specific fields

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using `UNION ALL` operations to create a single result set with consistent schema across different analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows ending on each calendar day, with daily grain timestamps for time series analysis
- **Final calculation**: Applies the `finalize_metric_user_mau` macro to standardize schema formatting, apply the "fill_zeros" strategy for missing periods, and add metadata fields including data source identifier "ink". The final MAU values represent probabilistic estimates from HyperLogLog cardinality extraction, providing accurate unique user counts across the rolling 30-day windows for each dimensional breakdown.

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

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

Ink

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown