Collators aggregate parachain transactions block candidates and producing state transition proofs for validators based on those blocks.

Heima is a specialized identity and data verification blockchain powered by Polkadot Relay chain.

HEI holders own and govern the protocol. Heima’s investors include LD Capital, Digital Renaissance, Signum Capital, and others.

website

twitter

github

discord

etherscan

Blockchains (L2)

Heima

# Heima Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user on the Heima blockchain platform. This metric is calculated by dividing daily revenue by daily active users, providing insight into the monetization efficiency and user engagement value. The calculation accounts for both Layer 1 (substrate) and Layer 2 (EVM) activities on Heima, requiring complex cross-layer user and fee tracking.

## 2. Data sources

The ARPU calculation relies on several key data sources:

- **Substrate blockchain events**: Heima substrate chain events including `TransactionFeePaid` events for L1 transaction fees and `NewAccount` events for account creation
- **Substrate extrinsics**: Transaction data from the Heima substrate layer including transaction senders and execution details  
- **EVM layer events**: Ethereum Virtual Machine events on Heima including `Executed` events for EVM transactions and `Withdraw`/`Deposit` events from the balances pallet for L2 fee tracking
- **End-of-day price feeds**: CoinGecko price data for the Heima token to convert native token fees to USD values
- **Account mapping data**: Cross-reference between substrate SS58 encoded addresses and EVM hexadecimal addresses for unified user tracking

## 3. Step-by-step calculation

### Component A: Daily active user calculation

- **Purpose**: Count distinct users active on both substrate and EVM layers daily
- **Logic**: Extract transaction senders from substrate extrinsics and EVM `Executed` events. Substrate users are identified from extrinsic sender addresses, while EVM users come from `Executed` event data in the ethereum pallet. All users are classified under the 'blockchains_l2' market sector and 'blockchain' business segment with 'Transaction sender' user type. Daily distinct counting uses HyperLogLog algorithms for efficient aggregation across multiple dimensions including project level, chain level, user type, and product level breakdowns.
- **Key fields**: `user_address` for distinct user identification, `block_timestamp` for daily aggregation, `chain` for layer differentiation ('heima' for substrate, 'heimaevm' for EVM layer)

### Component B: Account mapping for cross-layer tracking  

- **Purpose**: Create mappings between substrate and EVM addresses for unified user and fee tracking
- **Logic**: Process `NewAccount` events from the system pallet to extract substrate account addresses. Use a JavaScript user-defined function to convert SS58 encoded substrate addresses to EVM hexadecimal format. The conversion involves base58 decoding, extracting the 32-byte public key, and deriving the EVM address using keccak256 hash of the concatenated string "evm:" with the substrate account, taking the last 20 bytes as the EVM address.
- **Key fields**: `parachain_account` (original substrate address), `evm_account` (derived EVM address)

### Component C: Layer 1 fee calculation

- **Purpose**: Calculate transaction fees from substrate layer activities  
- **Logic**: Extract fee data from `TransactionFeePaid` events in successful transactions. Parse `amount` and `tip` values from event data, convert from native token units by dividing by 10^18 for decimal adjustment. Aggregate fees daily by block timestamp. Only include events where `success` is true to exclude failed transactions.
- **Key fields**: `amount` (base transaction fee), `tip` (additional miner tip), `block_timestamp` for daily aggregation

### Component D: Layer 2 fee calculation

- **Purpose**: Track EVM layer transaction fees with proper signer attribution
- **Logic**: Identify EVM transaction signers from `Executed` events in the evm pallet. Extract fee movements from `Withdraw` and `Deposit` events in the balances pallet for ethereum extrinsics. Match fee events to actual transaction signers using extrinsic IDs and account mapping. `Withdraw` events represent positive fees while `Deposit` events are negative (refunds). Net transaction fees per extrinsic by summing withdraw and deposit amounts. Only include fees where the balance event signer matches the original EVM transaction signer after account mapping conversion.
- **Key fields**: `transaction_fee` (net fee amount), `signer_address` (fee payer), `extrinsic_id` for matching transactions to fees

### Component E: USD revenue conversion

- **Purpose**: Convert native token fees to USD for standardized revenue measurement  
- **Logic**: Combine L1 and L2 fees into unified daily totals by chain and product. Apply CoinGecko USD conversion using end-of-day prices for the 'heima' token. Revenue aggregation maintains daily granularity with 'heima' chain identifier and 'heimachain' product classification.
- **Key fields**: `fees` (native token amount), USD converted `fees` (revenue in dollars), `timestamp` (daily boundary)

### Final aggregation

- **Combining components**: User DAU data provides daily distinct user counts aggregated using HyperLogLog across multiple dimensional breakdowns. Revenue data provides daily USD fee totals from both substrate and EVM layers. The ARPU macro joins these components on matching time and dimensional attributes.
- **Currency conversion**: All fee calculations use end-of-day CoinGecko price feeds for the Heima token, ensuring consistent USD valuation across the reporting period  
- **Time aggregation**: Both user and revenue data use daily boundaries with timestamp truncation to day level, ensuring aligned temporal aggregation for the division calculation
- **Final calculation**: ARPU equals daily total revenue in USD divided by daily distinct active users, with the division performed at matching dimensional granularities and time periods

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

HeimaHEI

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape