website

twitter

github

discord

Lending

Dolomite

# Dolomite Revenue Methodology

## 1. Overview

Dolomite revenue represents the protocol's earnings from two primary sources: interest fees collected from lending operations and option exercise fees from the oARB (option on ARB tokens) product. The metric calculates the protocol's net revenue share after accounting for supply-side fee distributions to liquidity providers. This provides insight into Dolomite's business model performance across its multi-chain lending platform on Arbitrum, Base, Ink, Berachain, and Ethereum.

## 2. Data sources

The calculation relies on several types of blockchain data and external feeds:

- **DolomiteMargin contract events**: Parsed events from Dolomite's core margin trading contract across Arbitrum, Base, Ink, Berachain, and Ethereum, including balance updates, index updates, and fee configuration changes
- **Lending operation events**: `LogIndexUpdate` events tracking borrow and supply index changes that determine interest accrual, and various balance update events (`LogTrade`, `LogDeposit`, `LogWithdraw`, `LogTransfer`, `LogLiquidate`, `LogBuy`, `LogSell`, `LogVaporize`) capturing lending activity
- **Fee configuration events**: `LogSetEarningsRate` events for global fee settings and `LogSetEarningsRateOverride` events for market-specific fee overrides that determine revenue sharing between protocol and liquidity providers
- **Market setup events**: `LogAddMarket` events that establish new lending markets and map market IDs to underlying tokens
- **oARB option events**: VesterProxy contract events including `VestingPositionCreated` for option creation and `PositionClosed` for option exercises with ETH payments
- **Price data**: End-of-day token price feeds for USD conversion and Dolomite's internal market price data as backup pricing
- **Token metadata**: Token symbols, decimals, and addresses for proper calculation scaling and identification

## 3. Step-by-step calculation

### Component A: Interest fee revenue calculation
- **Purpose**: Calculates protocol revenue from lending interest fees after deducting liquidity provider shares
- **Logic**: Tracks borrow index changes from `LogIndexUpdate` events which represent interest accrual over time. For each index update, identifies all outstanding loans (positions with negative balances) that existed during that period by matching order IDs. Calculates interest fees by multiplying the par amount of each loan by the borrow index delta. Applies the appropriate fee split to determine protocol revenue share, checking first for market-specific overrides from `LogSetEarningsRateOverride` events, then falling back to global settings from `LogSetEarningsRate` events. The protocol keeps the portion defined by (1 - supply_side_fee_share) while the remainder goes to liquidity providers
- **Key fields**: `par_amount` represents loan principal amounts scaled by token decimals, `delta_borrow_index` calculated as (current borrow index - previous borrow index) / 1e18, `supply_side_fee_share` determining the split between protocol and liquidity providers

### Component B: oARB option exercise revenue
- **Purpose**: Captures revenue from users exercising ARB token options by paying ETH fees
- **Logic**: Monitors `PositionClosed` events from the VesterProxy contract where users exercise their oARB positions. Each closure event contains the ETH amount paid (`ethCostPaid`) which represents direct revenue to the protocol. Matches closed positions with their original creation events from `VestingPositionCreated` to ensure proper tracking. Converts ETH payments to USD using end-of-day price feeds for the WETH token on Arbitrum
- **Key fields**: `revenue_amount` from the ETH cost paid during position closure, `vesting_id` for linking closed positions to their creation events

### Component C: Market and token data enrichment
- **Purpose**: Provides essential reference data for proper calculation scaling and USD conversion
- **Logic**: Uses `LogAddMarket` events to map market IDs to underlying token addresses and retrieve token metadata including symbols and decimals. Joins with token reference data to ensure accurate decimal scaling when converting raw amounts to human-readable values. For interest fees, applies token decimals to scale par amounts correctly. For oARB revenues, uses WETH token information for proper ETH amount scaling
- **Key fields**: `market_id` linking to specific lending markets, `token_address` and `token_decimals` for proper amount scaling, `token_symbol` for identification

### Final aggregation
- **Combining components**: Both revenue streams are combined using UNION ALL, with interest fee revenue calculated as `interest_fees_amount_usd * (1 - supply_side_fee_share)` and oARB revenue taken directly as `revenue_amount_usd`. Each component maintains the same output schema with timestamp, account address, chain, and token information
- **Currency conversion**: USD conversion uses end-of-day price feeds as the primary source, with Dolomite's internal market prices serving as backup when external feeds are unavailable. Market prices are scaled using the formula `market_price / 10^(36 - token_decimals)` to account for Dolomite's internal price representation
- **Time aggregation**: All events are aggregated to daily boundaries using timestamp truncation to day level, with the `timestamp_grain` field set to 'day' for consistency
- **Final calculation**: The combined revenue streams are processed through the `finalize_metric_revenue` macro which standardizes the output format, applies fill strategies for missing dates, and ensures consistent metric structure. Chain availability filters are applied to exclude data from chains that may not be fully operational during certain time periods

*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.

DolomiteDOLO

Revenue

Revenue

Competitive landscape

Chain breakdown