Stakers deposit funds into Marinade and receive a return on investment in the form of staking rewards (supply-side fees).

Marinade is a non-custodial staking protocol built on Solana. Marinade was co-founded by Lucio Tato and launched in 2021.

MNDE tokenholders own and govern the protocol. They currently take a cut of the total staking rewards earned by the protocol (revenue).

governance

github

twitter

discord

website

Liquid staking

Marinade

# Marinade Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interact with Marinade Finance's staking products within rolling 30-day periods. Marinade operates three distinct staking products on Solana: Marinade Liquid Staking staking (mSOL token), Marinade Native staking (direct validator delegation), and Marinade Select staking (curated validator set). The metric uses HyperLogLog approximate counting to efficiently calculate unique users across large datasets and provides dimensional breakdowns by product, user type, and chain.

## 2. Data sources

- **Solana blockchain transaction logs**: Complete transaction records including timestamps, signers, and instruction data
- **Marinade Finance smart contract instruction events**: Parsed instruction events for Marinade Liquid Staking staking operations including `Deposit`, `DepositStakeAccount`, `WithdrawStakeAccount`, `Claim`, `OrderUnstake`, and `LiquidUnstake` instructions
- **Solana Marinade Native stake account authority records**: System-level records of stake account authority changes showing when accounts are delegated to or removed from validators
- **Marinade validator authority addresses**: Specific Solana addresses representing Marinade's validator authorities for Marinade Native staking (`stWirqFCf2Uts1JBL1Jsd3r6VBWhgnpdPxCTe1MFjrq`, `ex9CfkBZZd6Nv9XdnoDmmB45ymbu4arXVk7g5pWnt3N`) and Marinade Select staking (`STNi1NHDUi6Hvibvonawgze8fM83PFLeJhuGMEXyGps`)

## 3. Step-by-step calculation

### Component A: Marinade Liquid Staking staking user identification
- **Purpose**: Identifies users interacting with Marinade's Marinade Liquid Staking staking product (mSOL)
- **Logic**: Extracts transaction signers from parsed Marinade Finance smart contract instruction events. Monitors six key instruction types: `Deposit` (users depositing SOL for mSOL), `DepositStakeAccount` (users depositing existing stake accounts), `WithdrawStakeAccount` (users withdrawing as stake accounts), `Claim` (users claiming delayed unstaking), `OrderUnstake` (users initiating unstaking), and `LiquidUnstake` (users performing immediate unstaking). Transaction signers from deposit-related instructions are classified as Depositors, while those from withdrawal/unstaking instructions are classified as Withdrawers.
- **Key fields**: `block_timestamp` for activity timing, `transaction_id` for deduplication, `transaction_signer` as user identifier, instruction type determines user classification

### Component B: Marinade Native staking user identification
- **Purpose**: Identifies users interacting with Marinade's Marinade Native staking product through direct validator delegation
- **Logic**: Analyzes Solana Marinade Native stake account authority changes to detect when users delegate stake accounts to Marinade's Marinade Native staking validators. Uses window functions to compare current and previous authority values for each stake account. When a stake account's authority changes to one of Marinade's Marinade Native validator addresses (`stWirqFCf2Uts1JBL1Jsd3r6VBWhgnpdPxCTe1MFjrq` or `ex9CfkBZZd6Nv9XdnoDmmB45ymbu4arXVk7g5pWnt3N`), the transaction signer is classified as a Depositor. When authority changes away from these addresses, the signer is classified as a Withdrawer.
- **Key fields**: `authority_value` and `previous_authority_value` for delegation tracking, `transaction_signer` as user identifier, `block_timestamp` for timing

### Component C: Marinade Select staking user identification
- **Purpose**: Identifies users interacting with Marinade's Marinade Select staking product (curated validator set)
- **Logic**: Similar to Marinade Native staking but monitors a single specific validator authority (`STNi1NHDUi6Hvibvonawgze8fM83PFLeJhuGMEXyGps`). Tracks stake account authority changes to detect when users delegate to or withdraw from this Marinade Select validator. Users are classified as Depositors when delegating to the Marinade Select authority and Withdrawers when removing delegation.
- **Key fields**: `authority_value` and `previous_authority_value` for delegation detection, `transaction_signer` as user identifier, `block_timestamp` for activity timing

### Component D: Daily active user aggregation
- **Purpose**: Consolidates all user interactions into daily unique user counts
- **Logic**: Unions all three product user datasets and truncates timestamps to daily boundaries. Creates distinct combinations of date, chain, user type, product ID, and user address. This eliminates duplicate users who perform multiple transactions within the same day while preserving their classification by product and user type.
- **Key fields**: `timestamp` truncated to day, `chain_id`, `product_id`, `user_type`, `user_address`

### Component E: HyperLogLog sketch creation
- **Purpose**: Converts daily user data into probabilistic data structures for efficient MAU calculation
- **Logic**: Groups daily user data by timestamp, chain, user type, and product ID. Initializes HyperLogLog sketches with precision parameter 15 for each group, containing the unique user addresses for that day and dimension combination. This enables approximate distinct counting across large datasets without storing individual user addresses.
- **Key fields**: `hll` sketches containing compressed user address data, grouping dimensions for later aggregation

### Component F: Rolling 30-day window creation
- **Purpose**: Creates a framework for calculating 30-day rolling MAU values
- **Logic**: Generates a complete datespine covering all days in the analysis period, then cross-joins with a 30-day lookback window for each day. For every target date, creates relationships to all days within the preceding 30-day period (including the target date). This ensures MAU calculations capture exactly 30 days of user activity and handle periods with no activity.
- **Key fields**: `timestamp` for target MAU date, `joinday` for each day within the 30-day window

### Component G: Window-based HLL aggregation
- **Purpose**: Merges daily HLL sketches within each 30-day window
- **Logic**: Joins the rolling window framework with daily HLL sketches, matching on the joinday relationships. For each target timestamp and dimension combination, collects all HLL sketches from the corresponding 30-day period. Merges these sketches using HyperLogLog union operations to create a single sketch representing unique users across the entire 30-day window.
- **Key fields**: Merged `hll` sketches representing 30-day unique users, preserved dimension attributes

### Final aggregation
- **Combining components**: Creates four dimensional views of MAU data: project-level (all dimensions collapsed), by chain, by user type, and by product ID. Each view applies HLL merge operations to combine sketches across the collapsed dimensions and extracts final approximate unique user counts.
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows aligned to daily boundaries, with each day's MAU representing unique users active in that day plus the previous 29 days
- **Final calculation**: Extracts approximate distinct user counts from merged HLL sketches using `hll_count.extract()`, applies schema standardization through the `finalize_metric_user_mau` macro, and fills missing periods with zero values to ensure complete time series data

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

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

MarinadeMNDE

Active users (monthly)

Active users (monthly)

Competitive landscape