What tip and priority fee land on Solana right now

Every guide that tells you to "set a 0.001 SOL tip" or "use 50,000 micro-lamports" was stale before it was published. Fees on Solana are an auction, and the auction reprices minute to minute with congestion, launch waves and bot activity. The only honest answer to "what Solana priority fee should I use right now" is a live measurement — taken from what actually landed and what actually failed in the last few minutes. This article shows how to get exactly that from the Raiden API: a live landed-vs-failed gauge, a Jito tip tracker with hourly history, and the leader schedule that tells you whether a tip will even work on the next slots.

Two auctions, not one: tip vs priority fee

"Fees" on Solana are two separate mechanisms that get conflated constantly:

So the question is never just "how much" — it is which auction is open right now and what the clearing price is in each. Both answers change on the timescale of minutes, which is why the endpoints below are windowed, not averaged over days.

pump.fun landing conditions, live: /aggregates/landing-conditions

The core instrument is a gauge that compares landed pump.fun buys (from the swaps stream) against failed ones (from the failed-transaction stream — the lost bids most indexers throw away) over a rolling window:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/aggregates/landing-conditions?lookback=15m"

{
  "as_of": "2026-07-22T14:03:00Z",
  "lookback_min": 15,
  "landed_buys": 33150, "failed_buys": 161090,
  "land_rate": 0.171, "congestion_index": 82.9,
  "landed": { "tip_p50": 0, "tip_p90": 0, "priority_p50": 0, "priority_p90": 210471, "cu_price_p50": 0 },
  "failed": { "tip_p50": 4020202, "tip_p90": 70000000, "priority_p50": 16, "priority_p90": 14678, "cu_price_p50": 0 }
}

• lookback — 5m, 15m (default) or 60m. Use 5m when you are about to send, 60m for the trend.
• venue — optional 0|1|2 filter to narrow the gauge to a single venue.
• land_rate — landed / (landed + failed) buys in the window.
• congestion_index — the failed share on a 0–100 scale, the complement of the land rate. 82.9 means fewer than one in five submitted buys executed.
• landed / failed — tip and priority-fee percentiles for each side, plus the median cu_price.

The failed side is the bid you must beat

Most fee estimators only look at what landed. That is half the picture, and the less useful half. The landed percentiles tell you what cleared; the failed percentiles tell you what everyone else is bidding at this exact moment and still losing. Your transaction does not compete against last block's winners — it competes against the live crowd of losers, and to land you have to beat their bids on the dimension that actually decides inclusion. Reading the two sides together is a diagnosis:

This is also why per-wallet analysis needs the same denominator: a wallet's spend only means something against the market's live clearing price. To run that comparison wallet-vs-wallet — who lands first, at what cost, on which leaders — see the head-to-head landing guide.

A Jito tip tracker with history: /aggregates/tip-market

The landing gauge answers "right now". For the tip market's structure — which provider is expensive, at which hours, and how today compares to last month — there is an hourly per-provider time-series. It works as a Jito tip tracker and covers the other submission providers (helius, astralane, 0slot, stellium, …) on the same schema:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/aggregates/tip-market?provider=jito&limit=168"

{
  "interval": "1h",
  "data": [
    { "ts": "2026-07-20T11:00:00Z", "provider": "jito", "tip_sol": 6.8, "tip_txs": 6533, "tip_p50": 100000, "tip_p90": 1000000 }
  ]
}

One row per hour and provider: total SOL tipped, the number of tipped transactions, and the p50/p90 tip in lamports. provider and from/to (RFC3339) are optional — omit the provider to get all lanes side by side, use the time range to pull history. The series is built from hourly snapshots; full history runs since May 1, 2026, with 6 months of retention. That depth is what turns "is 0.001 SOL a normal Solana tip amount today?" from a forum guess into a percentile lookup: compare the current hour's tip_p50 against the same hour last week and you know whether the market is hot or you are just early.

Will a tip even work? /leaders and the Jito flag

Here is the part almost every fee guide skips: a tip is only worth paying if the upcoming slot leaders can honor it. Each ~400ms slot has exactly one validator building the block, the schedule rotates in segments of ~4 consecutive slots, and only leaders running the Jito client participate in the tip auction. If the next 8 slots belong to vanilla leaders, a tip-heavy strategy is about to donate money — and this is knowable before sending:

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/leaders?past=40&future=160"

{
  "current_slot": 348291045,
  "slot_ms": 400,
  "epoch": 805,
  "segments": [
    {
      "start_slot": 348291040, "end_slot": 348291047, "slots": 8,
      "state": "active", "remaining_slots": 3,
      "identity": "Jee7…xQ2", "name": "Raiden Validator",
      "client": "agave", "version": "2.1.11",
      "stake": "488888889123456", "commission": 5,
      "jito": true, "delinquent": false,
      "country": "DE", "city": "Falkenstein",
      "swaps": 37, "priority_fees": "1450000", "tips": "880000",
      "fees": "185000", "vol": "21450000000"
    },
    { "start_slot": 348291048, "state": "future", "eta_slots": 3, "jito": false, … }
  ],
  "slot_fees": [
    { "slot": 348291040, "identity": "Jee7…xQ2", "swaps": 12, "priority_fees": "620000", "tips": "410000" }
  ]
}

The schedule comes back grouped into per-leader segments tagged past | active | future, each carrying the validator's identity, name, client, version, stake, commission, jito flag, delinquency and geography. Past and active segments also aggregate the fees actually paid on those slots — priority_fees and tips from indexed swaps — and slot_fees[] breaks the same numbers down per individual slot: not an estimate of the auction, but its receipts, slot by slot. The window is tunable (past 1–400, default 40; future 4–1600, default 160), the same payload streams in realtime over the WebSocket topic leaders, and it covers the current epoch only.

Put it together: a bid, in Python

import requests

BASE = "https://terminal.raiden.wtf/api"
H = {"X-API-Key": "YOUR_KEY"}

# 1 · what is clearing right now (tight 5-minute window)
lc = requests.get(f"{BASE}/aggregates/landing-conditions",
                  params={"lookback": "5m"}, headers=H).json()
print(f"land_rate={lc['land_rate']:.1%}  congestion={lc['congestion_index']:.0f}")
print("winners:", lc["landed"])
print("losers: ", lc["failed"])

# 2 · can a tip even work in the next ~13 seconds?
ld = requests.get(f"{BASE}/leaders", params={"past": 1, "future": 32}, headers=H).json()
upcoming = [s for s in ld["segments"] if s["state"] == "future"]
jito_slots = sum(s["slots"] for s in upcoming if s["jito"])
total = sum(s["slots"] for s in upcoming)
print(f"jito leaders ahead: {jito_slots}/{total} slots")

# 3 · pick the lever that is actually open
if total and jito_slots / total > 0.5:
    # tip auction open: clear the losing crowd's median, sanity-check vs winners' p90
    bid = max(lc["failed"]["tip_p50"], lc["landed"]["tip_p90"])
    print(f"tip lane open -> bid ≥ {bid} lamports ({bid/1e9:.4f} SOL)")
else:
    # vanilla leaders: only the in-protocol auction orders the block
    print("non-Jito segment -> skip the tip, push cu_price × cu_limit above landed priority_p90:",
          lc["landed"]["priority_p90"], "lamports total priority fee")

Three calls, one decision: what is clearing, what the losers are bidding, and whether the tip lane is open for the slots you are about to race. Poll the 5-minute window right before sending — with a congestion index in the 80s, percentiles measured an hour ago describe a different market.

The pump.fun landing conditions gauge, the tip tracker and the leader schedule are three of the endpoints in the Raiden pump.fun API — the full parameter reference lives in the API docs. And when the question shifts from "what does the market pay" to "why does that wallet keep beating me", the same data answers it per-wallet: compare transaction landing between two wallets, leader by leader.