twitter

website

github

Asset management

Seamless Protocol

# Seamless Protocol Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average amount of fees generated per daily active user on Seamless Protocol. This metric is calculated by dividing total daily fees (in USD) by the number of daily active users. It provides insight into the revenue efficiency of the protocol's user base and helps assess the economic value generated per user interaction.

## 2. Data sources

The AFPU calculation relies on several categories of raw blockchain data and external sources:

- **Blockchain events**: Parsed Base blockchain events from Seamless Protocol contracts including `Borrow`, `Supply`, `Withdraw`, `Repay`, `FlashLoan`, and `LiquidationCall` events from the LendingPool contract, `ReserveFactorChanged` and `LiquidationProtocolFeeChanged` events from the LendingPoolConfigurator contract, and `Mint` and `Redeem` events from the LeverageManager contract
- **Transaction data**: Base blockchain token transfer events, particularly transfers involving aTokens and transfers to specific fee recipient addresses
- **External data**: End-of-day price feeds for token-to-USD conversion and token metadata including decimal places and symbols
- **State data**: Treasury accrual snapshots from Seamless Protocol's internal state tracking system
- **Configuration data**: Hardcoded protocol configuration including pool addresses, configurator mappings, treasury addresses, and Morpho vault configurations

## 3. Step-by-step calculation

### Component A: Daily active users calculation
- **Purpose**: Counts distinct users who interact with Seamless Protocol each day
- **Logic**: Identifies users from lending pool events on Base blockchain. Users are extracted from parsed `Borrow`, `Supply`, `Withdraw`, `Repay`, `FlashLoan`, and `LiquidationCall` events. Each user is classified by interaction type (Borrower, Depositor, Withdrawer, Repayer, Liquidator). The system creates daily snapshots of distinct user addresses using HyperLogLog sketches for efficient counting. Users are aggregated across different dimensions including overall protocol, by chain, by user type, and by product
- **Key fields**: `user_address` from event parameters, `block_timestamp` for daily aggregation, `user_type` for classification

### Component B: V1 lending interest fees
- **Purpose**: Calculates protocol fees from lending interest accrual
- **Logic**: Combines treasury accrual data with treasury mint events to determine net interest earned by the protocol. Treasury accruals represent the total interest accumulated, while treasury mints represent tokens minted to the treasury. Daily interest revenue is calculated as the difference between consecutive days' cumulative amounts. Reserve factors are applied to split revenue between protocol fees and supply-side fees paid to lenders. The calculation uses daily reserve factor configurations that can change over time through governance events
- **Key fields**: `treasury_accruals` from state data, `amount` from mint events, `reserve_factor` from configurator events

### Component C: Flashloan fees
- **Purpose**: Captures fees from flashloan operations
- **Logic**: Extracts premium amounts directly from parsed `FlashLoan` events. Each flashloan transaction includes a premium fee that represents pure protocol revenue. These fees are aggregated daily by token and converted to USD using end-of-day price feeds
- **Key fields**: `premium` amount from flashloan events, `asset` token address

### Component D: Liquidation fees
- **Purpose**: Calculates protocol fees from liquidation events
- **Logic**: Identifies liquidation transactions through `LiquidationCall` events, then finds corresponding aToken transfers from liquidated users to the treasury address within the same transaction. Liquidation protocol fee factors are applied to determine the protocol's share versus the supply-side share. The system matches liquidation events with aToken transfers based on transaction hash, user address, treasury address, and collateral token address
- **Key fields**: `user` and `liquidator` addresses from liquidation events, `amount` from aToken transfers, `liquidation_factor` from configurator settings

### Component E: Morpho vault performance fees
- **Purpose**: Captures performance fees from Morpho vault strategies
- **Logic**: Monitors token transfers to a specific fee recipient address for Morpho vault tokens. The system maps vault addresses to underlying token addresses for consistent pricing, as some vault tokens don't have direct price feeds. Fee amounts are adjusted for decimal differences between vault tokens and their underlying assets. Transfers are filtered to only include those directed to the known fee recipient address
- **Key fields**: `value` from transfer events, `to_address` matching fee recipient, `token_address` for vault identification

### Component F: Leverage token strategy fees
- **Purpose**: Calculates fees from LTS mint and redeem operations
- **Logic**: Combines token fees and treasury fees from both mint and redeem events in the LeverageManager contract. Each operation generates two types of fees that are summed together. The system maps LTS token addresses to their underlying assets for proper pricing. Daily aggregation includes all mint and redeem operations with their associated fee amounts
- **Key fields**: `token_fee` and `treasury_fee` from mint/redeem events, `token` address for identification

### Final aggregation
- **Combining components**: All fee components are summed together daily by token address, then converted to USD using end-of-day price feeds and corrected for token decimal places. Missing days are filled with zero values to ensure continuous time series
- **Currency conversion**: USD conversion uses end-of-day price feeds matched by chain, token address, and date. Token amounts are first corrected for decimal places by dividing by 10^decimals, then multiplied by the USD price
- **Time aggregation**: Both fees and user counts are aggregated to daily granularity using timestamp truncation to day boundaries. HyperLogLog sketches enable efficient distinct user counting across time periods
- **Final calculation**: AFPU is calculated by dividing total daily fees (in USD) by daily active user count. The result represents the average fee revenue generated per user per day. Days with zero users result in null AFPU values rather than division by zero errors

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

Seamless ProtocolSEAM

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape