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

## 1. Overview

Ren fees measures the total USD value of fees generated by the Ren protocol's bridge operations. Ren operates a decentralized bridge allowing users to transfer assets like Bitcoin and Ethereum across different blockchains through mint and burn operations. The protocol charges fees as a percentage of the transfer volume, with rates that have changed over time. This metric calculates those fees by applying the appropriate fee percentages to bridge transfer volumes based on the transfer type and timestamp, then converting the results to USD.

## 2. Data sources

- **Ren V1 gateway contract events**: Parsed `LogMint_event` and `LogBurn_event` from Ren V1 gateway contracts across Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism
- **Blockchain transaction data**: Transaction hashes, block timestamps, and log indices from the various blockchain networks where Ren operates
- **Token metadata**: Token address mappings and decimal information for proper normalization
- **External price data**: End-of-day token price feeds for USD conversion (using alternative token addresses on Polygon due to price feed availability constraints)
- **Hardcoded fee schedules**: Time-based fee percentage configurations maintained within the calculation logic

## 3. Step-by-step calculation

### Component A: Bridge transfer extraction
- **Purpose**: Extract all mint and burn operations from Ren V1 gateway contracts across supported chains
- **Logic**: Parse `LogMint_event` and `LogBurn_event` from Ren V1 gateway contracts on Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism. Extract transfer amounts from the `amount` field, determine transfer type from event name, and capture transaction metadata including block timestamp and transaction hash. Each transfer is classified as either a Mint operation (assets moving into a blockchain) or Burn operation (assets moving out of a blockchain).
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for uniqueness, `account_address` for the gateway contract, `transfer_type` (Mint or Burn), `transfer_amount` for fee calculation base

### Component B: Token address mapping
- **Purpose**: Map original token addresses to alternative addresses for reliable price feeds
- **Logic**: Join bridge transfer data with a predefined mapping that converts original token addresses and chains to alternative addresses on Polygon. This mapping was created because reliable price feeds were not available for some tokens on their original chains during the calculation period. The mapping maintains the original chain information as `true_chain` while using alternative addresses for price conversion.
- **Key fields**: `account_address` and `chain` for mapping lookup, `alternative_token_address` and `alternative_chain` for price feed compatibility, `true_chain` to preserve original blockchain information

### Component C: Fee percentage application
- **Purpose**: Calculate fees by applying time-based percentage rates to transfer volumes
- **Logic**: Apply fee percentages based on transfer type and timestamp using hardcoded schedules. For Mint operations, rates have varied from 0.1% to 0.36% across different time periods from protocol launch through February 2022. For Burn operations, rates have ranged from 0.07% to 0.15% with their own timeline. The fee calculation uses a case statement that matches the transfer type and checks if the timestamp falls within the specified date ranges to apply the correct percentage.
- **Key fields**: `transfer_type` for rate selection, `timestamp` for date range matching, `transfer_volume` as the base amount, calculated `fees` as the result

### Component D: USD conversion and decimal correction
- **Purpose**: Convert fee amounts to standardized USD values
- **Logic**: Use the `convert_to_usd_and_correct_decimals` macro to convert calculated fees from native token amounts to USD values using end-of-day price feeds. The macro handles both decimal normalization (correcting for token decimal places) and currency conversion using the alternative token addresses established in the previous mapping step.
- **Key fields**: `fees` as input amount, `token_address` for price lookup, converted `fees` in USD

### Final aggregation
- **Combining components**: All fee calculations are aggregated by combining the USD-converted fees from all chains and transfer types, maintaining daily granularity through timestamp truncation to day level
- **Currency conversion**: USD conversion occurs using end-of-day price feeds matched to the alternative token addresses, with decimal correction applied to ensure proper value representation
- **Time aggregation**: Fees are aggregated to daily boundaries using `timestamp_trunc(block_timestamp, day)`, creating daily summaries of total fees generated
- **Final calculation**: The `finalize_metric_fees` macro standardizes the output schema, validates data integrity, fills any gaps with zeros using a fill strategy, and applies chain availability filters to ensure consistent reporting across the supported blockchain networks

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

Total value users pay to use a protocol (gross fees, user-paid fees).

RenREN

Fees

Fees

Competitive landscape

Chain breakdown