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

## 1. Overview

The Ren protocol expenses metric measures the operational costs incurred by the protocol. For Ren, expenses are defined as token incentives paid to network participants. The calculation methodology reveals that Ren protocol has zero token incentive expenses - they are explicitly hardcoded to zero across all time periods and chains.

## 2. Data sources

The metric uses the following underlying data sources to establish the dimensional framework:

- **Ren Gateway contract events**: Parsed `LogBurn` and `LogMint` events from Ren v1 BTCGateway and ETHGateway smart contracts deployed across multiple blockchains
- **Multi-chain bridge events**: Bridge transfer events from Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism networks
- **Token metadata mapping**: Hardcoded mapping table that links original token addresses to alternative token addresses on different chains for price feed compatibility
- **End-of-day price feeds**: Token price data used for USD conversion in the underlying fee calculations (though not directly used for expenses)

## 3. Step-by-step calculation

### Component A: Bridge transfer data extraction
- **Purpose**: Extract bridge activity to establish the dimensional structure for the expenses metric
- **Logic**: The system processes `LogBurn` and `LogMint` events from Ren v1 Gateway contracts across seven blockchains. These events capture cross-chain bridge transfers with transfer amounts, types (mint or burn), timestamps, and token addresses. The events are sourced from both BTCGateway contracts (for Bitcoin-related transfers) and ETHGateway contracts (for Ethereum-related transfers). Transfer amounts are extracted from event fields like `amount` and `_amount` depending on the specific contract implementation.
- **Key fields**: `block_timestamp`, `transaction_hash`, `account_address`, `transfer_amount`, `transfer_type`

### Component B: Token address mapping
- **Purpose**: Map original token addresses to alternative addresses on different chains for price compatibility
- **Logic**: The system applies a hardcoded mapping table that associates each original token contract address and chain with an alternative token address on a different chain (primarily Polygon). This mapping was implemented because reliable price feeds were not available for the original token addresses at the time of calculation. The mapping covers all supported chains and ensures consistent pricing across the protocol.
- **Key fields**: `account_address`, `chain`, `alternative_token_address`, `alternative_chain`

### Component C: Fee calculation framework
- **Purpose**: Calculate bridge fees to establish the time series and dimensional structure
- **Logic**: The system calculates fees from bridge transfers by applying time-varying fee percentages based on transfer type and date ranges. Mint operations have fee percentages ranging from 0.1% to 0.36% across different time periods, while burn operations have fees from 0.07% to 0.15%. The fees are converted to USD using end-of-day price feeds and corrected for token decimals. However, these fees are only used to establish the dimensional structure (timestamps, chains, products) and are not included in the expenses calculation.
- **Key fields**: `timestamp`, `chain_id`, `product_id`, `fees`

### Component D: Token incentives calculation
- **Purpose**: Calculate token incentive expenses paid by the protocol
- **Logic**: The system sets token incentives to zero for all records. This is implemented as a hardcoded value of 0, indicating that Ren protocol does not pay token incentives to network participants. The calculation pulls the dimensional structure (timestamp, chain_id, product_id) from the fees model but explicitly sets the `token_incentives` field to 0 across all time periods and chains.
- **Key fields**: `token_incentives` (always 0)

### Final aggregation
- **Combining components**: The final expenses metric simply renames the `token_incentives` field as `expenses`, maintaining the zero value across all records
- **Currency conversion**: No currency conversion is needed since token incentives are zero
- **Time aggregation**: Daily time boundaries are maintained from the underlying bridge activity data
- **Final calculation**: Expenses = Token incentives = 0 for all time periods, chains, and products. The metric applies gap-filling with zero values for any missing time periods and filters results based on chain availability.

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

Total project operating and incentive expenses.

RenREN

Expenses

Expenses

Competitive landscape

Chain breakdown