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

Acala is a specialized stablecoin and liquidity blockchain powered by Polkadot Relay chain.

ACA holders own and govern the protocol. Acala’s investors include Pantera Capital, Coinbase Ventures, and Polychain Capital.

website

github

twitter

discord

etherscan

Blockchains (L2)

Acala Network

# Acala Network Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average amount of fees paid per daily active user on the Acala network. This metric answers the question: "How much does the average user contribute in fees to the Acala ecosystem per day?" The calculation divides total daily fees collected across Acala's dual-layer architecture (native parachain and EVM layer) by the number of daily active users, providing insight into user monetization and network usage intensity.

## 2. Data sources

- **Acala blockchain events**: Parsed events from multiple pallets including `evmAccounts` `ClaimAccount` events for address mappings, `evm` `Executed` events for EVM transactions, `balances` `Withdraw` and `Deposit` events for L2 fee tracking, and `TransactionFeePaid` events for native transaction fees
- **Acala extrinsics data**: Native parachain transaction records containing sender addresses and execution details
- **External price data**: End-of-day Acala (ACA) token price feeds from CoinGecko API for USD conversion
- **Account mapping data**: Cross-reference between EVM addresses and parachain account addresses via claim events

## 3. Step-by-step calculation

### Component A: Daily active user identification
- **Purpose**: Count unique daily active users across both Acala's native parachain and EVM layers
- **Logic**: Extract user addresses from two sources - native parachain extrinsics using the sender address field, and EVM layer transactions from `Executed` events in the evm pallet which contain the transaction initiator address. Truncate all timestamps to daily boundaries and count distinct user addresses per day using HyperLogLog aggregation to handle large user sets efficiently. Users are classified as "Transaction sender" type and tagged with appropriate chain identifiers (`acala` for native layer, `Acala EVM` for EVM layer)
- **Key fields**: `block_timestamp` for daily aggregation boundaries, `id` field from extrinsics for native users, `event_data[0]` from EVM Executed events for EVM users, `user_address` as the final deduplicated identifier

### Component B: Layer 1 native fees calculation  
- **Purpose**: Calculate fees paid for native Acala parachain transactions
- **Logic**: Extract fee payment events from `TransactionFeePaid` events where the transaction was successful. Each event contains the base transaction fee amount and optional tip amount. Sum these two components and adjust for Acala's 12-decimal token precision by dividing by 1e12. Aggregate fees by day, block number, and transaction hash to avoid double-counting
- **Key fields**: `event_data[1]` containing the base `amount`, `event_data[2]` containing the `tip`, `block_timestamp` for daily grouping, `success` flag for filtering valid transactions

### Component C: Layer 2 EVM fees calculation
- **Purpose**: Calculate net fees paid for EVM execution layer transactions  
- **Logic**: Track fee flows through `Withdraw` and `Deposit` events in the balances pallet that occur within EVM execution contexts. `Withdraw` events represent fee payments (positive amounts), while `Deposit` events represent fee refunds (treated as negative amounts). Match these events to EVM `Executed` events by `extrinsic_id` to ensure they belong to EVM transactions. Use account mapping data from `ClaimAccount` events to validate that the parachain account performing the withdraw/deposit corresponds to the EVM transaction signer, preventing misattribution. Calculate net fees per transaction by summing withdrawals minus deposits, then adjust for 12-decimal precision
- **Key fields**: `event_data[1]` containing transaction fee amounts, `event_data[0]` containing signer addresses, `extrinsic_id` for linking events, `parachain_account` and `evm_account` from mapping table for validation

### Component D: Fee aggregation and USD conversion
- **Purpose**: Combine Layer 1 and Layer 2 fees and convert to USD values
- **Logic**: Union the daily fee totals from native parachain transactions (base amount plus tip) and EVM layer transactions (net withdraw minus deposit amounts). Group by day and product layer (`acala` for native, `Acala EVM` for EVM). Apply USD conversion using end-of-day Acala token prices from CoinGecko API, matching prices to the transaction date. Sum fees across both layers to get total daily fees for the Acala ecosystem
- **Key fields**: `fees` as the token-denominated amount, `timestamp` for daily boundaries, `product_id` for layer identification, converted USD amounts for final calculations

### Final aggregation  
- **Combining components**: Join the daily active user counts with the daily fee totals by matching on the date dimension. Both components are aggregated to daily boundaries using the same timestamp truncation logic
- **Currency conversion**: All fees are converted to USD using end-of-day Acala token prices from CoinGecko, ensuring consistent valuation timing across the calculation
- **Time aggregation**: Both user counts and fees use daily boundaries created by truncating `block_timestamp` fields to day precision
- **Final calculation**: Apply the ARPU (Average Revenue Per User) formula where AFPU equals total daily fees in USD divided by the count of daily active users. Handle edge cases where user count is zero by returning null rather than division errors, and apply zero-filling strategy for days with no activity

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

Acala NetworkACA

Archived

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape