website

twitter

discord

github

Asset management

Rezerve

# Rezerve RZR stakers (daily) Methodology

## 1. Overview

The RZR stakers daily metric measures the number of unique addresses that hold active staking positions in Rezerve's staking system on any given day. This metric tracks engagement in Rezerve's staking protocol by counting addresses that own staking position NFTs (ERC721 tokens) issued by the AppStaking contracts. The calculation handles cross-chain scenarios where the same address may stake on multiple chains, treating them as a single unique staker to avoid double-counting.

## 2. Data sources

- **ERC721 transfer events**: Parsed `Transfer` events from Rezerve's AppStaking contracts deployed on Ethereum and Sonic blockchains
- **Blockchain timestamps**: Block timestamp data used to aggregate staking activity by day
- **Contract addresses**: AppStaking contract addresses on supported chains that issue staking position NFTs

## 3. Step-by-step calculation

### Component A: Staking position tracking
- **Purpose**: Track the creation, destruction, and transfer of staking position NFTs to determine account ownership
- **Logic**: Extract `Transfer` events from AppStaking contracts on Ethereum and Sonic chains. Process mints as transfers from the zero address (`0x0000000000000000000000000000000000000000`) to recipient addresses, representing new staking positions. Process burns as transfers from account addresses to the zero address, representing position closures. Process regular transfers between non-zero addresses as position ownership changes. Each event is converted to a balance change of +1 for recipients and -1 for senders, then aggregated by day and account address to get net balance changes.
- **Key fields**: `from` and `to` addresses from Transfer events, `block_timestamp` for daily aggregation, `amount` representing balance changes (+1 or -1)

### Component B: Balance calculation and forward filling
- **Purpose**: Calculate running balances for each account and maintain continuous daily history
- **Logic**: Apply a cumulative sum window function partitioned by chain and account address, ordered by timestamp, to calculate running balances from the daily balance changes. Use forward filling to propagate the most recent balance for accounts on days without transactions, ensuring continuous balance history for all accounts that have ever held staking positions.
- **Key fields**: `balance` representing cumulative staking position count per account, `timestamp` for daily boundaries, `account_address` and `chain` for partitioning

### Final aggregation
- **Combining components**: Count distinct account addresses with positive balances (greater than 0) on each day across all supported chains
- **Cross-chain deduplication**: Treat the same address staking on multiple chains as a single unique staker by aggregating all chains under a unified identifier
- **Time aggregation**: Use daily boundaries determined by truncating block timestamps to day level, excluding the current incomplete day
- **Final calculation**: The final metric value is the count of unique addresses holding at least one staking position NFT on each day, deduplicated across chains to represent true unique stakers in the Rezerve ecosystem

### Dimensional breakdowns
- **Project level**: Overall staker count across all chains with null chain and product identifiers
- **Chain level**: Staker count broken down by individual blockchain (Ethereum, Sonic) while maintaining cross-chain deduplication logic
- **Schema standardization**: Apply finalization macro to ensure consistent column naming, data types, and missing day handling with forward-fill strategy

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

Unique addresses holding an active RZR staking position on a given day.

RezerveRZR

RZR stakers (daily)

RZR stakers (daily)

Competitive landscape

Chain breakdown