NEAR Explorer: How to Read, Verify, and Query NEAR Blockchain Data

What a NEAR explorer actually shows

A NEAR explorer is a front end over indexed NEAR data. It presents blocks, transactions, execution outcomes, receipts, account balances, access keys, and contract calls in a human-readable layout. Public explorers such as the NEAR Explorer Selector, NearBlocks, and specialized views like the NEAR Intents explorer each index and present different slices of the chain, so the same transaction can look different depending on which view you open.

The important distinction is between the explorer as a presentation layer and the NEAR RPC as the source of truth. Explorers typically run their own indexers, which may lag the chain head by seconds or minutes, may prune historical detail, or may label data using heuristics. When accuracy matters, confirm the explorer view against a direct RPC call. For endpoint selection, the RPC Assistant covers concrete provider choices; this article focuses on the method.

• Block explorers show block height, timestamp, and producer.
• Transaction views show the signed transaction and its outcome.
• Receipt views show cross-contract execution, which is where NEAR differs from account-model chains.
• Account views show balance, storage usage, code hash, and access keys.

Assumptions and prerequisites

The procedures below assume you have a NEAR RPC endpoint URL, which you should treat as a secret if it contains an API key. You need curl or a JavaScript runtime with fetch, and optionally Python for scripting. No private key is required for read-only queries; signing is only needed when you submit transactions, which is out of scope here.

Set an environment variable so the examples stay portable. Never commit a keyed endpoint to a repository. If you are choosing a provider, start from the OnFinality NEAR network page and the RPC endpoint guide, then use the RPC Assistant for a direct recommendation.

export RPC_URL="https://your-near-rpc-endpoint"
# Optional: confirm the endpoint responds
echo $RPC_URL

The NEAR execution model in one mental model

On NEAR, a transaction is not the same as an execution. A signed transaction is included in a block, producing an outcome that contains one or more receipts. Receipts are the units of cross-contract work: a function call can generate receipts that execute in later blocks. This is why an explorer may show a transaction as final while a receipt is still pending, and why a successful transaction outcome does not guarantee that every downstream receipt succeeded.

When you read an explorer, follow the chain: transaction hash, then outcome, then each receipt ID, then each receipt outcome. When you query RPC, use the same sequence. Treating the transaction as the whole story is the most common source of confusion in NEAR troubleshooting.

• Transaction: the signed request submitted by a user or service.
• Execution outcome: the result of applying that transaction in a block.
• Receipt: a unit of work, often a cross-contract call.
• Receipt outcome: success or failure of that unit, with logs and gas burnt.

Verifying a transaction with curl

The NEAR RPC exposes JSON-RPC methods that mirror what explorers display. To inspect a transaction, call tx with the transaction hash and the account that signed it. Replace the placeholders with values from the explorer URL or your own logs.

The response includes the transaction, its execution outcome, and any receipts. Read status.SuccessValue for the top-level result, then inspect receipts_outcome for downstream work. A non-empty Failure object indicates an execution error, and logs often contain the contract-level reason.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": "near-explorer-guide",
    "method": "tx",
    "params": {
      "tx_hash": "TRANSACTION_HASH",
      "sender_account_id": "SENDER_ACCOUNT.near",
      "wait_until": "FINAL"
    }
  }' | python3 -m json.tool

Reproducing an explorer view in JavaScript

A small script makes the verification repeatable. The function below fetches a transaction, prints the top-level status, and lists receipt outcomes with their status and gas burnt. This is the same data an explorer renders, minus the indexer's labels and formatting.

Run it with Node 18 or later, which includes fetch. Keep the endpoint in an environment variable and log only non-sensitive fields if you paste output into a ticket.

const RPC_URL = process.env.RPC_URL;

async function inspectTx(txHash, sender) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 'near-explorer-guide',
      method: 'tx',
      params: { tx_hash: txHash, sender_account_id: sender, wait_until: 'FINAL' }
    })
  });
  const { result, error } = await res.json();
  if (error) throw new Error(JSON.stringify(error));

  const outcome = result.status;
  console.log('top-level:', outcome.SuccessValue !== undefined ? 'success' : 'failure');
  for (const r of result.receipts_outcome || []) {
    const s = r.outcome.status;
    console.log(r.id, s.SuccessValue !== undefined ? 'ok' : 'failed', 'gas:', r.outcome.gas_burnt);
  }
}

inspectTx('TRANSACTION_HASH', 'SENDER_ACCOUNT.near').catch(console.error);

Querying blocks, accounts, and contract state

Explorers also show block-level and account-level data. The block method returns the block header and chunks; the view_account method returns balance and storage usage; view_state returns contract state keys. These calls are read-only and safe to run against a production endpoint, subject to rate limits.

For contract state, prefer view_state with a prefix or use a view call that returns exactly the field you need. Dumping full state from a large contract can be slow and may hit response size limits. If you need historical state, note that NEAR RPC generally serves current state; historical queries require an indexer or archive service.

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' -d '{
  "jsonrpc":"2.0","id":"block","method":"block",
  "params":{"finality":"final"}
}' | python3 -c "import sys,json; b=json.load(sys.stdin)['result']; print(b['header']['height'], b['header']['hash'])"

curl -s -X POST "$RPC_URL" -H 'Content-Type: application/json' -d '{
  "jsonrpc":"2.0","id":"acct","method":"view_account",
  "params":{"finality":"final","account_id":"ACCOUNT.near"}
}' | python3 -m json.tool

A results table procedure for comparing explorer and RPC

When an explorer view and your application disagree, build a small comparison table rather than arguing from screenshots. For each transaction under investigation, record the fields below from both sources and note the timestamp of each observation. Do not fill in numbers you did not observe; the table is a measurement record, not an estimate.

A mismatch in the latest block height usually indicates indexer lag. A mismatch in receipt count or status is more serious and should be resolved by trusting the RPC response, then checking whether the explorer's indexer has caught up. Record the block height at query time so the comparison is reproducible.

Troubleshooting common explorer discrepancies

Most discrepancies fall into a few categories. Unknown transaction errors often mean the transaction has not been included yet, the hash is truncated, or the sender account is wrong. A transaction that shows success while a user reports failure usually means a downstream receipt failed. Balance differences can come from staking, storage costs, or pending receipts.

If an explorer shows a contract call as successful but your application sees an error, check whether your application is reading the transaction outcome or the receipt outcome. If you query by receipt ID, confirm you are using the receipt ID and the account that produced the receipt, not the original signer.

• Unknown transaction: wait for finality, then re-query with the exact hash and sender.
• Success with user-visible failure: inspect receipts_outcome for Failure objects and logs.
• Balance mismatch: account for storage usage, staking locks, and in-flight receipts.
• Missing history: the endpoint may be pruned; use an indexer or archive for old data.
• Rate limits: batch or cache reads instead of polling every block.

Limitations and tradeoffs of explorer-first workflows

Explorers are excellent for human investigation and poor as a system of record. They introduce an indexer between you and the chain, which adds latency and a second implementation that can disagree with RPC. They also apply labels and heuristics that are convenient for browsing but unsuitable for automated decisions.

For production systems, treat the explorer as a debugging aid and the RPC as the interface. If you need historical queries, aggregated analytics, or low-latency reads at scale, consider a dedicated node or an indexing pipeline rather than scraping explorer pages. OnFinality's dedicated node offering and API service pages describe the infrastructure options; pricing for RPC is documented separately.

• Explorer data may lag the chain head.
• Historical state is not generally available from standard RPC.
• Labels and tags are heuristic, not authoritative.
• Scraping explorer HTML is brittle; use JSON-RPC instead.

Next steps: from browsing to programmatic access

Once you can reproduce an explorer view with RPC calls, the next step is to decide whether you need a managed endpoint or your own node. For read-heavy applications, a reliable managed RPC endpoint with clear rate limits is usually sufficient. For indexing, archival queries, or custom retention, a dedicated node gives you control over pruning and throughput.

Review the NEAR network overview, compare RPC pricing, and use the RPC Assistant for a concrete endpoint recommendation. Then adapt the scripts above into your monitoring: alert on failed receipts, track indexer lag by comparing latest block heights, and keep a comparison table for incidents.

• Read the OnFinality NEAR network guide: /en/networks
• Compare managed RPC options: /en/api-service
• Review RPC pricing: /en/pricing/rpc
• Explore dedicated nodes: /en/dedicated-node
• General endpoint guidance: /en/learn/rpc-endpoints-guide