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

## 1. Overview

Heima earnings represent the protocol's net profitability, calculated as revenue minus expenses on a daily basis. Revenue comes from transaction fees collected on both the native Heima parachain (L1) and its EVM-compatible layer (L2), while expenses consist of token incentives paid to validators and stakers. The metric measures the protocol's financial performance by tracking the difference between fee income and staking reward payouts, providing insight into operational sustainability and profitability.

## 2. Data sources

The calculation uses several types of blockchain data and external feeds:

- **Heima blockchain events**: Native parachain event logs including transaction fee payments, staking rewards, and account creation events
- **EVM layer events**: Events from Heima's EVM-compatible layer including transaction executions and balance changes
- **Substrate transaction data**: Transaction records from the Substrate-based Heima parachain with event data and execution status
- **Balance change events**: `Withdraw` and `Deposit` events from the balance pallet tracking fee payments on the EVM layer
- **Staking events**: Reward distribution events from both parachain staking and score-based staking mechanisms
- **End-of-day token price feeds**: CoinGecko price data for the Heima token used for USD conversion
- **Account mapping data**: System events that enable conversion between Substrate and EVM address formats

## 3. Step-by-step calculation

### Component A: L1 transaction fees (native parachain)
- **Purpose**: Calculate transaction fees collected on the native Heima parachain
- **Logic**: Extract `TransactionFeePaid` events from successful transactions on the Heima parachain. Each event contains the base transaction fee and any tip amount paid by users. The fee amounts are extracted from the event data array positions, converted from 18-decimal precision (1e18) to token amounts, and filtered to only include successful transactions
- **Key fields**: `amount` (base transaction fee), `tip` (optional additional payment), `block_timestamp` (for daily aggregation), `success` flag (to filter successful transactions only)

### Component B: L2 transaction fees (EVM layer)
- **Purpose**: Calculate transaction fees from the EVM-compatible layer of Heima
- **Logic**: Match EVM transaction executions with corresponding balance changes to identify legitimate user fees. First, identify EVM transactions through `Executed` events from the EVM pallet. Then, find corresponding `Withdraw` events (positive fees) and `Deposit` events (negative fees or refunds) from the balance pallet. Use address mapping between Substrate and EVM formats to ensure the transaction signer matches the balance change account. Aggregate net fees per transaction by summing withdrawals and deposits
- **Key fields**: `transaction_fee` (net fee amount), `signer_address` (transaction initiator), `extrinsic_id` (links EVM execution to balance changes)

### Component C: Token incentive expenses (staking rewards)
- **Purpose**: Calculate token rewards paid out as protocol expenses for staking
- **Logic**: Extract staking reward events from two mechanisms: traditional parachain staking rewards from `Rewarded` events in the parachain staking pallet, and score-based staking rewards from `RewardClaimed` events in the score staking pallet. Convert reward amounts from 18-decimal precision to token amounts and aggregate by day
- **Key fields**: `amount` (reward amount paid), `block_timestamp` (for daily aggregation), event source pallet (parachain staking vs score staking)

### Component D: Address mapping system
- **Purpose**: Enable conversion between Substrate and EVM address formats for L2 fee calculation
- **Logic**: Process `NewAccount` events from the system pallet to extract Substrate account identifiers. Use a custom JavaScript function to convert Substrate SS58-encoded addresses to hexadecimal format, then derive the corresponding EVM address using keccak256 hashing with the "evm:" prefix. This mapping enables proper attribution of EVM layer fees to the correct Substrate accounts
- **Key fields**: `parachain_account` (original Substrate address), `evm_account` (derived EVM address)

### Final aggregation
- **Combining components**: L1 and L2 fees are aggregated separately by day, then combined to create total daily revenue. Token incentives are aggregated by day to create total daily expenses
- **Currency conversion**: Both revenue and expense components are converted to USD using end-of-day CoinGecko price feeds for the Heima token, applied at the daily aggregation level
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation, with separate aggregation for each fee source before combining
- **Final calculation**: Earnings are calculated as daily revenue minus daily expenses, where revenue equals the sum of L1 and L2 transaction fees, and expenses equal token incentive payouts. The calculation uses a fill-forward strategy for revenue (carrying forward the last known value) and fill-zeros strategy for expenses (treating missing days as zero expenses) to ensure complete daily coverage

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

Net profit (also profits, net income, profitability) — revenue remaining after subtracting expenses.

HeimaHEI

Earnings

Earnings

Competitive landscape