Solana fees versus revenue

Two numbers show up on every serious Solana dashboard. They are not the same thing, and treating them as synonyms is how people write bad takes about “cheap chain” or “validators print.”

Fees are what users (and bots) pay to land work on chain — base fees, priority fees, and related user-side cost. Revenue, in the sense Solana Compass and similar trackers use it, is what the producing side earns from that activity: those fees plus Jito tips and other MEV-path payments that never look like a classic “priority fee” line item in a wallet UI.

Compass states it bluntly on the fees analytics page: fees land txs; revenue is fees plus Jito tips. Everything below follows that split. Source for the week’s aggregates: solanacompass.com/analytics/fees (2–7 Aug 2026). Figures move every day — treat them as a worked example, not eternal constants.

Click to zoom

The accounting identity

user_cost_to_land  ≈  base_fees + priority_fees  (+ any app-level fees)

validator_side_revenue  ≈  protocol_fee_share
                         + Jito_tips (and similar out-of-band bids)

// Compass-style:
revenue  ≈  fees + jito_tips

Protocol fee design still matters (base per signature, priority as microlamports × CU, burn vs reward splits). Tips sit beside that: a SOL transfer to a tip account inside a Jito bundle (or Jito single-send path), auctioned by the Block Engine into Jito-Solana leaders. Related builder recipe: CU price vs Jito tips.

A concrete week

Tips were roughly 17% of revenue (9.42 / 56.01) and about 20% of the fee total (9.42 / 46.59) in that window. Revenue exceeded fees by the full tip stack. If your model stops at “network fees,” you miss a material validator (and staker) cashflow line.

What the fee charts are really saying

1. Stacked fee breakdown

Base vs priority vs tips over time answers: is the week dominated by ordinary CU bidding or by MEV-path tips? A tip-heavy stack means contention and searcher activity; a priority-heavy stack means the local fee market is doing more of the work inside normal transactions.

2. Volume vs average fee

Hundreds of millions of transactions with a low median total fee (Compass showed on the order of ~5.7K lamports median total fee in that window) sit next to a savage upper tail (p99 priority fee on the order of hundreds of thousands of lamports). Averages lie. Product UX should anchor on medians; execution systems should provision for percentiles.

3. Fee per CU and per writable account

Compass-style unit metrics (example levels from that week: fee per CU around the high teens of lamports, revenue per CU higher once tips are included; fee per writable account in the tens of thousands of lamports) restate the local fee market: you pay for compute and write locks, not a flat “tx tax.” Bloated account metas are a fee bug.

4. Fees vs economic volume

When fees are divided by swap notional, Solana often prints sub-basis-point settlement cost on real DeFi flow (that window’s Compass card was on the order of ~$77 fees per $1M swapped, ~0.008%). That is the right chart for “is the chain expensive for commerce?” — not average fee on a bot-heavy tx count.

Jito: small share of txs, large share of the gap

Tip percentiles in that dump ran from ~1K lamports at p10 up through median a few thousand, then p90/p95/p99 into meaningful SOL for competitive flow. Same lesson as priority fees: the distribution is the product.

Compass’s native vs Jito comparison also showed similar average compute with different fee shapes — because a large part of the Jito bid is the tip, not the priority-fee field. Reading only “average fee” on Jito txs understates what searchers paid.

Who should care about which number

Builder implications

• Estimate inclusion cost as a stack: base + priority (+ tip if you use Jito). Document which legs you pay.
• Don’t tip out of habit on low-contention user transfers — tips are for auctions and multi-tx atomicity.
• Dual-route when you need both Jito leaders and the rest of the schedule (bundle or Jito send + staked RPC + CU price).
• Simulate and cap so failed attempts don’t become a hidden fee line (failed txs still burn fees).
• When you chart internally, plot fees and tips as separate series, then a revenue sum — never one unlabeled line called “cost.”

// Mental model for a send path
if needs_cross_tx_atomicity or competing_for_hot_state:
  consider Jito bundle/send + tip_floor(percentiles)
else:
  set CU limit + CU price from recent priority percentiles
always:
  track land_rate, fee_paid, tip_paid separately

Related reading

• Priority fees in 2026: CU price, Jito tips, or both?
• Jito Bundles: atomic execution
• What it takes to be a Solana validator
• Solana Compass — Fees analytics

Summary

Fees measure what it costs to land work. Revenue measures what block producers and their stakers take home when you include Jito tips. On a representative Compass week, tips alone added on the order of ten thousand SOL on top of ~47K SOL fees across ~900M user transactions — with most users still paying dust and a competitive tail paying real money. Read the charts with that split in mind, and build products against medians or percentiles depending on whether you ship wallets or auctions.