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

## 1. Overview

Weekly active addresses measures the number of unique blockchain addresses that have initiated at least one transaction on the Ink network within a 7-day rolling window. This metric answers the question "How many distinct users are actively transacting on Ink each week?" and uses a rolling 7-day window approach with HyperLogLog probabilistic data structures for efficient computation across multiple dimensional breakdowns.

## 2. Data sources

- **Ink blockchain transaction records**: Raw transaction data from the Ink blockchain containing block timestamps, transaction hashes, and sender addresses for all network transactions
- **Transaction metadata**: Includes transaction timing information and sender address identification to track user activity patterns

## 3. Step-by-step calculation

### Component A: User extraction
- **Purpose**: Identify unique transaction senders as active users from raw blockchain data
- **Logic**: Raw Ink blockchain transactions are processed to extract transaction senders. Each transaction record provides a `block_timestamp`, `transaction_hash`, and `from_address` field. The `from_address` represents the wallet address that initiated the transaction and is treated as an active user. Additional metadata is added including chain identifier set to 'ink', market sector as 'blockchains_l2', business segment as 'blockchain', and user type classified as 'Transaction sender'.
- **Key fields**: `block_timestamp` for timing, `from_address` as the user identifier, and `user_address` as the standardized user field

### Component B: Daily active user calculation  
- **Purpose**: Calculate the count of distinct active users per day
- **Logic**: Transaction data is aggregated daily by truncating `block_timestamp` to day granularity. For each day, user addresses are deduplicated using distinct selection to identify unique active users. The result includes the daily timestamp, timestamp grain set to 'day', and the distinct `user_address` values representing daily active users.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing the distinct user address, and dimensional metadata for later aggregation

### Component C: Weekly active user aggregation with rolling windows
- **Purpose**: Calculate 7-day rolling weekly active users using probabilistic counting
- **Logic**: A datespine is generated covering all dates from the minimum transaction date to the current date minus one day. For each date in the datespine, a 7-day window is created including the current day plus the previous 6 days using array generation functions. Daily active user data is converted to HyperLogLog probabilistic data structures for efficient distinct counting. These HyperLogLog structures are merged across the 7-day windows to calculate unique users. The aggregation is performed across four dimensional breakdowns: project level (project_dbt_tag), chain level, user type level, and product level. Each breakdown uses HyperLogLog merge operations to combine daily distinct user counts into weekly aggregates.
- **Key fields**: `timestamp` for the rolling window end date, `user_wau` containing the distinct user count, and `dimensions` indicating the aggregation level

### Final aggregation
- **Combining components**: The weekly active user data is filtered to include only 'chain' and 'project_dbt_tag' dimensional breakdowns. The `user_wau` field is renamed to `active_addresses_weekly` to align with the metric definition.
- **Currency conversion**: Not applicable for this address-based metric
- **Time aggregation**: Uses 7-day rolling windows where each day represents the count of unique addresses active in that day plus the previous 6 days. Missing dates are filled with zero values to maintain consistent time series data.
- **Final calculation**: The final metric value represents the count of distinct blockchain addresses that initiated at least one transaction within any 7-day rolling period, calculated using HyperLogLog probabilistic data structures for scalable computation across large address sets.

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

Unique active addresses over a rolling 7-day window.

Ink

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown