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 Revenue Methodology

## 1. Overview

The Ren Protocol revenue metric measures the protocol's direct revenue generation, which is consistently zero. While Ren Protocol facilitates cross-chain bridging and generates fees from these operations, all fees are distributed to node operators who secure the network rather than accruing to the protocol itself. The metric is calculated by processing bridge transfer events from Ren gateway contracts, applying historical fee rates, but ultimately setting revenue to zero to reflect the protocol's decentralized fee distribution model.

## 2. Data sources

The calculation utilizes several key data sources:

- **Smart contract events**: Parsed `LogBurn` and `LogMint` events from Ren gateway contracts (BTCGateway and ETHGateway) deployed across Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism
- **Bridge transfer data**: Transaction amounts, timestamps, and transfer types (mint vs burn operations) from cross-chain bridge transactions
- **Token metadata**: Token contract addresses, decimal precision information, and symbol mappings
- **End-of-day price feeds**: Historical token prices for USD conversion, accessed through alternative token addresses on Polygon due to price feed availability constraints
- **Blockchain transaction data**: Block timestamps, transaction hashes, and log indices for event ordering and deduplication

## 3. Step-by-step calculation

### Component A: Bridge transfer extraction
- **Purpose**: Extract all bridge transfer events from Ren gateway contracts across multiple blockchain networks
- **Logic**: The system queries parsed smart contract events from BTCGateway and ETHGateway contracts deployed on seven different chains. For each chain, it captures both `LogBurn` events (when users burn tokens to initiate cross-chain transfers) and `LogMint` events (when tokens are minted on the destination chain). Each event contains the transfer amount, block timestamp, transaction hash, contract address, and transfer direction. The data includes version information to distinguish between different iterations of the Ren protocol
- **Key fields**: `block_timestamp` for temporal analysis, `transfer_amount` for fee calculation basis, `transfer_type` (Mint or Burn) for applying correct fee rates, `account_address` for contract identification, and `chain` for network-specific processing

### Component B: Token address mapping
- **Purpose**: Map original Ren token addresses to alternative addresses with reliable price feeds
- **Logic**: Due to limited price feed availability for original Ren token addresses at the time of calculation, the system uses a comprehensive mapping table that associates each original token address with an alternative token address, typically on Polygon. This mapping covers over 130 token address pairs across all supported chains. The mapping ensures that fee calculations can be accurately converted to USD values using available price feeds from the alternative token addresses
- **Key fields**: `account_address` as the original contract address, `chain` as the source blockchain, `alternative_token_address` for price lookups, and `alternative_chain` (primarily Polygon) for price feed queries

### Component C: Fee rate application
- **Purpose**: Calculate fee amounts by applying historically accurate fee percentages to transfer volumes
- **Logic**: The system applies time-based fee percentages that varied throughout Ren Protocol's operation. For Mint operations, fees ranged from 0.1% (early 2020) to 0.36% (late 2021), with specific rates including 0.2%, 0.25%, 0.15%, and returning to 0.2% by 2022. For Burn operations, fees ranged from 0.1% initially to 0.15% in mid-2021, dropping to 0.07% in late 2021, then settling at 0.1% by 2022. The system uses conditional logic to apply the correct fee percentage based on the transfer date and type
- **Key fields**: `timestamp` for determining applicable fee period, `transfer_type` for selecting Mint or Burn fee rates, `transfer_volume` as the basis for fee calculation, and `fees` as the calculated fee amount

### Component D: USD conversion and decimal correction
- **Purpose**: Convert fee amounts from token units to standardized USD values
- **Logic**: Using the alternative token addresses identified in the mapping process, the system retrieves end-of-day price feeds to convert fee amounts to USD. The conversion process includes decimal correction to account for different token precisions (typically 8 or 18 decimal places for bridge tokens). This ensures all fee amounts are expressed in comparable USD terms regardless of the underlying token's decimal structure
- **Key fields**: `token_address` for price lookups, `fees` in native token units, and USD-denominated `fees` after conversion and decimal correction

### Final aggregation
- **Combining components**: Bridge transfer data flows through token address mapping, then fee calculation, followed by USD conversion, with all components joined on transaction identifiers and timestamps
- **Currency conversion**: End-of-day price feeds applied using alternative token addresses from the mapping table, with decimal precision standardized across all tokens
- **Time aggregation**: Daily aggregation using timestamp truncation to day boundaries, ensuring consistent time-series data
- **Final calculation**: After processing all bridge fees and converting to USD, the final revenue metric is explicitly set to zero for all records. This reflects Ren Protocol's operational model where bridge fees are distributed entirely to node operators rather than retained as protocol revenue. The zero revenue assignment occurs after all fee calculations to maintain the underlying fee data for other metrics while accurately representing the protocol's revenue model

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

RenREN

Revenue

Revenue

Competitive landscape

Chain breakdown