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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for the Ren Protocol measures the average revenue generated per daily active user. However, since Ren operates as a decentralized bridge protocol without direct user fees, the ARPU consistently equals zero. The metric is calculated by dividing total daily revenue by the number of daily active users, providing a framework that could accommodate future revenue models while currently reflecting Ren's fee-free bridging service.

## 2. Data sources

- **Blockchain events**: Parsed `LogBurn` and `LogMint` events from Ren V1 gateway smart contracts across seven blockchain networks (Ethereum, BSC, Polygon, Fantom, Avalanche, Arbitrum, and Optimism)
- **Transaction data**: Gateway transaction records capturing cross-chain bridging operations, including mint operations (deposits) and burn operations (withdrawals)
- **External data**: End-of-day token price feeds from Polygon network, used as alternative price sources for tokens lacking reliable price data on their original chains
- **Token metadata**: Alternative token address mappings that redirect price lookups from original chains to Polygon equivalents for consistent pricing

## 3. Step-by-step calculation

### Component A: Daily active user calculation
- **Purpose**: Count unique users interacting with Ren bridge contracts daily
- **Logic**: Extract user addresses from Ren gateway event logs across all supported chains. Parse `LogBurn` events to identify withdrawers (users burning wrapped tokens) and `LogMint` events to identify depositors (users minting wrapped tokens). Extract user addresses from event parameters (`to` field variants like `to`, `_to`). Aggregate daily using HyperLogLog algorithm for efficient distinct counting across multiple dimensions including chain, user type, and product level
- **Key fields**: `user_address` from event parameters, `block_timestamp` for daily grouping, `transfer_type` for categorizing as mint or burn operations, `chain` for network identification

### Component B: Revenue calculation  
- **Purpose**: Calculate total daily revenue from protocol operations
- **Logic**: Set revenue to zero for all time periods and chains, reflecting Ren's design as a fee-free bridge protocol. While the system tracks bridge transfer volumes and maintains fee calculation infrastructure with historical fee percentages (ranging from 0.1% to 0.36% for different periods and operation types), actual revenue is recorded as zero
- **Key fields**: `revenue` set to 0, `timestamp` for daily aggregation, `chain_id` for network breakdown

### Component C: Token address mapping
- **Purpose**: Provide consistent price data access across chains
- **Logic**: Map original token addresses to alternative addresses on Polygon network where reliable price feeds were available. This mapping system was implemented because sufficient price feeds were not available on the original chains at the time of calculation. The mapping covers tokens across all supported networks and redirects price lookups to Polygon equivalents
- **Key fields**: `account_address` and `chain` for original token identification, `alternative_token_address` and `alternative_chain` for price lookup redirection

### Final aggregation
- **Combining components**: ARPU is calculated using the standard formula of revenue divided by daily active users. Since revenue is always zero, the resulting ARPU is zero across all time periods and dimensional breakdowns
- **Currency conversion**: Not applicable since revenue is zero, though the infrastructure supports USD conversion through end-of-day price feeds
- **Time aggregation**: Daily boundaries are established using timestamp truncation to day level, ensuring consistent daily user counts and revenue calculations
- **Final calculation**: ARPU equals total daily revenue (always $0) divided by daily active user count, consistently yielding $0 per user across all dimensions and time periods

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

RenREN

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape