RPC troubleshooting and concept reference
Last updated:
| Page | Chain | Summary |
|---|---|---|
| Why getSignaturesForAddress returns an empty array | Solana | Why Solana's getSignaturesForAddress returns [] for a valid address, and how to tell "no history" from "history outside the node's index". |
| Why getTransaction returns null for an old signature | Solana | getTransaction returns null for two different reasons: an unknown signature, or one that fell outside the node's retained history. How to tell them apart. |
| Why Tron wallet/getaccount returns an empty object | Tron | Tron's wallet/getaccount returns {} both for an address/visible mismatch and a real empty account — not an error. How to tell the two apart. |
| Why TON RPC calls fail with "not in db" | TON | A TON liteserver prunes its own state — the same seqno can fail on one node and succeed on the next. What "not in db" means and when retrying helps. |
| Why eth_getLogs returns an empty array | EVM chains | eth_getLogs returns [] with no error when the filter matches nothing: default block range, a wrong topic hash, a proxy address or the wrong chain. |
| Why eth_getTransactionReceipt returns null | EVM chains | A null receipt means the node has no mined transaction for that hash: pending, replaced, on another chain, or older than its transaction index. |
| Why an EVM transaction is stuck: nonce gaps | EVM chains | A transaction whose nonce skips ahead waits as "queued" and is never mined until the missing nonce arrives. How to find the gap and unblock the sender. |
| Why Solana RPC results differ between calls | Solana | Two identical Solana RPC calls can return different balances or account data: different commitment levels, or nodes at different slots. How to pin it. |
| Why getProgramAccounts returns an empty array | Solana | getProgramAccounts returns [] when no account passes every filter: wrong dataSize, a memcmp offset or encoding mismatch, or the wrong token program. |
| Why a Stellar Horizon page has no records | Stellar | Horizon returns an empty _embedded.records when the cursor is past the last record, the order is reversed, or the account has none. How paging works. |
| One TON address, several formats: EQ, UQ and raw | TON | The same TON account can be written as raw 0:hex, a bounceable EQ… or a non-bounceable UQ… string. Why they differ and how to compare them safely. |
| Why TRON gettransactioninfobyid returns {} | Tron | TRON's wallet/gettransactioninfobyid returns an empty object for a transaction not yet in a block, not yet solidified, malformed, or on another network. |
| Why a WebSocket subscription goes silent | EVM chains, Solana | RPC subscriptions live and die with their WebSocket connection. Why events stop after a reconnect, how to resubscribe, and how to backfill the gap. |
| Chain ID vs network ID: eth_chainId vs net_version | EVM chains | eth_chainId returns the EIP-155 chain ID used in transaction signing; net_version returns the network ID. Why they can differ and which one to trust. |
| Solana slot vs block height: why they differ | Solana | Solana's slot number keeps advancing through skipped slots, so it runs ahead of block height. Which RPC calls use which, and why the gap matters. |
| Solana transaction not landing: how to diagnose it | Solana | sendTransaction gave you a signature and nothing confirmed. Sort it by what getSignatureStatuses shows: failed, dropped or expired, and when to re-sign. |
| Why a Solana wallet's token balance is missing | Solana | getBalance returns only SOL in lamports. Token balances live in separate token accounts owned by the wallet — per mint, and per token program. |
| Paging getSignaturesForAddress with before/until | Solana | getSignaturesForAddress returns at most 1,000 signatures, newest first. How the before and until cursors page through an address's history. |
| Why eth_estimateGas is higher than gas used | EVM chains | eth_estimateGas often returns more gas than the receipt's gasUsed: the 63/64 rule, refunds, and state that changes before inclusion. How to set a limit. |
| Why eth_call returns 0x | EVM chains | eth_call returning "0x" usually means no contract code at that address and block, the wrong chain, or a function that returns nothing. How to tell. |
| Archive node vs full node: what each can answer | All chains | A full node prunes old state; an archive node keeps it. Which RPC reads need historical state, and why transaction lookups and retention differ. |
| Why an ERC-20 transfer shows value 0 | EVM chains | An ERC-20 transfer is a contract call: the transaction's value is 0 and the amount is in the call data and a Transfer event log. How to read it. |
| Why internal ETH transfers are not in logs | EVM chains | ETH sent by a contract during execution emits no log unless the contract emits an event. Why internal transfers need a trace, and how to read them. |
| Polygon PoS finality: milestones and confirmations | Polygon | On Polygon PoS, milestones give deterministic finality on the chain itself. How to read the finalized block over RPC instead of counting confirmations. |
| Base block heads: unsafe, safe and finalized | Base | On Base and other OP Stack chains, latest is the unsafe head, safe means data is on Ethereum, finalized means Ethereum finalized it. What to use. |
| TRON energy vs bandwidth: USDT transfer costs | Tron | TRON USDT transfers need energy and bandwidth. Compare recipient states, resource recovery and TRX burn, then simulate before sending. |
| Why a TRC-20 balanceOf call returns zero | Tron | triggerconstantcontract returns zero or nothing for balanceOf when the address parameter is encoded wrongly or visible does not match the addresses. |
| Why a TON transaction can't be found by hash alone | TON | TON transactions belong to an account and are ordered by logical time. Find one by account, lt and hash, and page history with the lt/hash pair. |
| Why TON funds came back: bounced messages | TON | A bounceable TON message that fails at its destination comes back as a bounce. When that happens, and why wallets use non-bounceable addresses. |
| How Stellar sequence numbers work | Stellar | Every Stellar transaction must carry the source account's next sequence number. How to read it and keep concurrent senders from colliding. |
| Why a Stellar M… address maps to a G… account | Stellar | A muxed M… address combines a G… account with a 64-bit ID and does not exist on the ledger. Why payments to it land on the G account. |
| Why Stellar RPC getEvents returns no events | Stellar | getEvents returns nothing when filters do not match: contract IDs, event type, or topics that are not base64 XDR ScVal. An old startLedger errors instead. |
| JSON-RPC batches: order, ids and partial errors | All chains | In a JSON-RPC 2.0 batch, responses may come back in any order and each can fail on its own. How to match them by id and handle partial failures. |
| Why newHeads repeats a block number | EVM chains | An eth_subscribe newHeads stream can deliver two headers at one height during a reorg and skip blocks while a node catches up. How to handle both. |
| Robinhood Chain Testnet: Chain ID 46630 & Faucets | Robinhood Chain | Testnet chain ID 46630, public RPC and feed, explorer, two faucets and their rules — and what changes when you move to mainnet 4663. |
| Deploy on Robinhood Chain with Foundry or Hardhat | Robinhood Chain | Deploy and verify a contract on Robinhood Chain: forge create or Hardhat, Blockscout verification, the 96 KB size limit and the errors that stop a deploy. |
| Robinhood Chain Explorers: Blockscout, RobinScan | Robinhood Chain | Robinhood Chain's official explorer is Blockscout; RobinScan is on Etherscan's domain. Which to use, and the RPC call that answers it in code. |
| Robinhood Chain block.number vs eth_blockNumber | Robinhood Chain | On Robinhood Chain, Solidity's block.number is an Ethereum L1 estimate, while eth_blockNumber is the L2 block. Three live values side by side and fixes. |
| Bridge ETH to Robinhood Chain: Routes, 7-Day Exit | Robinhood Chain | Bridge ETH to Robinhood Chain: the Delayed Inbox address and depositEth() to check in your wallet, the 7-day way back, and an RPC arrival check. |
| Solana Shreds and Turbine: How Shred Streams Work | Solana | How Solana shreds, Turbine and FEC turn ledger entries into an early transaction feed, and what raw, deshredded and processed data can tell you. |
| Solana Geyser Plugin and Yellowstone gRPC, Explained | Solana | Understand Solana's Geyser interface, Yellowstone gRPC filters, commitment and replay, then choose between your own node and a managed provider. |
| How to Calculate a Solana Priority Fee | Solana | Solana priority fee = compute unit price × limit ÷ 1,000,000. A worked example, how to read recent fees per account, and why the limit costs you money. |
| Jito Tip vs Priority Fee: What Each One Buys | Solana | A priority fee bids for position inside a leader's scheduler. A Jito tip bids in Jito's auction. When you need one, the other, or both, and the 1,000 lamport floor. |
| RPC credits, compute units and flat pricing explained | All chains | How RPC providers meter usage with credits, compute units and request units, how to turn an allowance into requests, and when flat RPS pricing costs less. |
Glossary
Short definitions of the terms these pages use — slot, commitment level, nonce, chain ID and more. Full list at /learn/glossary.
| Term | Definition |
|---|---|
| ABI (application binary interface) | The Contract Application Binary Interface (ABI) is the standard way to interact with contracts in the Ethereum ecosystem, from outside the chain and between contracts. |
| ADNL (TON) | ADNL (Abstract Datagram Network Layer) is TON's network protocol; ADNL over TCP is used by clients to communicate with liteservers. |
| Arbitrum Orbit chain (Arbitrum chain) | An Arbitrum Orbit chain is a dedicated blockchain built with the Arbitrum Nitro stack that settles to a parent chain such as Ethereum; Arbitrum's documentation now calls it simply an Arbitrum chain, and Robinhood Chain's documentation uses the name Arbitrum Dedicated Blockchains. |
| Archive node | An archive node retains the full historical state of the chain, so it can answer state queries at any past block, not only near the head. |
| Associated token account (ATA) | An associated token account (ATA) is the canonical SPL token account for one wallet and one mint, located at an address derived from the wallet address, the token program and the mint. |
| Base fee (EIP-1559) | The base fee is the minimum price per unit of gas, set by the protocol for each block under EIP-1559; it is burned rather than paid to the block producer. |
| Block height | Block height is the number of blocks beneath a block in its chain — its position in the sequence of produced blocks, counted from genesis. |
| Block tag | A block tag is a named block parameter in Ethereum JSON-RPC — earliest, latest, safe, finalized or pending — used instead of a block number. |
| Bounceable address (TON) | A bounceable address is a TON user-friendly address whose flag asks the sender to set the bounce flag, so a message returns its value if the destination cannot process it. |
| Chain ID | A chain ID is a number that identifies an EVM chain and is included in every transaction signature under EIP-155, so a transaction signed for one chain is invalid on another. |
| Chain reorganization (reorg) | A chain reorganization (reorg) happens when a node switches its view of the chain head to a competing branch, replacing one or more of its most recent blocks. |
| Commitment level | A commitment level tells a Solana RPC node how settled the state it reads must be: processed, confirmed or finalized. |
| Compute unit (Solana) | A compute unit is the smallest unit of measure for consumption of computational resources on Solana. |
| Energy and bandwidth (TRON) | Bandwidth pays for transaction bytes on TRON. Energy pays for smart-contract execution. |
| EOA vs contract account | An externally owned account (EOA) is controlled by whoever holds its private key; a contract account is a deployed smart contract controlled by its code. |
| Epoch (Solana) | An epoch is the number of slots for which a Solana leader schedule is valid. |
| Event log | An event log is a record emitted by an EVM contract during a transaction, made of the emitting address, up to four topics and a data field, and stored in the transaction's receipt. |
| Event topic | A topic is one of up to four 32-byte indexed fields of an EVM event log; topic 0 is normally the keccak-256 hash of the event's canonical signature. |
| Finality | Finality is the point after which a block — and every transaction in it — can no longer be reverted by the network's consensus rules. |
| Fork | A fork is a ledger derived from common entries that then diverged from another. |
| Gas | Gas is the unit that measures the computational work an EVM transaction performs; the sender pays for the gas used at a price per unit. |
| History retention window | A history retention window is the range of past blocks, ledgers or state a particular node still keeps and can answer from. |
| Horizon (Stellar) | Horizon is the REST API server for the Stellar network: it serves accounts, payments, operations, effects, ledgers and transactions as HAL JSON. |
| Jetton (TON token standard) | A jetton is a fungible token following TON's TEP-74 standard, with a jetton master contract and a separate jetton wallet contract for each holder. |
| JSON-RPC | JSON-RPC 2.0 is a stateless remote-procedure-call protocol that encodes a request as a JSON object with jsonrpc, method, params and id, and answers with either a result or an error. |
| Lamport | A lamport is a fractional unit of Solana's native token, with the value of 0.000000001 SOL, so 1 SOL = 1,000,000,000 lamports. |
| Layer 2 rollup | A rollup is a layer 2 that performs transaction execution outside layer 1 and posts the data to layer 1, where consensus is reached. |
| Leader and leader schedule (Solana) | The leader is the role of a Solana validator while it appends entries to the ledger; the leader schedule is the sequence of validator public keys mapped to slots. |
| Ledger (Stellar) | A ledger is a representation of the state of the Stellar network at a given point in time, shared across all network nodes. |
| Liteserver (TON) | A liteserver is a TON full node that serves blockchain data to lite clients over the ADNL protocol, answering queries about blocks, accounts and transactions. |
| Logical time (TON) | Logical time (lt) is a counter carried by every TON transaction that strictly increases with each new transaction of the account. |
| Masterchain (TON) | The masterchain is TON's workchain -1, which holds global configuration and system smart contracts. |
| Mempool (transaction pool) | A mempool (transaction pool) is the set of valid, not-yet-included transactions a node holds and relays while they wait to be put into a block. |
| Merkle proof (eth_getProof) | A Merkle proof is the list of trie nodes along the path from a state root to an account or storage slot, enough to verify that value without the full state. |
| Muxed account (Stellar) | A muxed account combines a Stellar G… account with a 64-bit integer ID into an M… address; it does not exist on the ledger, only its underlying G account does. |
| Node sync status | A node's sync status says whether it has caught up with the chain head or is still importing blocks. |
| Nonce (account nonce) | An account nonce is the number of transactions an externally owned account has had included on chain; each new transaction must carry exactly the next nonce. |
| Pagination cursor | A pagination cursor is an opaque marker of a position in an ordered result list; passing it back asks the API for the records after (or before) that position. |
| Preflight simulation (Solana) | Preflight is the set of checks Solana's sendTransaction runs before forwarding a transaction: signature verification, blockhash recency and a simulation. |
| Priority fee | A priority fee is an optional amount paid on top of a network's base fee to make a transaction more attractive to include. |
| Program derived address (PDA) | A program derived address (PDA) is a Solana address derived deterministically from a program ID and a set of seeds, chosen so that it has no corresponding private key and only the program can sign for it. |
| Rate limit (HTTP 429) | A rate limit caps how many requests a client may send in a given amount of time; exceeding it returns HTTP 429 Too Many Requests. |
| Raw (signed) transaction | A raw transaction is a transaction that has already been signed and serialized by the sender, submitted to a node as bytes. |
| Recent blockhash (Solana) | A blockhash is a unique hash that identifies a Solana block; every transaction includes a recent one, which limits how long the transaction stays valid. |
| Rent exemption (Solana) | Rent exemption is the minimum lamport balance a Solana account must hold, in proportion to its data size, to stay on-chain. |
| Sequence number (Stellar) | A Stellar sequence number identifies and verifies the order of transactions from a source account; each transaction must use the account's stored sequence number plus one. |
| Sequencer (L2) | A sequencer is the component of a layer 2 rollup that orders incoming transactions and produces the rollup's blocks. |
| Server-Sent Events (SSE) | Server-Sent Events (SSE) let a server push messages to a client over one long-lived HTTP response with the text/event-stream type; the channel is one-way, server to client. |
| Shred (Solana) | A shred is a fraction of a Solana block — the smallest unit sent between validators. |
| Slot | A slot is the period of time for which a Solana leader ingests transactions and produces a block. A slot that did not produce a block — because the leader was offline or its fork was abandoned — is a skipped slot. |
| Solidified block (TRON) | A solidified block is a TRON block that has become irreversible because at least 19 of the 27 active super representatives have produced a block at or above its height. |
| Soroban and Stellar RPC | Soroban is the smart contract platform on the Stellar network; its data is served by Stellar RPC rather than by Horizon. |
| Stake-weighted QoS (SWQoS) | Stake-weighted Quality of Service is a Solana mechanism that lets leaders identify and prioritise transactions proxied through a staked validator, as a sybil-resistance measure. |
| State root | The state root is the root hash of the global state after applying the changes in a block, stored in the block header. |
| Stock Token (Robinhood Chain) | A Stock Token is an ERC-20 token on Robinhood Chain, with 18 decimals, that the issuer describes as a tokenised debt security giving economic exposure to one underlying share or ETF; dividends and splits change its uiMultiplier() instead of holders' balances. |
| Stroop (Stellar) | A stroop is the smallest unit of a Stellar asset, one ten-millionth of it. |
| Super representative (TRON) | A super representative (SR) is one of TRON's 27 active block producers, elected through delegated proof of stake by stakers' votes. |
| Transaction receipt | A transaction receipt is the record of what happened when an EVM transaction was included: its status, gas used, logs and, for deployments, the new contract address. |
| Transaction trace | A transaction trace is a replay of an EVM transaction's execution that reports what happened inside it — for example every call frame, with its type, sender, recipient and value. |
| TRC-20 | TRC-20 is TRON's standard for fungible token contracts, parallel to Ethereum's ERC-20. |
| TRON address formats (hex 41 and Base58) | A TRON address is 21 bytes — the byte 0x41 followed by 20 bytes — written either as 42 hex characters starting with 41 or as 34 Base58Check characters starting with T. |
| WebSocket subscription | A WebSocket subscription asks an RPC node to push notifications for new events — blocks, logs, account changes — over an open WebSocket connection. |
| Wei and gwei | Wei is the smallest denomination of ether, 10⁻¹⁸ ETH; gwei (giga-wei) is 10⁻⁹ ETH. |
| Workchain (TON) | A workchain is a TON blockchain with its own rules and account space. |
Longer reads from the blog
Worked, dated analyses that go further than a reference entry. All posts at /blog.
- getProgramAccounts pricing across Solana providers: credits, calls, bytes and buckets
- Alpenglow is live on Solana mainnet: what block consumers and dashboards need to change
- The BNB Smart Chain methods the Triport dedicated pool now covers
- Solana RPC latency: what we broke, what we fixed, and how many milliseconds our gateway adds
- How a Solana launchpad indexer turns validator events into token cards
- Pump.fun bonding curves, almost bonded tokens and migration explained
- Zero platform fee Solana trading — what you still pay
- Racing multiple block feeds: how we deliver the earliest copy of every Robinhood block
- Base and Robinhood Chain side by side: what a trading bot must change
- First-come, first-served: pricing transactions on Robinhood Chain
- What changes when you port a dApp from Ethereum to Robinhood Chain
- Reading Robinhood Stock Tokens on-chain: balances, uiMultiplier and transfers
- Reading BNB Smart Chain pending transactions: txpool, subscriptions and their limits
- eth_getLogs block range limits on Ethereum, BSC, Base, Polygon, TRON and Robinhood Chain
- Processed, safe, finalized: what "final" means on Solana, Ethereum, Stellar, TON and sequencer L2s
- How we verify RPC provider pricing: sources, dates and a 45-day freshness rule
- Priority fees on Solana vs Ethereum, Base and Polygon: same word, different auctions
- Sizing an RPC plan from your workload: sustained RPS, burst and heavy-method buckets
- What a Solana DAS API workload really costs: per-call credits vs flat plans
- SSE vs WebSocket vs gRPC: choosing a transport for blockchain data
- TRON USDT transfer history via JSON-RPC: logs, block windows and address formats
- Watching incoming payments on Solana, Ethereum, Stellar and TON: one task, four designs
- Yellowstone gRPC filters in practice, and the same filter set over a WebSocket bridge
Solana DAS API
The Digital Asset Standard API is a closed set of read methods for regular and compressed Solana NFTs. Full reference at /learn/das.
| DAS method |
|---|
| getAsset |
| getAssetProof |
| getAssetsByGroup |
| getAssetsByOwner |
| getTokenAccounts |
| searchAssets |
How to use this section
- If your problem has a JSON-RPC or HTTP error code, use the RPC error reference instead — every entry there names its code.
- If a call succeeds but the result is empty, null or missing data you expected, find your chain and symptom in the Learn pages table.
- If you're reading Solana assets (including compressed NFTs) through the Digital Asset Standard API, open a DAS method below.
FAQ
- What's the difference between Learn and the RPC error reference?
- The error reference documents JSON-RPC and HTTP codes, each with a cause and a fix. Learn documents RPC and protocol behavior that has no error code to look up — for example, why a history call returns an empty array, or what the DAS API is and which methods belong to it.
- Which chains does Learn cover?
- Each page is about one chain and says which in the Chain column of the table above; the DAS API pages are Solana-only.
- What is the Solana DAS API?
- A read-only JSON-RPC API for Solana's Digital Asset Standard: getAsset, getAssetsByOwner, searchAssets and the rest, covering both regular and compressed NFTs.
- Where are the RPC methods documented?
- Every network's methods are indexed at /docs/methods; DAS methods are listed below and at /learn/das.