edgeX is a high-performance decentralized perpetual futures and spot trading platform incubated by Amber Group, combining an off-chain matching engine with on-chain settlement. Its original venue ran on StarkEx zero-knowledge rollups and wound down in August 2026. edgeX V2 is a full rebuild on EDGE Chain, an application-specific Arbitrum rollup that settles to Ethereum, using Circle's CCTP for native USDC deposits and reaching a peak throughput of 300,000 orders per second at sub-100 millisecond order latency.

website

twitter

discord

Derivative exchanges

edgeX

# edgeX Revenue Methodology

## 1. Overview

Revenue measures the portion of fees that a project retains, as determined by its take rate. Fees generated by edgeX Perps are analyzed, and the retained portion is designated as protocol revenue. Operating expenses, token incentives, and cost of revenue are not deducted from this metric. Financial performance and protocol sustainability are evaluated using these captured earnings.

## 2. Data sources

- **External data**: Daily fee and revenue metrics retrieved from the edgeX public REST API, covering StarkEx and Edgechain

## 3. Step-by-step calculation

### Component A: API data extraction for edgeX Perps

- **Purpose**: Retrieve raw daily fee and revenue data from the edgeX public REST API
- **Logic**: Raw daily data is ingested from off-chain scraper sources for both V1 and V2 venues. The fields representing fee and revenue values are extracted along with their corresponding timestamps and venue identifiers.
- **Key fields**: `timestamp` (timing), `venue` (venue identifier), `chain_id` (chain identifier), `fee` (fee values), `revenue` (revenue values)

### Component B: Deduplication and validation

- **Purpose**: Ensure data integrity by selecting the latest and most accurate records
- **Logic**: Records are partitioned by day and venue, and deduplicated by selecting the latest entry based on the insertion timestamp. In cases of duplicate insertion times, the records with the highest fee and revenue values are retained. The data is then filtered to ensure only valid chain and project identifiers are included.
- **Key fields**: `inserted_at` (insertion timestamp), `fee` (fee values), `revenue` (revenue values)

### Component C: Revenue aggregation and zero-filling

- **Purpose**: Aggregate revenue for edgeX Perps and ensure continuous daily time series
- **Logic**: Revenue values are cast to high-precision numeric types and summed by day, product, and chain. The product identifier is mapped to edgeX Perps. A zero-filling strategy is applied to insert zero values for any days where no revenue data is reported, ensuring a continuous daily time series.
- **Key fields**: `revenue` (revenue values), `timestamp` (timing), `product_id` (product identifier), `chain_id` (chain identifier)

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

edgeXEDGE

Revenue

Revenue

Competitive landscape

Chain breakdown