Enhanced APIs (sn_* methods)

Common blockchain reads are really groups of calls: a wallet balance view is one eth_getBalance plus N balanceOfs plus metadata lookups; understanding a transaction is a fetch, a receipt, and log decoding. Enhanced APIs collapse each group into one JSON-RPC call on your existing endpoint — same URL, same key, just methods with an sn_ prefix.

• Paid plans only. On the free tier, sn_* methods return error -33000 with an upgrade link.
• No metering surcharge. Providers that offer similar calls weight them heavily in compute units; here an enhanced call counts like any other request — flat-rate as always.
• Consistent snapshots. Every multi-value response is pinned to a single block (returned as blockNumber), so balances are mutually consistent.
• EVM chains only. One upstream round trip per call, with automatic failover.

sn_getTokenBalances

Native balance plus ERC-20 balances (with cached symbol/decimals) for one address, for the token contracts you specify (up to 200):

curl -X POST "https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"sn_getTokenBalances",
       "params":["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
                 ["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"]]}'

// result: { address, blockNumber, nativeBalance,
//   tokens: [{ contract, balance, symbol: "USDC", decimals: 6 }] }

sn_getPortfolio

The same idea across up to 20 addresses at once: native balance, nonce, and token balances per account, all at one pinned block. params: [addresses[], tokens[]?].

{"jsonrpc":"2.0","id":1,"method":"sn_getPortfolio",
 "params":[["0xAddr1...","0xAddr2..."],["0xTokenA...","0xTokenB..."]]}

// result: { blockNumber, accounts: [{ address, nativeBalance, nonce, tokens: [...] }] }

sn_getTransactionBundle

Transaction + receipt + decoded activity in one call. Logs matching the ERC-20/721/1155 standards (Transfer, Approval, ApprovalForAll, TransferSingle/Batch) are decoded with named fields; the calldata selector is resolved against a dictionary of common methods. status is the honest one: success, reverted, or pending — because mined and succeeded are not the same thing.

{"jsonrpc":"2.0","id":1,"method":"sn_getTransactionBundle","params":["0xTxHash..."]}

// result: { transaction, receipt, status: "success",
//   methodSelector: "0xa9059cbb", methodName: "transfer",
//   decodedLogs: [{ log, decoded: { standard:"erc20", event:"Transfer",
//                                   from, to, value, contract } }] }

sn_getAllowances

Audit ERC-20 approvals in one call: an owner plus up to 200 {token, spender} pairs → each allowance with token metadata. Built for approval-checker and security tooling.

{"jsonrpc":"2.0","id":1,"method":"sn_getAllowances",
 "params":["0xOwner...",[{"token":"0xUSDC...","spender":"0xRouter..."}]]}

// result: { owner, blockNumber,
//   allowances: [{ token, spender, allowance, symbol, decimals }] }

More methods

Limits and behavior

• Maximums per call: 200 tokens, 20 addresses, 200 allowance pairs. Oversized lists return -32602.
• Enhanced calls count as one request for rate-limit purposes, regardless of how many values they return.
• A token that isn’t a standard ERC-20 (or a call an individual contract rejects) yields null for that entry rather than failing the whole response.
• Token discovery (“which tokens does this address hold?”) and address transaction history need an index rather than live calls — that’s on our roadmap; these methods take explicit token lists today.