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 (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interacted with the Solv protocol within any 7-day period. This metric tracks user engagement across Solv's Bitcoin-related financial products, counting users who perform subscription (deposit) or redemption (withdrawal) activities. The calculation uses HyperLogLog approximation for efficient computation across multiple blockchain networks and provides breakdowns by chain, user type, and product dimensions.

## 2. Data sources

- **Blockchain events**: Parsed `CreateSubscription` and `CreateRedemption` events from Solv protocol contracts (`SolvBTCRouter` and `SolvBTCLSTRouter`) across Ethereum, BSC, Arbitrum, Base, and Avalanche networks
- **Event parameters**: User addresses (`subscriber` and `redeemer` parameters), transaction timestamps, and transaction hashes from these contract events
- **Chain metadata**: Blockchain network identifiers and transaction context data

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Extract and classify unique user addresses from Solv protocol interactions
- **Logic**: Parse `CreateSubscription` and `CreateRedemption` events from both `SolvBTCRouter` and `SolvBTCLSTRouter` contracts across all supported chains. Extract the `subscriber` parameter from `CreateSubscription` events and classify these users as "Depositor" type. Extract the `redeemer` parameter from `CreateRedemption` events and classify these users as "Redeemer" type. Include transaction metadata such as `block_timestamp`, `transaction_hash`, and chain identifier for each user interaction.
- **Key fields**: `user_address` (the wallet address), `user_type` (Depositor or Redeemer), `chain` (blockchain network), `product_id` (currently null), `block_timestamp` (transaction timing)

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily unique user counts and prepare data for weekly rolling calculations
- **Logic**: Group user interactions by truncated day timestamp, chain, user type, and product dimensions. Remove duplicate users within each day by using distinct operations on user addresses. Initialize HyperLogLog sketches for each daily user set with precision level 15 to enable efficient approximate counting in subsequent aggregation steps. This creates the foundation dataset of daily active users across all dimensions.
- **Key fields**: `timestamp` (day-truncated), `timestamp_grain` (set to 'day'), `chain`, `user_type`, `product_id`, `user_dau` (unique user address), `hll` (HyperLogLog sketch)

### Component C: Rolling window construction
- **Purpose**: Create 7-day rolling windows for weekly active user calculation
- **Logic**: Generate a complete datespine covering all days from the earliest user activity to the current date. For each date in the datespine, create associations with the 6 preceding days plus the current day to form 7-day windows. Join these rolling windows with the daily active user data to identify which users were active during each 7-day period. This approach ensures consistent weekly calculations even when some days have no user activity.
- **Key fields**: `timestamp` (current day), `joinday` (each day in the 7-day window), daily user data with HLL sketches

### Component D: Weekly aggregation by dimensions
- **Purpose**: Calculate unique weekly active users across different dimensional breakdowns
- **Logic**: Merge HyperLogLog sketches across each 7-day window to count users who were active at least once during the week. Create four distinct dimensional views: project-level (overall WAU across all chains), chain-level (WAU per individual blockchain), user type-level (WAU for Depositors vs Redeemers), and product-level (WAU per product, currently null). For each dimension, aggregate HLL sketches using merge operations and extract the final approximate unique count. Set unused dimensional fields to null for each breakdown.
- **Key fields**: `timestamp`, `timestamp_grain`, `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_wau` (final weekly count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set with consistent schema structure
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Weekly boundaries are created as 7-day rolling windows, with each day representing the end date of a week that includes the 6 preceding days
- **Final calculation**: The final `user_wau` value represents the approximate count of unique users who performed at least one subscription or redemption transaction within any 7-day period, calculated using HyperLogLog merge operations across daily user sets

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

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

Solv ProtocolSOLV

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown