Liquidity providers (LPs) deposit funds into Aura Finance and receive a return on investment (supply-side fees).

Aura Finance is an asset management and staking protocol built on Ethereum. Aura Finance was founded by an anonymous team and launched in June 2022.

AURA tokenholders own and govern the protocol. They currently take a cut of the total yield generated (revenue).

governance

github

twitter

discord

etherscan

website

Asset management

Aura Finance

# Aura Finance Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user on the Aura Finance platform. This metric is calculated by dividing total daily revenue by the number of daily active users, providing insights into the platform's revenue efficiency and user monetization. Aura Finance generates revenue through a revenue-sharing model on Balancer incentives (taking 25% of LP yields) and by capturing 100% of veBAL trading fee yields distributed to users.

## 2. Data sources

The calculation uses several key data sources:

- **Cross-chain deposit events**: Parsed `Deposited` events from `BoosterLite` contracts across Arbitrum, Base, Gnosis, Optimism, and Polygon networks, capturing user deposit activities
- **Ethereum token transfers**: Token transfer records tracking deposits to Aura Finance contracts and yield distributions between protocol accounts
- **Multi-chain BAL token flows**: BAL token transfer events across Ethereum and supported sidechains, tracking incentive distributions from voter proxy accounts to booster accounts
- **Balancer trading fee distributions**: bb-a-USD token transfers on Ethereum representing veBAL trading fee yields distributed to reward accounts
- **End-of-day price feeds**: Token price data for converting various tokens to USD equivalents for consistent revenue measurement
- **Token metadata**: Decimal information for accurate token amount calculations across different token standards

## 3. Step-by-step calculation

### Component A: Daily active user identification
- **Purpose**: Identify and count unique users interacting with Aura Finance daily across all supported chains
- **Logic**: User activity is captured through two primary sources. First, parsed `Deposited` events from `BoosterLite` contracts on sidechains (Arbitrum, Base, Gnosis, Optimism, Polygon) identify depositors through the `user` parameter in the events. Second, token transfers to the main deposit account address (`0xaf52695e1bb01a16d33d7194c28c42b10e0dbec2`) on Ethereum capture additional user activity, excluding transfers from known Balancer fee distributor addresses to prevent double counting. All user addresses are classified as 'Depositor' user type under the 'yield_aggregator' business segment.
- **Key fields**: Block timestamp for daily aggregation, `user_address` from event parameters or transfer `from_address`, transaction identifiers for deduplication

### Component B: User aggregation with HyperLogLog
- **Purpose**: Efficiently count distinct users daily while supporting dimensional breakdowns
- **Logic**: User addresses are aggregated using HyperLogLog (HLL) data structures to handle large-scale distinct counting efficiently. Daily aggregations are performed by truncating block timestamps to day boundaries. The system supports multiple dimensional breakdowns including project-level totals, chain-specific counts, user type classifications, and product-specific metrics. HLL merge operations combine counts across different dimensions while maintaining accuracy.
- **Key fields**: Daily `timestamp`, `user_dau` counts, dimensional attributes like `chain_id`, `user_type`, `product_id`

### Component C: LP yield revenue calculation  
- **Purpose**: Calculate revenue from Aura Finance's share of Balancer LP incentives across multiple chains
- **Logic**: LP yields are tracked through BAL token transfers from voter proxy accounts to booster accounts across all supported chains. The system uses chain-specific configurations for voter proxy addresses, booster addresses, and BAL token addresses. For pricing consistency, Ethereum BAL prices are used for all chains except Polygon, which uses its own BAL price. Revenue is calculated by applying a 25% multiplier to the total yield amounts, representing Aura Finance's revenue share from Balancer incentives. A denylist mechanism excludes specific transaction patterns that would result in double counting, particularly transfers involving aura staking and fee distributor flows.
- **Key fields**: `amount` of BAL tokens transferred, `token_address` for price lookup, `account_name` for yield categorization, transaction identifiers for denylist filtering

### Component D: veBAL yield revenue calculation
- **Purpose**: Calculate revenue from Balancer trading fees earned through veBAL holdings
- **Logic**: veBAL yields are captured through two types of transfers on Ethereum. First, bb-a-USD token transfers from booster accounts to reward accounts represent distributed trading fees. Second, BAL token transfers from Balancer fee distributor accounts to the voter proxy account capture additional fee distributions. Unlike LP yields, 100% of veBAL yields are counted as revenue since these represent direct trading fee distributions to Aura Finance's veBAL position.
- **Key fields**: Transfer `amount` values, `token_address` for bb-a-USD and BAL tokens, account addresses for filtering relevant transfers

### Component E: Revenue normalization and aggregation
- **Purpose**: Convert all revenue streams to USD and combine into daily totals
- **Logic**: All token amounts are converted to USD using end-of-day price feeds, with decimal corrections applied based on token metadata to ensure accurate value calculations. LP yields have the 25% revenue multiplier applied before USD conversion, while veBAL yields are converted at full value. Daily aggregation is performed by truncating block timestamps to day boundaries, summing all USD-converted revenue amounts across both yield sources.
- **Key fields**: USD-converted `revenue` amounts, daily `timestamp` boundaries, `chain_id` for multi-chain aggregation

### Final aggregation
- **Combining components**: Daily active user counts and daily revenue totals are combined using the `calculate_arpu` macro, which performs the division of total daily revenue by total daily active users
- **Currency conversion**: All revenue amounts are normalized to USD using end-of-day price feeds, ensuring consistent measurement across different tokens and chains
- **Time aggregation**: Both user and revenue data use daily timestamp truncation to align on consistent 24-hour boundaries
- **Final calculation**: ARPU is computed as the quotient of total daily USD revenue divided by total daily active users, with missing days filled with zero values to maintain complete time series continuity

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

Aura FinanceAURA

Archived

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape