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

Moonbeam is an Ethereum-compatible smart contracts platform built as a Polkadot parachain.

GLMR holders own and govern the protocol. Moonbeam’s investors include IOSG Ventures, Coinbase Ventures, Fenbushi Capital, CoinFund, etc

website

github

twitter

discord

etherscan

Blockchains (L2)

Moonbeam

# Moonbeam Average revenue per user (ARPU) Methodology

> **Archived 2026-07-31.** Token Terminal stopped tracking Moonbeam following the announced migration of GLMR to Base and the launch of the new Moonbeam Protocol. The methodology below describes how this metric was calculated while the chain was tracked; historical values remain accurate and accessible.

## 1. Overview

Average revenue per user (ARPU) for Moonbeam is calculated as the average daily revenue generated per active user on the network. This metric is utilized to evaluate the economic efficiency of user activity and the monetization effectiveness of the blockchain network. For Moonbeam, revenue is composed entirely of transaction fees, as zero supply-side fee sharing is implemented on the network.

## 2. Data sources

- **Blockchain events**: `TransactionFeePaid` events from `transactionPayment` pallets, `Withdraw` and `Deposit` events from `balances` pallets, `Executed` events from `ethereum` pallets, and native transaction signers from Substrate extrinsics on Moonbeam
- **External data**: End-of-day price feeds for native GLMR assets

## 3. Step-by-step calculation

### Component A: Active users (daily) calculation

- **Purpose**: Count the number of unique users who performed transactions on Moonbeam each day.
- **Logic**: Transaction senders are extracted from two sources: Substrate extrinsics (native Moonbeam transactions) and `Executed` events from `ethereum` pallets (Moonbeam EVM transactions). For Substrate transactions, senders are identified from the extrinsics table. For Moonbeam EVM transactions, sender addresses are extracted from `Executed` events in the `ethereum` pallet. Duplicates are removed and distinct users are counted per day. Users are classified as "Transaction sender" type and associated with the Layer 2 blockchains market sector.
- **Key fields**: `block_timestamp` for daily grouping, `id` field from extrinsics as user address, `event_data[0]` from `Executed` events as EVM user address, `user_address` as the final user identifier.

### Component B: Layer 1 fee collection

- **Purpose**: Calculate transaction fees paid on the Moonbeam Substrate layer.
- **Logic**: Fee data is extracted from `TransactionFeePaid` events in the `transactionPayment` pallet. Event data is parsed to retrieve transaction fee and tip amounts from positions 1 and 2 in the event data array. Total transaction cost is calculated as the sum of the fee and tip. Values are converted from wei to GLMR by dividing by normalized decimal precision. Each fee is associated with its corresponding extrinsic identifier and timestamp.
- **Key fields**: `event_data[1]` as `transaction_fee`, `event_data[2]` as `transaction_tip`, `extrinsic_id` for transaction linking, `timestamp` for daily aggregation.

### Component C: Moonbeam EVM fee collection

- **Purpose**: Calculate transaction fees for Ethereum-compatible (EVM) transactions executed on Moonbeam.
- **Logic**: Moonbeam EVM transactions are identified by locating `Executed` events in the `ethereum` pallet, followed by the collection of associated fee payments from `Withdraw` and `Deposit` events in the `balances` pallet. Withdraw and deposit events are matched to executed transactions using extrinsic identifiers and block timestamps. The address making the withdraw/deposit is verified to match the original transaction signer. Withdraw (positive fees) and deposit (negative fees) events are combined and summed by transaction to determine net fee amounts. Values are converted from wei to GLMR by dividing by normalized decimal precision.
- **Key fields**: `event_data[0]` as signer address, `event_data[1]` as fee amount, `extrinsic_id` for transaction matching, `event_method` to distinguish `Withdraw` vs `Deposit`.

### Component D: Fee aggregation and USD conversion

- **Purpose**: Combine all fee types and convert to USD for consistent revenue measurement.
- **Logic**: Layer 1 and Moonbeam EVM fees are combined via a union by timestamp and extrinsic identifier. Total fees are summed per day across all transaction types. GLMR asset amounts are converted to USD using end-of-day price feeds. Conversion is applied using the asset metadata for GLMR to retrieve current prices.
- **Key fields**: `transaction_fee` as the combined fee amount, `fees` as the USD-converted amount.

### Component E: Revenue calculation

- **Purpose**: Determine net revenue by subtracting supply-side fees from total fees.
- **Logic**: Revenue is calculated as total fees minus fees paid to supply-side participants. For Moonbeam, supply-side fees are set to zero, meaning the network retains 100% of transaction fees as protocol revenue. Therefore, revenue is equal to the total transaction fees collected.
- **Key fields**: `fees` from the fees calculation, `fees_supply_side` set to 0, `revenue` as the final amount.

### Component F: Final aggregation and ARPU calculation

- **Purpose**: Combine daily revenue and user data to calculate the final ARPU metric.
- **Logic**: Daily active user counts are joined with daily revenue amounts by timestamp. Daily timestamp boundaries are utilized by both metrics for consistent aggregation periods. All fee amounts are converted from native GLMR assets to USD using end-of-day price feeds to enable cross-protocol comparisons. Data is aggregated to daily boundaries using timestamp truncation to the day level, with missing days filled with zero values. ARPU is calculated as daily revenue divided by active users (daily), while cases where the user count is zero are handled by safe division logic. Results are finalized using a standardized schema with data quality validation.

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

MoonbeamGLMR

Archived

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape