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 Revenue Methodology

## 1. Overview

AlephZero revenue represents the total transaction fees collected by the AlephZero network on a daily basis, converted to USD. This metric measures the network's ability to generate revenue from users executing transactions on the Aleph Zero EVM blockchain. The calculation follows a simple model where all transaction fees paid by users become network revenue, making revenue equivalent to total fees collected.

## 2. Data sources

The calculation relies on two primary data sources:
- **Aleph Zero EVM blockchain transaction records**: Raw transaction data including gas usage amounts, gas prices, transaction hashes, addresses, and block timestamps for all transactions executed on the Aleph Zero EVM network
- **End-of-day price feeds**: Daily AZERO token prices in USD from CoinGecko market data, used to convert native token fees to USD values

## 3. Step-by-step calculation

### Component A: Transaction fee calculation
- **Purpose**: Calculate the gas fees paid for each transaction on Aleph Zero EVM in native AZERO tokens
- **Logic**: Extract all transactions from the Aleph Zero EVM blockchain, capturing the `receipt_effective_gas_price` and `receipt_gas_used` for each transaction. Calculate the L2 gas fee amount by multiplying the gas used by the effective gas price, then dividing by 1e18 to convert from Wei units to AZERO tokens. Each transaction record includes the block timestamp, transaction hash, sender and recipient addresses, and the calculated fee amount.
- **Key fields**: `gas_price` (effective gas price per unit), `gas_used_amount` (total gas consumed), `l2_gas_fee_amount` (calculated fee in AZERO)

### Component B: Daily fee aggregation
- **Purpose**: Aggregate all transaction fees by day to create daily totals
- **Logic**: Group all transaction fees by day using timestamp truncation to daily boundaries. Sum all individual transaction fees within each day to create a single daily fee total per day. The aggregation maintains metadata fields including chain identifier, market sector classification, and business segment categorization.
- **Key fields**: `timestamp` (daily boundary), `fees` (sum of all transaction fees for the day)

### Component C: USD conversion
- **Purpose**: Convert AZERO-denominated fees to USD values using market prices
- **Logic**: Join the daily aggregated fees with end-of-day AZERO token prices from CoinGecko using timestamp matching. Multiply the daily fee amount in AZERO tokens by the corresponding USD price to get the fee amount in USD. Use inner join to ensure only days with both fee data and price data are included.
- **Key fields**: `fees` (converted to USD), `price` (AZERO/USD exchange rate)

### Final aggregation
- **Combining components**: The USD-converted fees flow directly into the revenue calculation without additional combining steps, as this metric treats all network fees as revenue
- **Currency conversion**: Fees are converted from AZERO to USD using end-of-day CoinGecko prices, with the conversion applied at the daily aggregation level after summing all transactions for each day
- **Time aggregation**: Daily boundaries are established using timestamp truncation, with all transactions within a calendar day summed together before USD conversion
- **Final calculation**: Revenue equals the total USD value of transaction fees collected each day (revenue = sum of daily transaction fees in USD). The finalize metric macros ensure proper schema formatting, validate data consistency, and fill any gaps with zeros where no transactions occurred

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Aleph Zero EVMAZERO

Archived

Revenue

Revenue

Competitive landscape

Chain breakdown