Aleph Zero EVM is powered by Arbitrum's AnyTrust protocol which uses a data availability committee (DAC) to store raw transaction data.

Aleph Zero EVM is an Ethereum layer 2 powered by Arbitrum Orbit tech stack. This dashboard does not include Aleph Zero WASM data.

AZERO tokenholders own and govern the protocol.

github

twitter

discord

website

Blockchains (L2)

Aleph Zero EVM

# Aleph Zero EVM Transaction count Methodology

## 1. Overview

The Aleph Zero transaction count metric measures the daily number of unique transactions sent to each contract or address on the Aleph Zero EVM blockchain. This metric provides visibility into transaction activity and contract usage patterns by counting distinct transactions per destination address per day. The calculation aggregates raw blockchain transaction data on a daily basis and enriches it with address labels to categorize transaction destinations.

## 2. Data sources

The methodology relies on two primary data sources:

- **Aleph Zero EVM transaction records**: Raw blockchain transaction data including block timestamps, transaction hashes, sender and recipient addresses, and gas usage information from the Aleph Zero EVM blockchain
- **Address label database**: External labeling system that maps blockchain addresses to human-readable contract names and categorizations, specifically filtered for Aleph Zero chain addresses

## 3. Step-by-step calculation

### Component A: Base transaction extraction
- **Purpose**: Extract and standardize all Aleph Zero EVM transaction records
- **Logic**: Retrieve all transactions from Aleph Zero EVM blockchain data, selecting distinct records to avoid duplicates. Extract key fields including `block_timestamp`, `transaction_hash`, `from_address`, `to_address`, gas pricing (`receipt_effective_gas_price`), and gas usage (`receipt_gas_used`) information. Apply data type conversions to ensure numeric fields are properly formatted as big numeric values. Calculate Layer 2 gas fees by multiplying gas used by gas price and dividing by 1e18 for proper decimal conversion.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for unique identification, `to_address` for destination tracking, gas-related fields for fee calculations

### Component B: Daily transaction aggregation  
- **Purpose**: Aggregate unique transaction counts per destination address per day
- **Logic**: Group transactions by day using timestamp truncation to day-level granularity and by `to_address` to track transactions per destination. Count distinct `transaction_hash` values using approximate counting for performance optimization. Add standardized metadata fields including chain identifier as 'Aleph Zero EVM', market sector as 'blockchains_l2', business segment as 'blockchain', and null product identifier. This creates daily snapshots of transaction activity per contract or address.
- **Key fields**: Truncated `timestamp` for daily grouping, `to_address` for destination identification, `transaction_count` as the aggregated distinct count

### Component C: Address label enrichment
- **Purpose**: Enrich transaction data with human-readable contract names and labels  
- **Logic**: Join the aggregated transaction data with the address labeling database using `to_address` as the join key. Apply a left join to preserve all transaction records regardless of whether labels exist. Use coalesce function to assign 'Unlabeled' as the default value for addresses without corresponding entries in the labeling system. This categorizes transaction destinations as either labeled contracts with meaningful names or unlabeled addresses.
- **Key fields**: `contract_name` derived from `account_title` with 'Unlabeled' fallback, preserving all transaction aggregation fields

### Final aggregation
- **Combining components**: The enriched transaction data flows through the `finalize_metric_transaction_count` macro which standardizes the schema, validates identifiers, and ensures data completeness
- **Data standardization**: The macro applies consistent formatting and validation rules, fills missing time periods with zero values using the 'fill_zeros' strategy, and ensures proper data type alignment
- **Time boundaries**: Apply a final filter to exclude any data beyond September 17, 2025, ensuring the metric only includes historical and near-term data
- **Final calculation**: The result provides daily unique transaction counts per labeled contract or unlabeled address, with standardized metadata for chain classification and business categorization

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

Confirmed transactions added to the blockchain.

Aleph Zero EVMAZERO

Archived

Transaction count

Transaction count

Competitive landscape

Chain breakdown