Overcollateralized nodes custody and transfer funds between blockchains and receive burn & mint fees from traders (supply-side fees).

Ren is a non-custodial interoperability protocol built on Ethereum and other blockchains. Ren was founded by Tayiang Zhang & Loong Wang and launched in 2017. Ren is currently only in redeeming-mode, due to their exposure to the effects of Alameda Research's failure.

REN tokenholders own and govern the protocol. They do not currently take a cut of the total mint/burn fees paid by traders (revenue). Ren's investors include Polychain, FBG Capital, BlockVC, etc.

governance

github

twitter

discord

etherscan

website

Bridges

# Ren Earnings Methodology

## 1. Overview

Ren earnings represents the net profit generated by the Ren protocol from its cross-chain bridging operations. The metric is calculated as revenue minus expenses, where both components are currently set to zero, resulting in zero earnings across all time periods. This indicates that Ren operates as a fee-neutral bridge where collected fees are not retained as protocol revenue.

## 2. Data sources

The calculation relies on several key data sources:

- **Ren v1 gateway smart contract events**: Parsed `LogBurn` and `LogMint` events from Ren v1 gateway contracts deployed across seven blockchains (Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism)
- **Bridge transfer data**: Transaction hashes, block timestamps, contract addresses, and transfer amounts extracted from gateway events
- **End-of-day token price feeds**: Daily closing prices sourced primarily from Polygon network due to price feed availability constraints
- **Alternative token address mappings**: A hardcoded mapping table that maps original bridge contract addresses to alternative token addresses on Polygon for reliable price lookup
- **Token metadata**: Decimal precision information for proper amount normalization during USD conversion

## 3. Step-by-step calculation

### Component A: Bridge transfer extraction
- **Purpose**: Extract all bridging activity from Ren v1 gateway contracts across multiple chains
- **Logic**: Query `LogBurn` and `LogMint` events from Ren v1 gateway contracts on Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism. Extract key fields including block timestamps, transaction hashes, contract addresses, and transfer amounts. Classify transfers as either "Mint" (deposits into the bridge) or "Burn" (withdrawals from the bridge)
- **Key fields**: `block_timestamp`, `transaction_hash`, `address` (contract address), `transfer_type`, `transfer_amount`

### Component B: Alternative token mapping
- **Purpose**: Map original contract addresses to alternative tokens on Polygon for price lookup
- **Logic**: Join bridge transfers with a hardcoded mapping table that associates each original contract address and chain combination with an alternative token address on Polygon. This mapping exists because reliable price feeds were not available for tokens on the original chains at the time of calculation
- **Key fields**: `account_address`, `chain`, `alternative_token_address`, `alternative_chain`

### Component C: Fee calculation
- **Purpose**: Calculate fees collected by the protocol based on transfer volumes and time-based fee schedules
- **Logic**: Apply different fee percentages to transfer amounts based on transfer type and date ranges. For Mint operations, fees range from 0.1% to 0.36% across different time periods. For Burn operations, fees range from 0.07% to 0.15% across different periods. Fee percentages are hardcoded with specific start and end dates for each rate change
- **Key fields**: `fees` (calculated as transfer_amount × fee_percentage), `timestamp`, `transfer_type`

### Component D: USD conversion
- **Purpose**: Convert fee amounts from native token units to USD values
- **Logic**: Use end-of-day price feeds to convert calculated fees to USD. Apply decimal correction to normalize token amounts based on each token's decimal precision. Price data is sourced using the alternative token addresses on Polygon
- **Key fields**: `fees` (in USD), `token_address`, `chain_id`

### Component E: Revenue calculation
- **Purpose**: Determine protocol revenue from bridging operations
- **Logic**: Set revenue to zero for all records. This indicates that Ren does not retain any portion of collected fees as protocol revenue
- **Key fields**: `revenue` (always 0)

### Component F: Token incentives and expenses
- **Purpose**: Calculate protocol expenses including token incentive payments
- **Logic**: Set token incentives to zero for all records, indicating no incentive payments are made. Total expenses equal token incentives, which results in zero expenses
- **Key fields**: `token_incentives` (always 0), `expenses` (always 0)

### Final aggregation
- **Combining components**: Revenue and expenses components are combined using the earnings calculation macro
- **Currency conversion**: All amounts are already converted to USD during the fee calculation step
- **Time aggregation**: Data is aggregated to daily granularity using timestamp truncation to day boundaries
- **Final calculation**: Earnings equals revenue minus expenses, which equals 0 minus 0, resulting in zero earnings for all time periods. Missing dates are filled with zero values using the "fill_zeros" strategy

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

Net profit (also profits, net income, profitability) — revenue remaining after subtracting expenses.

RenREN

Earnings

Earnings

Competitive landscape