website

twitter

discord

github

Asset management

Rezerve

# Rezerve Operations funding Methodology

## 1. Overview

Operations funding represents the portion of bond sales revenue allocated to fund Rezerve protocol operations. This metric captures 10% of all bond sales revenue, reflecting the protocol's operational fee structure. It answers the business question of how much revenue is being generated to sustain protocol operations and development activities. The calculation takes total bond sales in USD and applies a fixed 10% allocation rate.

## 2. Data sources

- **Sonic blockchain events**: Parsed `AppBondDepository_CreateBond_event` and `AppBondDepository_BondCreated_event` logs from Rezerve's bond depository contracts
- **Transaction data**: Sonic blockchain transaction records containing bond creation and deposit events
- **External data**: End-of-day token price feeds for USD conversion and token metadata for decimal precision handling
- **Contract data**: Rezerve AppBondDepository contract addresses and bond-related smart contract events

## 3. Step-by-step calculation

### Component A: Bond creation tracking
- **Purpose**: Identifies all valid bonds and their associated quote tokens for deposit tracking
- **Logic**: Extracts `AppBondDepository_CreateBond_event` events from Sonic blockchain to establish a registry of created bonds. Each event contains a unique `id` (bond identifier) and `quoteToken` address that defines which token can be used for deposits. The contract address represents the bond depository contract managing the bond.
- **Key fields**: `id` as bond identifier, `quoteToken` as the deposit token address, contract `address` as bond depository

### Component B: Bond deposit processing  
- **Purpose**: Captures all actual deposits made to bonds with amounts and pricing
- **Logic**: Extracts `AppBondDepository_BondCreated_event` events from Sonic blockchain representing completed bond purchases. Each event includes the bond `id`, deposit `amount`, and `price` paid. These events are joined with the bond creation data to associate each deposit with its corresponding quote token.
- **Key fields**: `id` as bond identifier, `amount` as deposit quantity, `price` as purchase price, matched with `token_address` from bond creation

### Component C: USD conversion and aggregation
- **Purpose**: Converts bond deposit amounts to USD values and aggregates by day
- **Logic**: Processes deposit amounts by correcting for token decimal precision and converting to USD using end-of-day price feeds. Deposits are aggregated by daily timestamp boundaries, chain, and product to calculate total daily bond sales. The conversion accounts for each token's specific decimal configuration to ensure accurate value calculations.
- **Key fields**: `amount` converted to USD, `timestamp` truncated to daily grain, `chain_id` and `product_id` for grouping

### Final aggregation
- **Combining components**: Bond creation events provide token context, deposit events provide transaction data, and these are joined on bond identifiers to create complete deposit records with token information
- **Currency conversion**: USD conversion using end-of-day token price feeds with decimal precision correction applied to ensure accurate monetary values
- **Time aggregation**: Daily boundary aggregation using timestamp truncation to day level for consistent reporting periods
- **Final calculation**: Operations funding equals total daily bond sales multiplied by 0.1 (representing exactly 10% allocation to protocol operations). The calculation uses safe multiplication to handle potential null values and applies schema validation with zero-filling for any data gaps.

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

Share of bond-sales proceeds allocated to protocol operations.

RezerveRZR

Operations funding

Operations funding

Competitive landscape

Chain breakdown