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 (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have sent at least one transaction on the Ink blockchain within a rolling 30-day window. This metric provides insight into user engagement and network activity by tracking distinct transaction senders over time. The calculation uses HyperLogLog probabilistic counting to efficiently estimate unique address counts across overlapping time periods, with the final metric representing blockchain user activity measured through transaction initiation.

## 2. Data sources

The calculation relies on the following data sources:
- **Ink blockchain transaction records**: Complete transaction history including timestamps, transaction hashes, and sender addresses from the Ink blockchain
- **Chain availability configuration**: Metadata that defines data availability and completeness boundaries for quality filtering

## 3. Step-by-step calculation

### Component A: User identification from transactions
- **Purpose**: Extract and classify unique addresses from blockchain transactions as active users
- **Logic**: Process all Ink blockchain transactions to identify transaction senders as active addresses. Each transaction record provides the sending address via the `from_address` field, along with block timestamp and transaction hash. All transaction senders are classified as "Transaction sender" user type and tagged with Ink chain metadata including market sector as "blockchains_l2" and business segment as "blockchain". No filtering is applied at this stage - all transactions and their senders are included in the analysis.
- **Key fields**: `block_timestamp` for timing analysis, `transaction_hash` for transaction identification, `from_address` as the active user address, and classification fields for chain and market categorization

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users by counting unique addresses that sent transactions each day
- **Logic**: Group transaction senders by day using timestamp truncation to day granularity. For each day, count distinct addresses that initiated at least one transaction. This creates a daily time series of unique active addresses. The calculation preserves dimensional breakdowns by chain, user type, market sector, business segment, and product. Incremental processing is used with daily partitioning to efficiently update the metric as new transaction data arrives.
- **Key fields**: Daily timestamp from `block_timestamp` truncation, `user_address` as the distinct identifier for counting, and dimensional attributes for later aggregation

### Component C: Monthly active user calculation with HyperLogLog
- **Purpose**: Calculate 30-day rolling window unique address counts using probabilistic counting methods
- **Logic**: Create HyperLogLog sketches for each day's active users to enable efficient unique counting across time windows. Generate a complete datespine covering all days in the analysis period, then for each day create a 30-day rolling window spanning that day plus the previous 29 days. Use the datespine to ensure no gaps in the time series analysis. For each 30-day window, merge the HyperLogLog sketches from all days within the window to count unique addresses while properly handling overlaps where the same address was active on multiple days. Extract the final unique count from the merged HyperLogLog structure. Create dimensional breakdowns including project-level aggregation, chain-level aggregation, user type aggregation, and product-level aggregation through separate grouping operations.
- **Key fields**: HyperLogLog sketches from daily `user_dau` values, 30-day window boundaries from datespine generation, and `dimensions` field indicating the breakdown level (chain, project_dbt_tag, user_type, product_id)

### Final aggregation
- **Combining components**: Filter the monthly active user results to include only chain-level and project-level dimensions as these are most relevant for blockchain address activity analysis. The project_dbt_tag dimension provides overall Ink protocol activity while the chain dimension provides chain-specific activity.
- **Currency conversion**: No currency conversion required as this is a count-based metric measuring user activity rather than financial values
- **Time aggregation**: Monthly boundaries are established through 30-day rolling windows, with each day representing the endpoint of a 30-day lookback period. This creates a smooth time series without artificial month-end boundaries.
- **Final calculation**: Rename the `user_mau` field to `active_addresses_monthly` to reflect that in blockchain contexts, active users are measured through active addresses that initiate transactions. Apply chain availability filtering to ensure only periods with complete and reliable data are included in the final metric. The result is a time series showing unique address counts that were active (sent at least one transaction) within each 30-day rolling window.

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

Unique addresses active over a rolling 30-day window.

Ink

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown