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

## 1. Overview

The Marinade ARPU (Average Revenue Per User) metric measures the average daily revenue generated per active user across Marinade's Marinade Liquid Staking staking products. It answers the business question: "How much revenue does Marinade generate on average from each daily active user?" The metric is calculated by dividing total daily revenue by the number of daily active users, providing insight into user monetization effectiveness across Marinade's Marinade Liquid Staking staking, Marinade Native staking, and validator selection products.

## 2. Data sources

The calculation uses several types of raw blockchain data from Solana:

- **Smart contract instruction logs**: Parsed Marinade Finance protocol instructions including deposits (`Finance_Deposit_instruction`), stake account deposits (`Finance_DepositStakeAccount_instruction`), withdrawals (`Finance_WithdrawStakeAccount_instruction`), claims (`Finance_Claim_instruction`), unstaking orders (`Finance_OrderUnstake_instruction`), and Marinade Liquid Staking unstaking (`Finance_LiquidUnstake_instruction`)
- **Staking infrastructure events**: Solana stake account authority change records that track when stake accounts are delegated to or withdrawn from Marinade validators
- **Token transfer events**: Solana token transfer logs filtered by recipient addresses to capture fee payments
- **Token mint events**: Solana token mint records for mSOL (Marinade's Marinade Liquid Staking staking token) during reward distribution
- **Bond settlement data**: Parsed bond claim instructions (`Bond_ClaimSettlement_instruction`, `Bond_ClaimSettlementV2_instruction`) for validator reward payments
- **Account balance snapshots**: Daily Marinade Native SOL balance changes for stake accounts and reserve addresses
- **Transaction metadata**: Solana transaction and block information including signers, timestamps, and ordering data
- **External price data**: End-of-day token price feeds for USD conversion
- **Token metadata**: Token configuration data for decimal precision correction

## 3. Step-by-step calculation

### Component A: Daily active user identification

- **Purpose**: Identify unique users interacting with Marinade products daily
- **Logic**: Extract user addresses from transaction signers across three product categories. For Marinade Liquid Staking staking, capture signers from parsed Marinade Finance instruction logs including deposits, withdrawals, claims, unstaking orders, and Marinade Liquid Staking unstaking transactions. For Marinade Native staking, identify users through stake account authority changes where accounts are delegated to specific Marinade validator addresses (`stWirqFCf2Uts1JBL1Jsd3r6VBWhgnpdPxCTe1MFjrq`, `ex9CfkBZZd6Nv9XdnoDmmB45ymbu4arXVk7g5pWnt3N`) or withdrawn from those validators. For validator selection (Marinade Select product), track authority changes to the specific Marinade Select validator address (`STNi1NHDUi6Hvibvonawgze8fM83PFLeJhuGMEXyGps`). Classify users as depositors when they delegate stake or withdrawers when they remove stake.
- **Key fields**: `transaction_signer` as user address, `block_timestamp` for daily aggregation, `product_id` for product categorization, `user_type` for interaction classification

### Component B: User aggregation with HyperLogLog

- **Purpose**: Efficiently count distinct daily active users across multiple dimensions
- **Logic**: Group user interactions by day and apply HyperLogLog initialization to create scalable distinct user counts. Generate aggregations across four dimensions: total project level (all users combined), by chain (Solana), by user type (depositor vs withdrawer), and by product (Marinade Liquid Staking, Marinade Native, Marinade Select). Use HyperLogLog merge operations to combine user sets without double-counting users who interact with multiple products. Extract final distinct user counts from HyperLogLog structures.
- **Key fields**: `timestamp` truncated to day, `user_dau` as distinct user count, `dimensions` for aggregation level, `chain_id`, `product_id`, `user_type`

### Component C: Bond revenue calculation

- **Purpose**: Calculate validator reward revenue allocated to Marinade
- **Logic**: Extract bond claim settlement amounts from parsed bond instructions where validators pay rewards to treasury stake accounts. Join bond payments with stake account dimension data to identify which product each stake account belongs to based on authority patterns and timing. Calculate total bond payments to treasury accounts daily, then allocate proportionally to Marinade Liquid Staking and Marinade Native products based on their relative TVL shares. TVL is calculated from daily Marinade Native SOL balances across all product stake accounts excluding treasury and reserve accounts.
- **Key fields**: `amount` from bond claims, `account_address` for stake accounts, `product_id` for allocation, `block_timestamp` for daily aggregation

### Component D: Marinade Liquid Staking staking reward fees

- **Purpose**: Capture protocol fees from Marinade Liquid Staking staking rewards
- **Logic**: Identify mSOL token mints to treasury accounts during reward update transactions (`Finance_UpdateActive_instruction`, `Finance_UpdateDeactivated_instruction`). These mints represent Marinade's fee share when staking rewards are distributed and the mSOL supply is increased. Filter token mint events by mSOL token address and treasury account recipients, matching transaction IDs with reward update instructions.
- **Key fields**: `amount` of mSOL minted, `to_address` as treasury account, `token_address` for mSOL, `transaction_id` for matching with reward instructions

### Component E: Instant withdrawal fees

- **Purpose**: Calculate fees from immediate unstaking transactions
- **Logic**: Capture mSOL token transfers to treasury accounts during Marinade Liquid Staking unstaking transactions. When users perform instant unstaking through `Finance_LiquidUnstake_instruction`, they pay a fee in mSOL tokens that gets transferred to Marinade's treasury. Match token transfers by recipient address and transaction ID with Marinade Liquid Staking unstaking instructions to isolate fee payments from other transfers.
- **Key fields**: `amount` of mSOL transferred as fees, `to_address` as treasury account, `transaction_id` for instruction matching

### Component F: Revenue aggregation and conversion

- **Purpose**: Combine all revenue streams and convert to USD
- **Logic**: Union bond revenues, Marinade Liquid Staking staking reward fees, and instant withdrawal fees into a single daily revenue stream. Group by day, chain, product, and token address. Apply decimal correction to convert from Marinade Native blockchain token units to human-readable amounts (e.g., converting lamports to SOL, accounting for mSOL decimal places). Convert all amounts to USD using end-of-day price feeds, matching token addresses to price records by date.
- **Key fields**: `revenue` as corrected and USD-converted amounts, `timestamp` for daily boundaries, `chain_id`, `product_id`, `token_address`

### Final aggregation

- **Combining components**: Join aggregated daily revenue with aggregated daily active users by matching on date and applying project-level totals. The revenue represents total daily USD revenue across all products and the user count represents distinct daily active users across all products
- **Currency conversion**: All revenue amounts are converted to USD using end-of-day token price feeds with proper decimal correction applied before price multiplication
- **Time aggregation**: Both revenue and user metrics use daily boundaries with timestamp truncation to day level, ensuring consistent time alignment between numerator and denominator
- **Final calculation**: Divide total daily revenue in USD by total daily active user count to produce average revenue per user in USD. Apply gap filling with zeros for days with no activity and chain availability filtering to exclude periods before data collection began

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

MarinadeMNDE

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape