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 Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interact with Solv protocol within any 30-day rolling period. This metric captures user engagement across Solv's Bitcoin-related financial products by tracking subscription (deposit) and redemption activities. The calculation uses HyperLogLog data structures to efficiently count unique users across multiple dimensions and chains, providing insights into protocol adoption and user retention patterns.

## 2. Data sources

The MAU calculation relies on the following raw data sources:

- **Blockchain events**: Parsed `CreateSubscription` and `CreateRedemption` events from Solv protocol smart contracts across Ethereum, BSC, Arbitrum, Base, and Avalanche networks
- **Smart contract data**: Event logs from `SolvBTCRouter` and `SolvBTCLSTRouter` contracts that handle Bitcoin-backed token subscriptions and redemptions
- **Transaction metadata**: Block timestamps and transaction hashes associated with user interactions
- **User classification data**: Event parameters that identify subscriber and redeemer addresses along with their interaction types

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identify and classify unique user addresses from Solv protocol interactions
- **Logic**: Parse blockchain event logs from Solv router contracts across five supported chains. Extract user addresses from `CreateSubscription` events using the `subscriber` parameter and from `CreateRedemption` events using the `redeemer` parameter. Classify subscribers as 'Depositor' user type and redeemers as 'Redeemer' user type. Capture block timestamps, transaction hashes, and chain identifiers for each interaction
- **Key fields**: `user_address` (subscriber or redeemer), `user_type` (Depositor or Redeemer), `chain`, `block_timestamp`, `transaction_hash`, `product_id`

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily unique user counts as the foundation for MAU rolling windows
- **Logic**: Group user addresses by day using timestamp truncation to daily boundaries. Create distinct user counts grouped by timestamp, chain, user type, and product ID dimensions. Apply incremental processing logic to efficiently update only recent time periods while maintaining data consistency
- **Key fields**: `timestamp` (daily truncated), `timestamp_grain` (day), `chain`, `user_type`, `product_id`, `user_dau` (unique user address)

### Component C: HyperLogLog structure creation
- **Purpose**: Convert daily user sets into efficient data structures for unique counting across time windows
- **Logic**: Transform daily active user data into HyperLogLog structures using 15-bit precision. Initialize HLL sketches for each combination of day, chain, user type, and product ID. This probabilistic approach enables efficient merging of user sets across multiple days while maintaining reasonable accuracy for unique user counting
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `timestamp_grain`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling periods for each target date to calculate monthly active users
- **Logic**: Generate a complete datespine of daily timestamps covering the full analysis period. For each target day, create a 30-day lookback window by joining with the previous 29 days of data. Use the joinday approach to map each target timestamp to its corresponding 30-day period, ensuring no gaps in the time series even when daily data is missing
- **Key fields**: `timestamp` (target date), `joinday` (dates within 30-day window), combined with all HLL and dimension fields

### Component E: Multi-dimensional MAU aggregation
- **Purpose**: Calculate unique user counts across different analytical dimensions
- **Logic**: Merge HyperLogLog structures within each 30-day window and extract final unique user counts. Create separate aggregations for four analytical levels: project-level (combining all dimensions), chain-level (grouped by blockchain), user type-level (Depositor vs Redeemer), and product ID-level. Use HLL merge operations to combine sketches and extract final cardinality estimates
- **Key fields**: `dimensions` (aggregation level), `chain_id`, `user_type`, `product_id`, `user_mau` (unique user count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set with appropriate dimension labeling and null values for non-applicable dimension fields
- **Time aggregation**: Apply monthly partitioning boundaries with daily granularity for the underlying 30-day rolling calculations
- **Final calculation**: Extract unique user counts from merged HyperLogLog structures using `hll_count.extract()` to produce the final MAU values for each dimension and time period. Apply zero-fill strategy for missing data points to maintain consistent time series output

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

Unique revenue-generating users over a rolling 30-day window.

Solv ProtocolSOLV

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown