How to compare transaction landing between two wallets on pump.fun

The complete guide to comparing Solana wallet landing: land rate, slot deltas, tips, priority fees, slot leaders, Jito and routers — head-to-head via API.

July 24, 2026·11 min read·1,980 words

landingsnipersversusslot leadersjitotips

Two snipers buy the same pump.fun launches. One is consistently in the block first. Is it the tip? The submission provider? The validator producing the slot? The bot they route through? This is the complete guide to answering that question with data: how to compare transaction landing between two wallets — land rate, execution order, spend, slot leaders and infrastructure — using the Raiden API.

What "landing" actually means

On Solana there are three outcomes for a submitted transaction: it lands and executes, it lands and reverts (you paid fees, got nothing), or it never reaches the chain at all. Within a block, execution order is exact: the slot (~400ms), then the block index inside that slot. That ordering is the ground truth of who "landed first" — not timestamps, which are too coarse for same-slot races.

Scope: the comparison is built from what the chain recorded — landed fills and landed-but-reverted attempts. Dropped transactions that never got included are invisible to everyone, including validators' own explorers.

Who decides: the slot leader

Every slot has exactly one validator in charge — the leader — who builds the block: it decides which transactions get in and in what order. The leader schedule is deterministic and public for the whole epoch, rotating in segments of ~4 consecutive slots per validator. Landing is therefore not an abstract race "to the chain": it is a race to the ingest port of one specific machine, somewhere on the planet, that holds the pen for the next ~1.6 seconds. Four consequences follow:

Path beats distance. Your transaction reaches the leader through a submission provider (Jito, Nextblock, 0slot, Astralane, …). What matters is that provider's connectivity to the current leader, not your ping to "Solana".
Tips are conditional. A Jito tip buys bundle priority through the Jito block engine — but only on slots whose leader runs the Jito client. On a non-Jito leader the tip buys nothing; what orders the block there is the in-protocol priority fee (cu_price × cu_limit, micro-lamports per compute unit).
Stake opens doors. Leaders allocate ingest capacity by stake (stake-weighted QoS): providers peered through well-staked nodes get their packets accepted when unstaked connections are shed under load.
Leaders differ. Client (agave, firedancer, jito-agave), version, stake and geography change how a leader schedules under pressure — two wallets can systematically split outcomes on different leader cohorts.

This is why a serious wallet-vs-wallet comparison must break results down per leader — and why every fill and every failed attempt in the API carries the validator that produced its slot.

One call: `/versus`

The head-to-head endpoint takes 2–5 wallets and scores them on the last N tokens they touched in common — bought by at least two of them, or bought by one while another tried and failed (the "one enters, the other reverts" case most tools miss):

curl -H "X-API-Key: $RAIDEN_KEY" \
  "https://terminal.raiden.wtf/api/versus?w=WALLET_A,WALLET_B&n=100"

n — window size: last 50, 100 (default) or 200 tokens touched in common.
max_behind=N — optional: keep only "tight" races where every wallet landed within N slots of the winner (filters entries[] only; the scoreboard stays full).

The scoreboard: `per_wallet`

Each wallet gets a leaderboard row. The two headline numbers measure different things:

Metric	Definition	What it tells you
`win_rate`	wins / contested tokens where the wallet landed	Who is first when both land
`land_rate`	landed / (landed + failed)	How often a submitted trade actually executes
`avg_from_creation`	avg slots between token creation and the fill	Raw reaction speed to a launch
`avg_tip` / `avg_priority_fee`	average spend per fill (SOL)	What the win rate costs
`avg_cu_price` / `avg_cu_limit`	compute-budget settings	How the transactions are tuned for non-Jito blocks
`direct` / `via_router` / `top_router`	fills sent straight to pump.fun vs through a bot/aggregator	Whose infrastructure they depend on

A wallet with a high win_rate but low land_rate is a spray-and-pray sniper: first when it connects, but burning fees on reverts. High land_rate with a losing win_rate is a careful follower — it waits, lands reliably, and pays for it in entry price.

The tape: `entries[]`, race by race

Every contested token comes back with the full grid: creation slot and block index (anchored to the dev buy), each wallet's fill ranked by (slot, block_index), the failed attempts ranked on the same scale — and, on every side, the leader that produced the slot:

{
  "mint": "9xQm…pump",
  "created_slot": 348812900,
  "winner": "WALLET_A",
  "sides": [
    { "wallet": "WALLET_A", "rank": 1, "slot": 348812903, "block_index": 12,
      "tip": "2000000", "priority_fee": "500000", "cu_price": "1500000",
      "provider": "jito", "router": "JUP6Lkb…VTaV4", "sig": "4Fr4…ULFK",
      "leader": { "identity": "Jee7…xQ2", "name": "Laine", "client": "agave",
                  "version": "2.1.11", "jito": true,
                  "stake": "1875432000000000", "country": "DE", "city": "Frankfurt am Main" } },
    { "wallet": "WALLET_B", "rank": 2, "slot": 348812905, "block_index": 4, … }
  ],
  "failed": [
    { "wallet": "WALLET_B", "slot": 348812904, "block_index": 9, "tip": "1500000", … }
  ]
}

If a failed attempt's slot is earlier than the winner's fill, its delta is negative: that wallet was actually faster to the chain and lost anyway — a slippage or fee war lost in-block, not a latency problem. The provider tells you which submission lane carried each fill; the router whether it went through a bot/aggregator program or straight to pump.fun; the leader object (identity, name, client, version, Jito flag, stake, country/city — for snapshotted epochs) is what turns anecdotes into a diagnosis.

The leader breakdown: where the race is actually decided

Group every side and failed attempt by its leader and patterns jump out:

Pattern in the data	Diagnosis	What to do
Same leader, same slot, A consistently lower `block_index`	A's provider has the better lane to that validator	Latency/peering work; copy A's `provider`
A wins on `jito: true` leaders, loses on the rest	A's edge is the tip auction, not speed	On non-Jito slots only `cu_price` orders the block — tune it
B's failures cluster on low-stake or specific-client leaders	B's packets get shed under SWQoS / scheduler differences	Use a provider with staked peering; avoid racing those segments
Wins cluster on leaders in one region (`country`/`city`)	Geographic proximity of that wallet's infra	Compare against your own placement
Both always land on the same few leaders	Snipes concentrate in the first slots after creation — the leader segment at launch time decides everything	Check the live schedule before committing (below)

For the forward-looking half of this: GET /leaders returns the live leader schedule around the current slot in ~4-slot segments — each with the validator's identity, client, Jito flag, stake, geography, and (for past/active segments) the priority fees and tips actually paid on those slots, per slot. The same payload streams over WebSocket on the leaders topic. If the next 8 slots belong to non-Jito leaders, a tip-heavy strategy is about to waste money — and you can know that before sending.

Compute the answer in Python

import requests, statistics
from collections import Counter

BASE = "https://terminal.raiden.wtf/api"
H = {"X-API-Key": "YOUR_KEY"}
A, B = "WALLET_A", "WALLET_B"

vs = requests.get(f"{BASE}/versus", params={"w": f"{A},{B}", "n": 200}, headers=H).json()

# 1 · headline: who wins, who lands, at what cost
for row in vs["per_wallet"]:
    spend = row["avg_tip"] + row["avg_priority_fee"]
    print(f"{row['wallet'][:6]}  win={row['win_rate']:.0%}  land={row['land_rate']:.0%}  "
          f"spend/fill={spend:.5f} SOL  from_creation={row['avg_from_creation']} slots")

# 2 · slot delta where BOTH landed (negative = A ahead; 0 = same-slot race)
deltas, same_slot = [], []
for e in vs["entries"]:
    fills = {s["wallet"]: s for s in e["sides"]}
    if A in fills and B in fills:
        d = fills[A]["slot"] - fills[B]["slot"]
        deltas.append(d)
        if d == 0:
            same_slot.append(fills[A]["block_index"] - fills[B]["block_index"])

print(f"median slot delta A-B: {statistics.median(deltas)}  "
      f"| same-slot races: {len(same_slot)}, median block_index delta: "
      f"{statistics.median(same_slot) if same_slot else '-'}")

# 3 · leader breakdown: is the edge bought (Jito) or structural?
wins_by_jito = Counter()
for e in vs["entries"]:
    for s in e["sides"]:
        if s["wallet"] == e["winner"] and s.get("leader"):
            wins_by_jito[(e["winner"][:6], s["leader"]["jito"])] += 1
print("wins by (wallet, jito-leader):", dict(wins_by_jito))
# A winning ONLY on jito=True leaders → tip-driven edge, beatable on vanilla slots

A median delta of -1 over a couple hundred shared tokens is a structural speed edge (~400ms per slot). A delta of 0 with a consistent block_index gap means the race is decided inside the block — look at the leader breakdown and the spend, not at latency.

The cost side: what a win actually costs

Two spends, two mechanisms. The tip is an out-of-band payment to the leader's tip account — an auction that exists only on Jito slots. The priority fee is in-protocol (cu_price × cu_limit) and orders transactions in every block. A wallet whose avg_tip dwarfs its avg_priority_fee is optimized for Jito segments and coasts elsewhere; divide total spend by wins to get the real price per win — the number that decides whether an edge is worth copying. Per-wallet provider habits are one call away: /wallets/{addr}/tips ranks the submission providers a wallet pays by total tipped.

Routers: whose infrastructure is it, really?

Each fill carries its router — the top-level program that orchestrated the swap (Trojan, BullX, Photon, GMGN, a custom contract…), absent when the wallet calls pump.fun directly. The scoreboard aggregates it: direct vs via_router counts and top_router. A high via_router share means the latency, the fee tuning, even the provider choice belong to the bot — you are not comparing two snipers, you are comparing two subscriptions.

Do they even play the same game? `overlap` & `exclusive`

A head-to-head is only meaningful if the wallets actually contest the same launches. The response ends with the group view: overlap.union (all tokens touched), shared (by ≥2), shared_all (by everyone), overlap_pct, and per-wallet touched / landed / failed_only / exclusive counts. exclusive[] lists, per wallet, the recent tokens no other wallet in the group ever touched (with landed=false marking pure failed attempts). Two wallets with 10% overlap are not rivals — they are running different strategies, and their win rates should not be compared at face value.

Go deeper per wallet

/wallets/{addr}/failed — every pump.fun transaction that landed and reverted (kept on the same 6-month window), with a kind label (0=buy, 1=sell, 2=other pump instruction, 3=pump referenced but no pump instruction) and the raw instruction discriminator. This is the denominator behind the land rate.
/wallets/{addr}/tips — which submission providers the wallet pays, ranked by total tipped.
/leaders — the live leader schedule with per-slot fees and tips; the forward-looking complement to the per-fill leader data.
/aggregates/landing-conditions — market context: what tip and priority fee are landing pump.fun buys right now, from a live landed-vs-failed window. A wallet's spend only makes sense against this baseline.

Reading the results honestly

Same leader, different outcome → the loser's path to that validator is slower or its provider queues worse; latency work.
Winner pays less (lower avg_tip, higher win_rate) → better routing beats bigger bribes; copy the provider mix, not the tip size.
Wins only on Jito leaders → the edge is bought at auction; on vanilla slots the same wallet is ordinary — attack it there with cu_price.
High via_router → the edge (or the bottleneck) belongs to the bot they route through — check top_router.
Negative deltas on failed attempts → speed is fine, the transaction construction loses fee wars; tune slippage and CU price, not infrastructure.
Low overlap → stop comparing; they are not in the same races.

The same comparison runs interactively on the Sniper VS page of the Terminal — same endpoint, same numbers, leaders included. To build the wallet lists worth comparing, start from tracking pump.fun wallets, and watch them live with a WebSocket stream.

Frequently asked questions · 7 answers

What is a slot leader and why does it decide my landing?

Every ~400ms slot has exactly one validator — the leader — who builds that block and decides which transactions enter and in what order. Landing is therefore a race to reach the CURRENT leader's ingest port before the block is sealed. The leader schedule rotates in ~4-slot segments and is known in advance for the whole epoch.

Why do Jito leaders matter for tips?

A Jito tip is an out-of-band payment that buys priority through the Jito block engine — but only the leader of the slot can honor it, and only if that leader runs the Jito client. When the current leader is not Jito-enabled, the tip buys nothing there. That is why comparing wins on Jito vs non-Jito leaders (the leader.jito flag) tells you whether a wallet's edge is bought or structural.

What counts as a failed transaction in the comparison?

Only transactions that landed on-chain and REVERTED — the fee and slippage wars lost in-block. Attempts that were dropped before inclusion never reach the chain and are not visible to any indexer. Land-rate analytics count buy/sell reverts (kind 0 and 1).

How is the landing winner decided on a token?

By lowest slot first, then block index as the tiebreaker inside the same slot — the actual execution order recorded by the chain. Failed attempts rank on the same scale: a negative delta means the loser actually reached the chain earlier but reverted.

Does a higher tip guarantee landing first?

No. The tip is one input among four: the submission provider's path to the leader, the priority fee (cu_price × cu_limit) that orders transactions inside the block, stake-weighted QoS on the leader's ingest connections, and the tip auction itself — which only exists on Jito leaders. The comparison regularly shows one wallet winning with a fraction of the other's spend.

Can I compare more than two wallets?

Yes — /versus accepts 2 to 5 wallets in the w parameter and scores them on the last N tokens they touched in common (n=50, 100 or 200).

Can I see who the upcoming slot leaders are before sending?

Yes — GET /leaders returns the live schedule around the current slot in ~4-slot segments with each validator's identity, client, Jito flag, stake and geography, plus per-slot priority fees and tips actually paid. The same payload streams over WebSocket on the leaders topic.

Build on the same data

Free API key with 200,000 trial credits: full REST and WebSocket access to the same firehose that powers the Terminal. Connect a Solana wallet; no email, no card.

Get a free API key Explore the API

Raiden TerminalGuides Pump.fun API Ingested by Raiden Vortex © Raiden · an independent Solana data provider, not affiliated with pump.fun