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

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.

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:

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:

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.