Users buy NET on Uniswap or mint it through bond sales against the treasury, then stake it to receive sNET. The Distributor mints new NET each 8-hour epoch and the staking contract rebases sNET so every staked balance grows proportionally. The dividend rate is a fixed function of the premium of NET's market price to NAV: zero at or below NAV, scaling linearly to 0.45% per epoch at a 1.75x premium.

NetNet is a reserve-backed token protocol on Robinhood Chain, built on the OlympusDAO v1 architecture. Its treasury holds USDG as the sole reserve asset, with an on-chain invariant that every NET is backed by at least 1 USDG of risk-free value. Idle treasury USDG earns yield in Morpho, capped at 70% of the balance. The protocol also runs a set of separate payout desks and a real-world bond desk.

NET holders are the protocol's shareholders. NetNet Capital Management operates without a policy committee — the dividend formula and the 1 USDG backing floor are fixed on-chain and cannot be modified by governance.

website

twitter

docs

Asset management

NetNet

# DEX trading volume methodology

## 1. Overview

DEX trading volume is the total value of trades involving a specific asset executed on decentralized exchanges, broken out by the exchange and product where the trade was executed (venue). Integrated venues include Uniswap, Aerodrome, PancakeSwap, and Fluid, among others, with coverage expanding as more are added.

## 2. Data sources

- **EVM chain events**: Swap and trade events from decentralized exchange contracts, covering EVM-compatible chains (Ethereum, Arbitrum, Base, Polygon, Optimism, and others)
- **Solana instructions**: Swap and trade instructions from decentralized exchange programs, covering Solana
- **Hyperliquid native spot**: Spot trading data from Hyperliquid
- **Asset metadata**: Token addresses and decimal precision
- **External data**: End-of-day price feeds

## 3. Step-by-step calculation

### Component A: Extract trade events and instructions

- **Purpose**: Retrieve raw trade data from decentralized exchange contracts, programs, and native spot feeds.
- **Logic**: On EVM-compatible chains, swap and trade events are parsed from decentralized exchange contracts. On Solana, swap and trade instructions are parsed from decentralized exchange programs. For each trade, the raw amounts of both traded tokens (the token sold and the token bought) are extracted along with the pool address, chain, and product identifier. For Hyperliquid, native spot trading volume is retrieved directly.
- **Key fields**: `amount_0` (raw quantity of first token), `amount_1` (raw quantity of second token), `token_address_0` (address of first token), `token_address_1` (address of second token), `timestamp` (block timestamp), `trading_volume` (raw trading volume for native spot)

### Component B: Normalize amounts and apply valuation

- **Purpose**: Normalize token quantities and calculate the USD value of the trade.
- **Logic**: Raw token amounts are normalized by decimal precision retrieved from asset metadata. Normalized amounts are multiplied by end-of-day price feeds from the price pipeline. To mitigate wash trading and mispricing, a conservative valuation is typically applied where the total trading volume of the trade is determined by taking the lesser USD value of the two legs (the token sold and the token bought). However, for trades involving exactly one tokenized stock, the valuation is determined solely by the tokenized-stock leg to prevent mispricing from unpriced counterparties. Hyperliquid native spot trading volume is retrieved pre-valued and is not subject to this valuation logic.
- **Key fields**: `trading_volume` (calculated USD value of the trade), `token_address_0` (address of first token), `token_address_1` (address of second token)

### Component C: Resolve trade legs and final aggregation

- **Purpose**: Attribute trading volume to each individual asset and aggregate by venue.
- **Logic**: Each trade is typically split into two distinct legs to represent both sides of the transaction, where one leg is categorized as a sell for the token sold by the trader, and the other leg is categorized as a buy for the token bought by the trader. Hyperliquid native spot trading volume is excluded from this split as it is retrieved pre-split by trade direction. The trading volume is then aggregated by summing the USD values across trade directions, assets, chains, and venues.
- **Key fields**: `trade_direction` (direction of the trade leg), `token_address` (resolved token address), `trading_volume` (aggregated USD volume)

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

Value of trades involving the asset on decentralized exchanges, counted on both sides of each trade, broken out per venue.

NetNetNET

DEX trading volume

DEX trading volume

Competitive landscape

Venue breakdown