website

twitter

discord

github

Asset management

Rezerve

# Rezerve RZR stakers (weekly) Methodology

## 1. Overview

The RZR stakers weekly metric measures the average number of unique addresses holding Rezerve staking positions over a 7-day rolling window. This metric tracks engagement in Rezerve's staking protocol by counting unique addresses that own at least one staking position NFT, providing a smoothed view of staking participation trends. The calculation uses a cross-chain approach where the same address staking on multiple chains (Ethereum and Sonic) is counted as a single staker.

## 2. Data sources

- **ERC721 transfer events**: Parsed `Transfer` events from Rezerve's AppStaking contracts deployed on Ethereum and Sonic chains
- **Staking position contracts**: Smart contracts that mint NFTs representing individual staking positions in the Rezerve protocol
- **Blockchain event logs**: Transaction logs capturing mints (from zero address), burns (to zero address), and transfers of staking position NFTs

## 3. Step-by-step calculation

### Component A: Extract staking position transfers
- **Purpose**: Identify all staking position movements from blockchain events
- **Logic**: Extract `Transfer` events from Rezerve's AppStaking contracts on Ethereum and Sonic chains. Each event represents a change in staking position ownership, where positions are represented as ERC721 NFTs. Process both minting events (transfers from zero address) and burning events (transfers to zero address), as well as regular transfers between addresses.
- **Key fields**: Block timestamp for daily aggregation, `to` address for recipients, `from` address for senders, with zero address filtering to identify mints and burns

### Component B: Calculate daily balance changes
- **Purpose**: Convert transfer events into daily balance deltas for each address
- **Logic**: Transform each transfer event into balance change records. For recipients (non-zero `to` address), add +1 to their daily balance. For senders (non-zero `from` address), subtract -1 from their daily balance. Aggregate all balance changes by day, chain, and account address to get net daily position changes.
- **Key fields**: Daily timestamp truncation, chain identifier, account address, and aggregated `amount` representing net position changes

### Component C: Calculate running staking balances
- **Purpose**: Track cumulative staking positions for each address over time
- **Logic**: Apply running sum calculation using window functions to determine each address's total staking position balance on each day. This cumulative approach ensures that an address's current staking position count reflects all historical mints, burns, and transfers. Fill forward missing days to maintain continuous balance tracking for all active addresses.
- **Key fields**: Daily timestamp, account address, chain, and cumulative `balance` representing total staking positions held

### Component D: Count daily unique stakers
- **Purpose**: Determine the number of unique addresses actively staking each day
- **Logic**: Count distinct addresses with positive staking position balances on each day. Apply cross-chain deduplication logic where the same address staking on both Ethereum and Sonic chains is counted as a single staker. Filter to include only addresses with balance greater than zero and exclude the current day to ensure data completeness.
- **Key fields**: Daily timestamp, unique account count as `rzr_stakers`, with Ethereum as the representative chain for cross-chain aggregation

### Component E: Create 7-day rolling windows
- **Purpose**: Generate time-based windows for weekly averaging calculations
- **Logic**: Create a datespine covering all days from the first staking event to yesterday. For each day in the datespine, generate a 7-day lookback period using timestamp arrays. Join this window structure with daily staker counts to create overlapping 7-day periods for each day. This ensures every day has a complete 7-day historical context for averaging.
- **Key fields**: Primary timestamp for the window end date, `joinday` timestamps for the 7-day lookback period, and daily staker counts for averaging

### Final aggregation
- **Combining components**: Join the 7-day window structure with daily staker counts, matching each window day with corresponding daily staker data. Average the daily staker counts across each 7-day window to create the weekly metric value.
- **Currency conversion**: Not applicable - this is a count-based metric measuring number of stakers
- **Time aggregation**: Calculate 7-day rolling averages where each day represents the average of that day plus the previous 6 days. Time boundaries use daily timestamp truncation with UTC day boundaries.
- **Final calculation**: The final metric value is the arithmetic mean of daily unique staker counts across each 7-day rolling window, broken down by project-level (cross-chain aggregate) and chain-level dimensions, with fill-forward strategy applied for missing values and chain availability filtering for data quality assurance.

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

7-day rolling average of unique addresses holding active RZR staking positions.

RezerveRZR

RZR stakers (weekly)

RZR stakers (weekly)

Competitive landscape

Chain breakdown