Render is a non-custodial exchange protocol built on Ethereum and other adjacent blockchains.

Render Network is a protocol that facilitates a compute marketplace between GPU providers and GPU requestors. Render Network was founded by Jules Urbach and launched publicly in 2020.

RENDER holders own and govern the protocol. They do not currently take a cut of the total computing fees paid by creators (revenue). Render Network is backed by parent company OTOY, inc., and their investors include Multicoin Capital, Solana Foundation, Kenetic etc.

website

twitter

etherscan

github

discord

docs

DePIN

Render Network

# Render Network Treasury Methodology

## 1. Overview

The Render Network treasury metric measures the total USD value of tokens held by Render Network's treasury addresses on Ethereum. This metric provides insight into the protocol's financial resources and asset management by tracking the real-time value of all tokens held in designated treasury wallets. The calculation aggregates token balances across multiple treasury addresses, converts them to USD, and excludes certain internal or non-relevant tokens from the total.

## 2. Data sources

The treasury calculation relies on several core data sources:

- **Ethereum ERC20 token transfers**: Parsed `Transfer` events from Ethereum that track token movements into and out of treasury addresses
- **Ethereum transaction traces**: Transaction-level data that captures token balance changes and internal transfers
- **End-of-day token price feeds**: Daily USD price data for all tokens held in treasury addresses
- **Token metadata**: Token contract information including symbols, decimal places, and contract addresses used for identification and conversion

## 3. Step-by-step calculation

### Component A: Treasury balance tracking

- **Purpose**: Track token balance changes for designated Render Network treasury addresses
- **Logic**: Monitor three specific treasury addresses on Ethereum (`0xb6e39e540e3472e927001bbbf77ffb5ab357b0e0`, `0xe9f57628059ac658901ce42a83fe09272a62a6c8`, `0x9ad51cffff91a24b352c11293bdb8810f0da137d`) by analyzing all ERC20 `Transfer` events where these addresses are either senders or receivers. The system captures balance changes by processing inbound transfers as positive balance changes and outbound transfers as negative balance changes. Each balance change is recorded with its timestamp, token address, and amount.
- **Key fields**: The component tracks `account_address` (treasury wallet), `token_address` (specific ERC20 token), `balance` (net change in token amount), `timestamp` (when the change occurred), and `chain_id` (Ethereum)

### Component B: Token filtering and exclusion

- **Purpose**: Remove internal or non-relevant tokens from treasury calculations
- **Logic**: Apply exclusion filters to remove seven specific token addresses from the treasury calculation. These excluded tokens likely represent internal protocol tokens, wrapped versions, or other assets that shouldn't count toward the public treasury value. The filtering ensures only legitimate external tokens are included in the final treasury metric.
- **Key fields**: Uses `token_address` to identify and exclude specific tokens: `0x54d1a6019f73cee87d7761aaf042ca9081f212b9`, `0x06b803465a1faa0dc30d771d44c17b3c2677cdb0`, and five other addresses

### Component C: Cumulative balance calculation

- **Purpose**: Convert balance changes into running token balances over time
- **Logic**: Transform the balance change events into cumulative balances using window functions that sum all balance changes for each token at each address up to each point in time. This creates a time series showing the actual token holdings at any given moment rather than just the individual transactions.
- **Key fields**: Maintains `timestamp`, `account_address`, `token_address`, and calculates cumulative `balance` as the running sum of all previous balance changes

### Component D: Data continuity and forward-filling

- **Purpose**: Ensure continuous time series data without gaps
- **Logic**: Apply forward-filling logic to propagate the last known balance forward for days when no transactions occurred. This creates a complete daily time series where each treasury address shows its token holdings for every day, even when no transactions happened that day.
- **Key fields**: Maintains all dimensions (`timestamp_grain`, `chain_id`, `account_address`, `token_address`) and forward-fills the `balance` field

### Component E: USD conversion

- **Purpose**: Convert token balances to USD values using daily price data
- **Logic**: Join the token balance data with end-of-day price feeds to convert each token holding to its USD equivalent. Only include tokens with positive balances and available price data. The conversion multiplies the token balance by the corresponding USD price for that specific day and token.
- **Key fields**: Combines `balance` from token data with `price_usd` from price feeds to calculate `amount` (USD value), matching on `timestamp`, `chain_id`, and `token_address`

### Final aggregation

- **Combining components**: Sum all USD token values across all treasury addresses and all tokens to create a single daily treasury metric value
- **Currency conversion**: Uses end-of-day USD prices to ensure consistent valuation timing across all tokens
- **Time aggregation**: Aggregates to daily granularity with each day showing the total USD value of all tokens held across all treasury addresses
- **Final calculation**: The final treasury value equals the sum of (token_balance × token_price_usd) for all tokens held by all treasury addresses, excluding the seven filtered token addresses

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

Total value of a project's onchain treasury, including its native token.

Render NetworkRENDER

Treasury

Treasury

Competitive landscape

Chain breakdown