Leader & Validator Endpoints

Follow the Solana leader schedule and see where block production happens. Get the live window of validators around the current slot, with the swaps, priority fees and tips landed in their slots, or the whole epoch’s leader slots grouped by city, country, datacenter or client.

Paths are relative to https://terminal.raiden.wtf/api and every request carries your key in the X-API-Key header (see Authentication). Each call costs the credits shown next to it.

Live leader schedule

The live leader schedule around the current slot, grouped into per-leader segments (each ≈4 consecutive slots). Every segment is tagged with a state: past, active or future.

Segment fields.

• Every segment carries its validator: identity, name, client, version, stake, commission, jito, delinquent, country, city.
• past and active segments also aggregate swaps, priority_fees, tips, fees and vol from indexed swaps on those slots.
• active segments add remaining_slots; future segments add eta_slots. Fee fields are 0 for future segments.
• slot_fees[] breaks the same priority_fees and tips down per individual slot.

Realtime. The same payload is pushed in realtime over the WS topic leaders.

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

{
  "current_slot": 348291045,
  "slot_ms": 400,
  "epoch": 805,
  "slot_index": 91045,
  "slots_in_epoch": 432000,
  "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"
    }
  ],
  "slot_fees": [
    {
      "slot": 348291040,
      "identity": "Jee7…xQ2",
      "swaps": 12,
      "priority_fees": "620000",
      "tips": "410000"
    }
  ]
}

Leader slot distribution

Where the current epoch’s leader slots physically are. Unlike /leaders, which is a live window of ~40 leaders, this covers the whole epoch (432,000 slots across every validator), so it answers “what does the network look like” rather than “who is next”.

Row fields. Each row carries slots, pct and validators, the number of distinct operators behind it. That is what separates “a city with 99 operators” from “a city with one very large one”: same slot count, opposite concentration risk.

unknown_slots reports anything that could not be classified, rather than quietly shrinking the denominator.

Why city names are normalized. The upstream source mixes city names with timezone identifiers: 22.6% of slots came labelled Europe/Amsterdam or America/Chicago. Left alone, that splits every city across two rows and every percentage is wrong. Amsterdam was 57,460 + 22,200 in separate rows, which put Frankfurt on top instead.

How they are normalized.

• The timezone prefix is stripped.
• Two verified aliases are merged: Frankfurt am Main → Frankfurt, City of London → London.
• Districts are not merged into their city.
• Frankfurt (Oder) is deliberately kept separate: it is a different city 500km away.

curl -s "https://terminal.raiden.wtf/api/leaders/distribution?by=city" \
  -H "X-API-Key: $RAIDEN_KEY"

{
  "by": "city", "epoch": 1018, "total_slots": 432000,
  "leader": "Amsterdam", "leader_pct": 18.44, "unknown_slots": 0,
  "data": [
    { "key": "Amsterdam", "country": "NL", "slots": 79660, "pct": 18.44, "validators": 99 },
    { "key": "Frankfurt", "country": "DE", "slots": 75696, "pct": 17.52, "validators": 80 },
    { "key": "London",    "country": "GB", "slots": 48984, "pct": 11.34, "validators": 29 }
  ]
}