Skip to main content
Global Fees Paid (GFP) is a unified view of every dollar of fees a token, pool, or trader generates, broken into five components, summed into a single total, and combined into a handful of derived metrics. The same five components appear across bar queries, token filters, event feeds, and launchpad subscriptions, so once you understand them here you’ll recognize them everywhere they’re surfaced.

What Global Fees Paid measures

GFP captures the full economic cost of activity on-chain. Not just the trading fee a pool charges, but everything paid to network validators, block builders, and (on rollups) the L1 chain that posts the data. Every field is denominated in USD and summed at the start of the query window.The five components are the same on every endpoint. What changes is the shape of the data: a single scalar per event, an array per bar, a pre-computed value over a time window, or a single-window snapshot. The endpoint coverage map below shows which shape you get where.

Endpoint coverage

This is the master map. Find the endpoint you’re using and follow the link to see the fields it exposes.

The five components

All five components are USD-denominated everywhere they appear in the schema. Some endpoints additionally expose the underlying native-unit values (wei on EVM, lamports on Solana). See per-transaction fee detail for that.

Derived metrics

Built from the five components, these surface the most common questions developers ask about fee data without making them do the arithmetic.
Ratios are null when their divisor is zero (no volume, no transactions, or no total fees). Always handle the null case in client code.

Classifications

Two categorical fields summarize the fee profile at a glance, useful for filtering, alerting, or labeling tokens in a UI without surfacing raw numbers.mevRiskLevel, based on mevToTotalFeesRatio:
  • low: builder tips are less than 3% of total fees
  • medium: between 3% and 30%
  • high: more than 30%
  • null: when totalFees is zero
feeRegimeClassification describes which fee component dominates:
  • gas-dominated: gas (base + priority + L1 data) is more than 50% of fees
  • mev-dominated: builder tips are more than 20% of fees
  • pool-fee-dominated: pool fees dominate
  • null: when fees are zero

Caveats and gotchas

A few things that are easy to miss and worth flagging up front:
  • Subscriptions only expose the five raw components. IndividualBarData (used by onBarsUpdated and onTokenBarsUpdated) does not include derived metrics or classifications. If you need totalFees or any ratio in a streaming context, compute it client-side or pull it from the corresponding query.
  • Launchpad feeToVolumeRatio1 is a Float, not a String. Everywhere else in the schema, ratio fields are returned as strings (to preserve precision on very small or very large values). On LaunchpadTokenEventOutput it’s a float. Your parsing layer needs to handle both.
  • Filter inputs are a subset of result fields. filterTokens returns 35 fee fields, but only seven of them are usable as filter inputs. The full list is in the token filtering section.
  • Component-level filters at shorter windows aren’t accepted as filter inputs. You can filter on totalFees5m but not builderTips5m. Component-level filters are only available for the 24h window (poolFees24).
  • Native-unit fields are chain-specific. On EventFeeData, fields like baseFeeNativeUnit are wei on EVM and lamports on Solana: same field name, different units. The USD-denominated parent fields don’t have this ambiguity.

Per-transaction fee detail

Every event returned by an event-feed endpoint carries a feeData object with both the USD-denominated GFP components and native-unit raw values. This is the most granular fee data the API exposes: one record per swap.USD components (same definitions as above): poolFees, baseFees, priorityFees, builderTips, l1DataFees, totalFees.Pool-fee detail:Native-unit gas detail (wei on EVM, lamports on Solana):Supplemental fee data: EventFeeData.supplementalFeeData is a union type carrying protocol-specific fields. It currently has two variants, both for Pump.fun cashback:
  • PumpCashbackFeeData for Pump V1 swaps. Fields: type (always "PumpCashback"), cashbackFeeBps, cashbackAmountLamports.
  • PumpAmmCashbackFeeData for Pump AMM swaps. Same field shape, with type = "PumpAmmCashback".
The maker/wallet endpoints (getTokenEventsForMaker, onEventsCreatedByMaker) are the simplest path to per-transaction fee detail for a specific wallet. Useful for trader analytics, MEV exposure tracking, or PnL accounting that includes gas costs.

Chart queries

getBars and getTokenBars return parallel arrays. The value at index i corresponds to the bar starting at timestamp t[i]. All twelve fields are exposed: the five components, totalFees, the four ratios, and both classifications.

Chart subscriptions

onBarsUpdated and onTokenBarsUpdated deliver one bar update at a time, so each fee field is a single scalar rather than an array. Only the five raw components are exposed here. Derived metrics and classifications are not.IndividualBarData is nested inside OnBarsUpdatedResponse.aggregates.{r1, r5, r15, r60, …}.{usd, token}. Resolution and currency are picked at the wrapper level, then the bar’s fields are fetched.
If you need totalFees, mevRiskLevel, or any ratio in a subscription context, compute it client-side from the five components or pull it from getBars / getTokenBars.

Token filtering

filterTokens and onFilterTokensUpdated return per-token results with fees pre-computed across five rolling windows ending at “now”: 5 minutes, 1 hour, 4 hours, 12 hours, and 24 hours. Each window suffix gives you a different field name.Seven fields × five windows = 35 fee-related fields per token. The base names are:
  • poolFees{w}, baseFees{w}, priorityFees{w}, builderTips{w}, l1DataFees{w}: the five components
  • totalFees{w}: the sum
  • feeToVolumeRatio{w}: the ratio
Where {w} is one of 5m, 1, 4, 12, 24. So the fully-enumerated set includes poolFees5m, poolFees1, poolFees4, poolFees12, poolFees24, baseFees5m, …, feeToVolumeRatio24.

Filter inputs

The TokenFilters input accepts a subset of the result fields. Only seven inputs are filterable:Component-level filters at shorter windows (e.g. builderTips24, baseFees1) are not accepted as filter inputs.

Ranking attributes

All 35 result fields are usable as ranking.attribute values for sorting:

Launchpad subscriptions

onLaunchpadTokenEvent and onLaunchpadTokenEventBatch deliver real-time updates on launchpad tokens (Pump.fun, Bonk, MeteoraDBC, Pump Mayhem, etc.). Fee fields populate on eventType: "Updated" events; other event types (Deployed, Created, Migrated, Completed, and the Unconfirmed* variants) carry the field shape but values may be null.Only the 1-hour window is exposed:
onLaunchpadTokenEventBatch is the more efficient choice when you don’t need event-by-event delivery. It returns batched arrays in a single message.