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 fees per user (AFPU) Methodology

## 1. Overview

Average Fees per User (AFPU) measures the average daily fee income generated per active user on the AuraFinance protocol. This metric answers the business question: "How much revenue does each active user generate for the protocol on average?" The calculation divides the total daily fees earned by AuraFinance by the number of unique daily active users, providing insight into user value and protocol efficiency.

## 2. Data sources

The calculation relies on several key blockchain and external data sources:

- **Cross-chain deposit events**: Parsed `BoosterLite_Deposited` events from AuraFinance contracts on Arbitrum, Base, Gnosis, Optimism, and Polygon networks
- **Ethereum token transfers**: Parsed `Transfer` events for BAL and bbausd tokens between specific protocol accounts
- **Transaction records**: Ethereum transaction data for identifying double-counting scenarios
- **External price data**: End-of-day token price feeds for USD conversion
- **Token metadata**: Decimal precision data for accurate amount calculations

## 3. Step-by-step calculation

### Component A: Daily active user tracking

- **Purpose**: Identifies and counts unique users interacting with AuraFinance daily
- **Logic**: Collects user addresses from two sources: cross-chain deposit events where users interact with `BoosterLite` contracts as depositors, and Ethereum token transfers where users send tokens to the voter proxy address `0xaf52695e1bb01a16d33d7194c28c42b10e0dbec2`. Excludes transfers from Balancer fee distributor addresses `0x26743984e3357efc59f2fd6c1afdc310335a61c9` and `0xd3cf852898b21fc233251427c2dc93d3d604f3bb` to avoid counting protocol-internal operations as user activity. Aggregates users by day using HyperLogLog for accurate deduplication across multiple dimensions including chain, user type, and product
- **Key fields**: `user_address` (unique user identifier), `block_timestamp` (for daily aggregation), `chain` (network identifier), `user_type` (always "Depositor")

### Component B: LP yield fee collection

- **Purpose**: Captures fees earned from liquidity provision rewards distributed through BAL tokens
- **Logic**: Tracks BAL token transfers from voter proxy addresses to booster contract addresses across multiple chains. Uses specific address pairs for each network: Ethereum uses voter proxy `0xaf52695e1bb01a16d33d7194c28c42b10e0dbec2` with boosters `0x7818a1da7bd1e64c199029e86ba244a9798eee10` and `0xa57b8d98dae62b26ec3bcc4a365338157060b234`, while sidechains use `0xc181edc719480bd089b94647c2dc504e2700a2b0` as voter proxy and `0x98ef32edd24e2c92525e59afc4475c1242a30184` as booster. For price normalization, uses Ethereum BAL token price for all chains except Polygon, which uses its native BAL price
- **Key fields**: `amount` (BAL token quantities), `token_address` (chain-specific BAL addresses), `from_address` and `to_address` (protocol account addresses)

### Component C: veBAL yield fee collection  

- **Purpose**: Captures trading fees earned from veBAL (vote-escrowed BAL) holdings
- **Logic**: Collects two types of veBAL-related fees: bbausd token transfers from booster contracts to reward distribution addresses, and BAL token transfers from Balancer fee distributors to the voter proxy. The bbausd transfers represent trading fee distributions flowing from boosters `0x7818a1da7bd1e64c199029e86ba244a9798eee10` and `0xa57b8d98dae62b26ec3bcc4a365338157060b234` to reward addresses. The BAL transfers capture direct fee distributions from distributors `0x26743984e3357efc59f2fd6c1afdc310335a61c9` and `0xd3cf852898b21fc233251427c2dc93d3d604f3bb` to the voter proxy
- **Key fields**: `amount` (token quantities for both bbausd and BAL), `token_address` (specific bbausd and BAL contract addresses), transaction routing between protocol accounts

### Component D: Double-counting prevention

- **Purpose**: Eliminates transactions that would inflate fee calculations through internal protocol operations
- **Logic**: Identifies and excludes transactions where BAL tokens flow from specific accounts (Aura staking contract, Balancer fee distributors) to the voter proxy and then to booster contracts within the same transaction. This prevents counting the same economic value multiple times when tokens move through the protocol's internal routing mechanisms. Uses transaction hash matching to identify these multi-step internal transfers
- **Key fields**: `transaction_hash` (for linking related transfers), account addresses for pattern matching

### Final aggregation

- **Combining components**: Sums all fee amounts from LP yields and veBAL yields after excluding double-counted transactions
- **Currency conversion**: Converts all token amounts to USD using end-of-day price feeds with decimal corrections applied based on token metadata
- **Time aggregation**: Truncates all timestamps to daily boundaries and aggregates fees by day
- **Final calculation**: Divides the total daily fees in USD by the count of daily active users to produce the average fees per user metric, with missing days filled with zero values to maintain time series continuity

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

Aura FinanceAURA

Archived

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape