getSlotLeaders
Returns the slot leaders for a given slot range
Common use cases
| TPU Transaction Forwarding | Applications fetch upcoming leaders to send transactions directly to leader TPU endpoints, bypassing gossip network for faster inclusion. Correlates getSlotLeaders results with getClusterNodes to obtain TPU addresses for optimized transaction routing. |
| Validator Monitoring and Analytics | Network analysis tools track which validators are scheduled as leaders for upcoming slots to monitor block production rates, calculate decentralization metrics, and identify validator performance patterns across the network. |
| Leader Schedule Caching | Services maintain local cache of leader schedule to reduce RPC calls, updating periodically (e.g., every 4 slots) and advancing schedule on slot progression. Enables low-latency leader lookup for transaction routing applications. |
| Epoch Boundary Planning | Applications query leader schedule before epoch transitions to prepare for schedule changes, ensuring continuity of transaction routing and avoiding disruptions from schedule unavailability during epoch rollover. |
| Network Simulation and Testing | Development tools use getSlotLeaders to simulate validator rotation for testing transaction timing, analyzing network behavior under different leader distributions, and building developer tooling for Solana ecosystem exploration. |
Parameters
start slot (u64, required)
Start slot, as u64 integer
limit (u64, required)
Limit, as u64 integer (between 1 and 5,000)
Request
- cURL
- JavaScript
- Python
curl https://solana-mainnet.api.syndica.io/api-key/YOUR_API_KEY \
-X POST \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getSlotLeaders",
"params": [
100,
10
]
}'
// Using fetch
const response = await fetch('https://solana-mainnet.api.syndica.io/api-key/YOUR_API_KEY', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
"jsonrpc": "2.0",
"id": 1,
"method": "getSlotLeaders",
"params": [
100,
10
]
})
});
const data = await response.json();
console.log(data);
import requests
import json
url = 'https://solana-mainnet.api.syndica.io/api-key/YOUR_API_KEY'
headers = {'Content-Type': 'application/json'}
data = {
"jsonrpc": "2.0",
"id": 1,
"method": "getSlotLeaders",
"params": [
100,
10
]
}
response = requests.post(url, headers=headers, data=json.dumps(data))
print(response.json())
Replace mainnet with devnet in the URL to query devnet instead.
Response
{
"jsonrpc": "2.0",
"result": [
"ChorusmmK7i1AxXeiTtQgQZhQNiXYU84ULeaYF1EH15n",
"ChorusmmK7i1AxXeiTtQgQZhQNiXYU84ULeaYF1EH15n",
"ChorusmmK7i1AxXeiTtQgQZhQNiXYU84ULeaYF1EH15n",
"ChorusmmK7i1AxXeiTtQgQZhQNiXYU84ULeaYF1EH15n",
"Awes4Tr6TX8JDzEhCZY2QVNimT6iD1zWHzf1vNyGvpLM",
"Awes4Tr6TX8JDzEhCZY2QVNimT6iD1zWHzf1vNyGvpLM",
"Awes4Tr6TX8JDzEhCZY2QVNimT6iD1zWHzf1vNyGvpLM",
"Awes4Tr6TX8JDzEhCZY2QVNimT6iD1zWHzf1vNyGvpLM",
"DWvDTSh3qfn88UoQTEKRV2JnLt5jtJAVoiCo3ivtMwXP",
"DWvDTSh3qfn88UoQTEKRV2JnLt5jtJAVoiCo3ivtMwXP"
],
"id": 1
}
Response Fields
Return value: array
Array of Node identity public keys as base-58 encoded strings.
FAQ and Troubleshooting
Why do I get 'Invalid slot range: leader schedule for epoch X is unavailable'?
RPC nodes typically retain leader schedule data for only the current epoch and approximately 10 recent epochs. When requesting leaders for older slots, the schedule may have been pruned. Use getBlock with rewards: true to extract the leader from historical block rewards instead.
What is the maximum number of leaders I can fetch at once?
The limit parameter accepts values between 1 and 5,000 slots. This allows you to look ahead approximately 1-2 minutes of slots at maximum (assuming 400ms slot time). For full epoch schedules, use getLeaderSchedule instead.
Can I fetch leaders for future slots that haven't occurred yet?
Yes. The leader schedule is determined at the beginning of each epoch, so you can request leaders for any future slot within the current epoch. The schedule is fixed for the epoch unless exceptional network circumstances occur.
Why are the same public keys repeated multiple times in the response?
Each validator is assigned 4 consecutive slots during their leader period. The returned array includes the leader for every slot in the requested range, so you'll see each validator's pubkey repeated 4 times for their assigned slot sequence.
How do I use getSlotLeaders to forward transactions to the right validator?
First call getSlotLeaders(current_slot, limit) to get upcoming leaders. Then call getClusterNodes() to get validator contact information including TPU addresses. Match the leader pubkeys to find the TPU endpoint and send transactions directly to it.
Related Methods
getLeaderSchedule
Returns the complete leader schedule for an entire epoch as a map of validator pubkeys to their assigned slot indices, while getSlotLeaders returns a sequential list for a limited range. Use getLeaderSchedule when you need the full epoch schedule; use getSlotLeaders for targeted upcoming slots.
getSlot
Returns the current slot number, which is commonly used as the start_slot parameter for getSlotLeaders to fetch upcoming leaders relative to now. This is the standard pattern in production implementations.
getClusterNodes
Returns validator contact information including TPU network addresses. After fetching leaders with getSlotLeaders, applications correlate the leader pubkeys with cluster node data to obtain TPU endpoints for direct transaction forwarding.
getEpochInfo
Returns current epoch number, slot index within epoch, and total slots in epoch. Used to determine if a requested slot range crosses an epoch boundary, which affects leader schedule availability since schedules are epoch-scoped.
getBlock
Can retrieve the leader for a historical slot via the rewards field (vote authority) when the leader schedule for that epoch is no longer available from RPC nodes. Serves as a fallback for historical leader identification.