Bitcoin holders deposit Bitcoin into Solv Protocol and receive yield from onchain strategies (supply-side fees).

Solv Protocol offers financial services for Bitcoin, including lending, liquid staking, yield generation, and fund management.

Solv Protocol team & investors own and govern the protocol. They currently take a cut of the total yield generated (revenue). Solv Protocol's investors include IOSG, Blockchain Capital, Binance Labs, etc.

github

twitter

discord

etherscan

website

Liquid staking

Solv Protocol

# Solv Protocol Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average daily fee revenue generated per active user on the Solv protocol. This metric answers the business question "How much fee revenue does each active user generate on average?" and is calculated by dividing total daily fees by the number of daily active users. Solv is a Bitcoin liquid staking protocol that generates fees through multiple mechanisms including pool management fees, collaboration partnerships, redemption fees, and subscription fees across multiple blockchain networks.

## 2. Data sources

The calculation relies on several types of blockchain and external data:

- **Smart contract events**: Parsed `CreateSubscription` and `CreateRedemption` events from SolvBTCRouter and SolvBTCLSTRouter contracts across Ethereum, BSC, Arbitrum, Base, and Avalanche networks
- **DeFi protocol events**: Parsed `Subscribe` events from OpenFundMarket contracts on supported chains  
- **Token transfer data**: Multi-chain token transfer events to identify fee payments to designated protocol addresses
- **Protocol state data**: Daily Net Asset Value (NAV) snapshots and share values from Solv's state management system
- **External price data**: End-of-day token price feeds for USD conversion across all supported tokens
- **Token metadata**: Token contract addresses, decimal configurations, and chain mappings
- **Protocol configuration**: Off-chain data containing fee structures, revenue ratios, collaboration addresses, and time-bound parameter changes

## 3. Step-by-step calculation

### Component A: Daily active user counting
- **Purpose**: Identifies and counts unique users who interact with Solv protocol daily
- **Logic**: Extracts user addresses from `CreateSubscription` and `CreateRedemption` events across all supported chains. Users are categorized as either Depositors (from subscription events) or Redeemers (from redemption events). Daily uniqueness is ensured by truncating event timestamps to day boundaries and using the `subscriber` and `redeemer` parameters from the respective events. Users are counted using HyperLogLog sketches for approximate distinct counting, with breakdowns available by chain, user type, and product ID.
- **Key fields**: `subscriber` and `redeemer` addresses from contract events, `block_timestamp` for daily grouping, chain identifiers for cross-chain aggregation

### Component B: Pool fee calculation  
- **Purpose**: Calculates management fees generated from Net Asset Value increases in Solv pools
- **Logic**: Identifies positive daily NAV changes by comparing current NAV values to previous day values using lag functions. These positive changes indicate fee generation from pool performance. The NAV increase is multiplied by the corresponding share value (normalized by dividing by 1e18) to determine the base fee amount. This amount is then adjusted using revenue ratios from protocol configuration data, where the total fee equals the base amount divided by (1 - revenue ratio), and protocol revenue equals the total fee multiplied by the revenue ratio.
- **Key fields**: `native_asset_value` from NAV data, `share_value` normalized to decimal format, `revenue_ratio` from configuration, time-bound configuration matching using `timestamp` boundaries

### Component C: Collaboration fee tracking
- **Purpose**: Captures fees from partnership collaborations where external projects deposit incentive tokens directly
- **Logic**: Monitors token transfers to designated collaboration addresses as specified in protocol configuration. These are off-chain partnerships where collaborating projects send tokens directly to Solv's designated addresses. The system tracks transfers to these addresses for specific tokens and applies the configured revenue ratio to determine the protocol's share of the collaboration fees. Address and token combinations are time-bound based on configuration timestamps.
- **Key fields**: `to_address` matching collaboration addresses, `token_address` for specific collaboration tokens, `value` representing transfer amounts, `revenue_ratio` applied to determine protocol share

### Component D: Redemption fee collection
- **Purpose**: Tracks fees collected when users redeem their positions from Solv pools
- **Logic**: Monitors token transfers to designated redemption fee addresses as configured in protocol settings. When users redeem positions, fees are automatically transferred to these addresses. The system identifies these transfers by matching destination addresses and token types against the redemption fee configuration, which specifies both addresses and tokens on a time-bound basis. All amounts transferred to these addresses are treated as redemption fees.
- **Key fields**: `to_address` matching redemption addresses, `token_address` for fee tokens, `value` representing fee amounts, time-bound configuration matching

### Component E: Subscription fee calculation
- **Purpose**: Calculates fees charged when users subscribe to Solv investment products
- **Logic**: Processes `Subscribe` events from OpenFundMarket contracts to calculate subscription fees. The fee is computed by multiplying the subscription amount by a factor derived from the difference between the current NAV and the base token value (represented as 10^decimals). This calculation is divided by 1e18 for normalization. Only subscriptions for pools where the `subscription_fee` flag is enabled in the configuration are included. The calculation accounts for the relationship between subscription amounts and NAV values at the time of subscription.
- **Key fields**: `value` from subscription events, `currency` token address, `poolId` for fee configuration lookup, NAV values for fee calculation, token `decimals` for normalization

### Final aggregation
- **Combining components**: All four fee types (pool fees, collaboration fees, redemption fees, subscription fees) are unioned together with daily timestamp truncation applied to transaction-based fees. Each fee type includes chain, token address, and amount information for consistent processing.
- **Currency conversion**: All fee amounts are converted to USD using end-of-day price feeds through the convert_to_usd_and_correct_decimals macro, which handles both decimal normalization and price conversion in a single step.
- **Time aggregation**: Data is filtered to include only dates from 2025-09-01 onward, representing the active period for fee collection. Daily boundaries are established using timestamp truncation to day level.
- **Final calculation**: The AFPU metric divides the sum of all daily fees (in USD) by the count of daily active users using the calculate_arpu macro. Missing data points are filled with zeros using the fill_zeros strategy. The result represents the average fee revenue generated per active user on each day.

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

Solv ProtocolSOLV

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape