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 Supply-side fees Methodology

## 1. Overview

Ren fees supply side measures the total fees collected by the Ren protocol from cross-chain bridge transfers, expressed in USD. This metric represents the protocol's revenue from facilitating asset transfers between different blockchain networks. The calculation applies time-based fee percentages to bridge transfer volumes, where all fees are considered supply-side since they represent revenue earned by the protocol for providing bridging services.

## 2. Data sources

- **Bridge contract events**: Parsed `LogBurn` and `LogMint` events from Ren Gateway contracts deployed across seven chains (Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism)
- **Contract event data**: Gateway contract event logs containing transfer amounts, transfer types, timestamps, and contract addresses
- **End-of-day price feeds**: Token price data used for USD conversion, accessed through alternative token addresses due to historical price feed availability limitations
- **Token metadata**: Decimal place information for proper amount normalization and display

## 3. Step-by-step calculation

### Component A: Bridge transfer extraction
- **Purpose**: Extract all mint and burn transactions from Ren Gateway contracts across supported chains
- **Logic**: Parse `LogBurn` and `LogMint` events from BTCGateway and ETHGateway contracts. Filter events to capture the `amount` field (labeled as `_amount` or `amount` depending on the contract), along with transaction metadata including timestamps, transaction hashes, and contract addresses. Each event represents either a mint operation (asset bridged into a chain) or burn operation (asset bridged out of a chain)
- **Key fields**: `block_timestamp`, `transaction_hash`, `account_address` (contract address), `transfer_type` (Mint or Burn), `transfer_amount`

### Component B: Token address mapping  
- **Purpose**: Map original token addresses to alternative addresses with reliable price feeds
- **Logic**: Apply a hardcoded mapping table that converts original Ren token contract addresses to alternative token addresses, primarily on Polygon. This mapping was necessary because reliable price feeds were not available for the original token addresses at the time of calculation. The mapping covers all supported tokens across all seven chains, ensuring consistent USD price conversion
- **Key fields**: `account_address` (original), `chain` (original), `alternative_token_address`, `alternative_chain`

### Component C: Fee percentage application
- **Purpose**: Calculate fee amounts by applying time-based percentage rules to transfer volumes
- **Logic**: Apply different fee percentages based on transfer type and date ranges. Mint fees have varied from 0.1% to 0.36% over time, with current rate at 0.2%. Burn fees range from 0.07% to 0.15% depending on the time period. The system uses hardcoded date ranges to determine which fee percentage applies to each transaction. Fee percentages changed multiple times between 2020 and 2022 as the protocol adjusted its pricing model
- **Key fields**: `transfer_type`, `timestamp`, `fee_percentage`, calculated `fees`

### Component D: USD conversion and decimal correction
- **Purpose**: Convert fee amounts to USD and normalize for token decimals
- **Logic**: Use end-of-day price feeds for the alternative token addresses to convert fee amounts from native token units to USD values. Apply decimal corrections based on each token's decimal places to ensure amounts are displayed in human-readable format rather than raw blockchain units
- **Key fields**: `token_address`, `chain_id`, `fees` (in USD)

### Final aggregation
- **Combining components**: Combine all processed fee data and group by chain and daily timestamps
- **Currency conversion**: All fees are converted to USD using end-of-day price feeds for the alternative token addresses
- **Time aggregation**: Results are aggregated daily with timestamp truncation to day boundaries  
- **Final calculation**: The metric sums all fees by chain and day, filling gaps with zeros where no bridge activity occurred. The final step renames the `fees` field to `fees_supply_side` since all Ren protocol fees are considered supply-side revenue earned by the protocol for providing bridging services

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

Portion of fees distributed to service providers or supply-side participants.

RenREN

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown