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 addresses (daily) Methodology

## 1. Overview

Active addresses daily for Ink protocol measures the number of unique blockchain addresses that initiated at least one transaction on the Ink network each day. This metric serves as a key indicator of user engagement and network activity. For blockchain protocols, active addresses directly represent active users since each user interaction requires a unique address to initiate transactions. The calculation uses probabilistic counting techniques to efficiently handle large volumes of transaction data while maintaining accuracy.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Ink blockchain transaction records**: Raw transaction data from the Ink network containing transaction metadata, timestamps, and sender addresses
- **Chain availability metadata**: Information about operational periods when the Ink chain was available for data collection and processing

## 3. Step-by-step calculation

### Component A: Transaction user extraction
- **Purpose**: Identifies unique users from raw blockchain transactions
- **Logic**: Extracts transaction sender addresses from raw Ink blockchain transaction records as user identifiers. Each transaction sender (`from_address`) represents a potential active user. The component adds protocol metadata including chain identifier ('ink'), market sector classification ('blockchains_l2'), business segment ('blockchain'), and user type ('Transaction sender'). Transaction timestamps and hashes are preserved for downstream processing.
- **Key fields**: `block_timestamp` for timing, `from_address` as user identifier, `transaction_hash` for uniqueness, and various metadata fields for categorization

### Component B: Daily user aggregation
- **Purpose**: Aggregates transaction activity to daily distinct active users
- **Logic**: Truncates block timestamps to day boundaries using timestamp truncation to create daily time periods. Performs distinct selection on combinations of date, chain, user type, market sector, business segment, product identifier, and user address. This ensures each unique address is counted only once per day regardless of how many transactions they initiated. Includes incremental processing logic with lookback periods for data quality and reprocessing of recent periods.
- **Key fields**: `timestamp` (truncated to day), `user_address` for distinct counting, and dimensional fields for categorization

### Component C: HyperLogLog aggregation 
- **Purpose**: Efficiently aggregates distinct users across multiple dimensions using probabilistic counting
- **Logic**: Creates HyperLogLog sketches from individual user addresses using `hll_count.init()` with precision parameter 15 for high accuracy. Aggregates sketches across different dimensional breakdowns including overall project level ('project_dbt_tag'), chain level ('chain'), user type level ('user_type'), and product level ('product_id'). Uses `hll_count.merge_partial()` to combine sketches and `hll_count.extract()` to get final distinct counts. This approach enables efficient distinct counting while avoiding memory limitations of exact distinct operations on large datasets.
- **Key fields**: `user_dau` containing the distinct user count, `dimensions` indicating the breakdown level, and various dimensional identifier fields

### Component D: Active addresses mapping
- **Purpose**: Maps user DAU data to active addresses metric
- **Logic**: Selects user DAU data specifically for 'chain' and 'project_dbt_tag' dimensions, which provide the appropriate granularity for active addresses reporting. Renames the `user_dau` field to `active_addresses_daily` to reflect that for blockchain protocols, active users directly correspond to active addresses since each transaction requires a unique address.
- **Key fields**: `active_addresses_daily` containing the final count, `dimensions` for breakdown level, `chain_id` for network identification

### Final aggregation
- **Combining components**: The final metric flows directly from the HyperLogLog aggregation component, filtered for relevant dimensions and renamed appropriately
- **Time aggregation**: Uses daily boundaries determined by truncating blockchain timestamps to day level, ensuring consistent daily periods regardless of transaction timing within each day  
- **Data quality controls**: Applies chain availability filtering to exclude periods when the Ink chain was not operational or data collection was unreliable. Uses fill zeros strategy to populate missing days with zero values rather than null, ensuring consistent time series data
- **Final calculation**: The final active addresses daily value represents the distinct count of unique addresses that initiated at least one transaction on the Ink network during each specific day, calculated using HyperLogLog probabilistic counting for scalability and accuracy

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

Unique active addresses over a fixed 24-hour window.

Ink

Active addresses (daily)

Active addresses (daily)

Competitive landscape

Chain breakdown