getLargestAccounts

Returns the 20 largest accounts, by lamport balance (results may be cached up to two hours)

Common use cases

Track Top Whale Accounts for Network Concentration Metrics	Monitor the 20 largest SOL holders to analyze network decentralization over time. Common in blockchain explorers and network health dashboards. Use filter: "circulating" to exclude stake/system accounts, then pair with getSupply to calculate top-20 concentration percentage. Cache results for dashboard refresh (2-hour cache makes this suitable for hourly updates).
Identify Largest Accounts Before Major Market Events	Fetch top 20 accounts by balance to identify whale wallets for monitoring. Once identified, use accountSubscribe WebSocket to watch for large transfers in real-time. Common pattern: getLargestAccounts for initial discovery, then subscribe to specific addresses. Note: Heavy rate limiting means this is a one-time discovery step, not continuous polling.
Separate Locked Supply from Active Circulation Using Filters	Compare filter: "circulating" vs filter: "nonCirculating" results to analyze locked supply distribution. Circulating filter excludes sysvars, stake accounts, and vote accounts to show "active" top holders. Useful for economic analysis and token distribution reports where you need to distinguish between locked/staked vs liquid holdings.
Display Rich List Rankings in Blockchain Explorers	Show top 20 accounts by SOL balance in explorer UIs or analytics dashboards. Results cached up to 2 hours make this perfect for public dashboards that don't need real-time accuracy. Format lamports to SOL (÷ 1B), calculate percentage of total supply, and display ranked list. Common in block explorers like Solscan, Solana Beach.
Research Token Concentration for Decentralization Studies	Collect top 20 account balances for academic research on network decentralization and wealth distribution. Pair with historical slot data to track concentration changes over time. Export data for Gini coefficient calculations or Lorenz curve analysis. Note: Limited by rate restrictions - suitable for periodic snapshots, not continuous monitoring.

Parameters

config (object, optional)

Configuration object containing the following fields:

Fields:

• commitment (string): The commitment describes how finalized a block is at that point in time. See Configuring State Commitment.
• filter (string): Filter results by account type

Request

cURL

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": "getLargestAccounts",
  "params": [
    {
      "commitment": "finalized"
    }
  ]
}'

JavaScript

// 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": "getLargestAccounts",
  "params": [
    {
      "commitment": "finalized"
    }
  ]
})
});
const data = await response.json();
console.log(data);

Python

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": "getLargestAccounts",
  "params": [
    {
      "commitment": "finalized"
    }
  ]
}

response = requests.post(url, headers=headers, data=json.dumps(data))
print(response.json())

Network Selection

Replace mainnet with devnet in the URL to query devnet instead.

Response

{
  "jsonrpc": "2.0",
  "result": {
    "context": { "slot": 54 },
    "value": [
      {
        "address": "99P8ZgtJYe1buSK8JXkvpLh8xPsCFuLYhz9hQFNw93WJ",
        "lamports": 999974
      },
      {
        "address": "uPwWLo16MVehpyWqsLkK3Ka8nLowWvAHbBChqv2FZeL",
        "lamports": 42
      }
    ]
  },
  "id": 1
}

Response Fields

Return value: array

The result will be an RpcResponse JSON object with value equal to an array of objects containing:

FAQ and Troubleshooting

Why does getLargestAccounts fail with rate limit errors or timeouts?

This is one of the most expensive RPC methods - it scans all accounts to find the top 20 by balance. Many RPC providers heavily rate-limit or disable it entirely (Syndica: 0 req/s). If you hit rate limits, space out calls or switch to a less restrictive provider. For frequent queries, cache results locally since data changes slowly and is already cached up to 2 hours on the RPC side.

How fresh is the data returned by getLargestAccounts?

Results may be cached up to 2 hours according to official docs, though agave implementation uses a 1-second cache. Always check the context.slot in the response and compare to current slot (getSlot) to determine staleness. For real-time whale tracking, use getLargestAccounts once for discovery, then accountSubscribe to specific addresses for live updates.

What's the difference between circulating and nonCirculating filters?

"circulating" excludes system accounts (sysvars, stake accounts, vote accounts) to show only "active" holder distribution. "nonCirculating" shows ONLY those excluded accounts. Use circulating for whale tracking and market analysis (liquid supply), nonCirculating for analyzing locked/staked supply. Omit filter to see all accounts regardless of type.

Can I get more than 20 largest accounts?

No, getLargestAccounts is hard-capped at 20 results. This limit is enforced in the agave implementation's BinaryHeap (max size 20). For complete account ranking, you'd need to use getProgramAccounts or direct database queries, but those are even more expensive and impractical for large-scale scans. The top 20 usually represents a significant portion of supply anyway.

Which commitment level should I use for getLargestAccounts?

Use "finalized" (default on most RPC providers) for network analysis and dashboards. Largest accounts change very slowly, so confirmed/processed levels don't add meaningful freshness and risk rollback issues. Only use confirmed if you're monitoring for immediate stake changes and can tolerate rare rollbacks where accounts drop from top 20.

Related Methods

getSupply
Returns total SOL supply (circulating, non-circulating, total). Pair with getLargestAccounts to calculate top-20 concentration: (sum of top 20 lamports / circulating supply) × 100%. Essential for decentralization metrics and whale dominance analysis. Both methods support circulating/nonCirculating filters for consistent comparisons.

getTokenLargestAccounts
Returns top 20 token accounts for a specific SPL token mint, whereas getLargestAccounts returns top SOL accounts. Use getLargestAccounts for native SOL whale tracking; use getTokenLargestAccounts for token-specific holder analysis (USDC, BONK, etc). Both share similar response format and cache behavior.

accountSubscribe (WebSocket)
Subscribe to real-time updates for specific accounts via WebSocket. Common pattern: use getLargestAccounts once to identify top 20 whale addresses, then accountSubscribe to those addresses for live balance change notifications. Avoids polling getLargestAccounts (which has heavy rate limits) for continuous monitoring.

getBalance
Returns lamport balance for a single account. After using getLargestAccounts to identify top holders, call getBalance on specific addresses for real-time balance checks without rate limits. getLargestAccounts is for discovery/ranking; getBalance is for monitoring known accounts.

getAccountInfo
Fetch full account data including owner, executable flag, and data bytes. Use after getLargestAccounts when you need to validate account types (stake account, program account, etc) beyond just balance. getLargestAccounts returns minimal data (address + lamports); getAccountInfo provides complete account state.

External Resources

• Solana Official Documentation
• Solana Account Model - Comprehensive guide to Solana's account structure including lamports, owner programs, and account types (system, stake, vote). Critical context for understanding what getLargestAccounts returns and why filtering by circulating vs nonCirculating matters. Explains sysvars and special account categories that affect top holder rankings.
• Setup an RPC Node: Performance Tuning - Validator operator guide explaining why methods like getLargestAccounts are expensive and how RPC nodes optimize caching. Documents the account database scan overhead and why rate limiting is necessary. Useful for understanding RPC provider constraints and why this method has such restrictive limits.