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 revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user on the Solv protocol. Solv is a Bitcoin liquid staking and yield protocol that operates across multiple blockchains. ARPU is calculated by dividing total daily revenue by daily active users (DAU), providing insight into the protocol's revenue efficiency and user monetization. The calculation captures revenue from pool management fees, collaboration incentives, redemption fees, and subscription fees across Ethereum, BSC, Arbitrum, Base, and Avalanche networks.

## 2. Data sources

The ARPU calculation relies on several key data sources:

- **Blockchain events**: Parsed `CreateSubscription` and `CreateRedemption` events from `SolvBTCRouter` and `SolvBTCLSTRouter` contracts across Ethereum, BSC, Arbitrum, Base, and Avalanche networks
- **Token transfer data**: Multi-chain token transfer events used to track fee collection to designated addresses
- **Contract events**: Parsed `OpenFundMarket_Subscribe` events for subscription fee calculations
- **Oracle data**: Daily Net Asset Value (NAV) and share value data from Solv's oracle systems
- **External configuration**: Fee configuration data including revenue ratios, receive addresses, and redemption addresses from external scraper systems
- **Price feeds**: End-of-day token price feeds for USD conversion
- **Token metadata**: Token contract addresses, decimal places, and chain information

## 3. Step-by-step calculation

### Component A: Daily active users calculation
- **Purpose**: Count unique users who interact with the protocol daily through subscriptions or redemptions
- **Logic**: Extract user addresses from `CreateSubscription` events (classified as "Depositor" user type) and `CreateRedemption` events (classified as "Redeemer" user type) across five supported blockchains. Aggregate addresses to daily granularity using timestamp truncation to day boundaries. Use HyperLogLog sketches for efficient unique user counting across different dimensional breakdowns including project-level, chain-level, user type, and product level aggregations
- **Key fields**: `subscriber` and `redeemer` addresses from blockchain events, `block_timestamp` for temporal aggregation, `chain` for multi-chain support

### Component B: Pool management fee revenue  
- **Purpose**: Calculate revenue from pool management fees based on Net Asset Value increases
- **Logic**: Identify positive daily NAV changes by comparing current NAV with previous day's NAV using lag window functions. Handle oracle errors by defaulting NAV to token decimal power when "invalid time" errors occur. Multiply NAV increases by corresponding share values (adjusted from 1e18 scale) to get pool fees. Apply revenue ratio adjustments to separate total fees into protocol revenue and supply-side fees. Join with fee configuration data using temporal validity windows based on timestamp ranges
- **Key fields**: `native_asset_value` from oracle data, `share_value` for fee calculation, `revenue_ratio` for protocol share

### Component C: Collaboration fee revenue
- **Purpose**: Track off-chain incentive token revenues from partnership arrangements  
- **Logic**: Monitor token transfers to designated receive addresses specified in fee configuration data. Apply revenue ratios to determine protocol's share of collaboration incentives. Match transfers to configuration using address matching and temporal validity windows. Aggregate transfer amounts by day and convert to revenue using specified revenue sharing ratios
- **Key fields**: `receive_address` from configuration, `value` from token transfers, `revenue_ratio` for protocol share calculation

### Component D: Redemption fee revenue
- **Purpose**: Calculate fees collected when users redeem their positions
- **Logic**: Track token transfers to designated redemption fee addresses specified in configuration data. Match transfers to configuration using temporal validity windows to ensure correct fee structure is applied. Aggregate daily transfer amounts to redemption addresses across all supported chains
- **Key fields**: `redemption_address` from configuration, transfer `value` amounts, temporal matching using `timestamp` ranges

### Component E: Subscription fee revenue
- **Purpose**: Calculate fees from user subscriptions based on NAV differentials
- **Logic**: Extract subscription amounts from `OpenFundMarket_Subscribe` events and match with pools that have subscription fees enabled in configuration. Calculate fee amounts by multiplying subscription values by the difference between current NAV and base currency unit (10^token_decimals), divided by 1e18 scaling factor. Join with daily NAV data and token metadata for accurate calculations
- **Key fields**: `value` from subscription events, `native_asset_value` for NAV-based calculation, token `decimals` for base unit calculation

### Final aggregation
- **Combining components**: Sum all four revenue streams (pool fees, collaboration fees, redemption fees, subscription fees) by day, chain, and token address. Apply data cutoff filter to include only revenue from September 1, 2025 onwards
- **Currency conversion**: Convert all token amounts to USD using end-of-day price feeds and correct for token decimal places using the `convert_to_usd_and_correct_decimals` transformation
- **Time aggregation**: Aggregate both revenue and user data to daily boundaries using timestamp truncation to day level  
- **Final calculation**: Divide total daily USD revenue by daily active user count using the `calculate_arpu` macro, which performs the division and handles edge cases like zero user days

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

Solv ProtocolSOLV

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape