Skip to main content
NEAR nodes provide RPC access to the network: exchanges use them to query balances, read blocks and receipt outcomes, and submit transactions. There are two types of RPC nodes: regular and archival. A regular RPC node keeps approximately 36 hours of history - 5 epochs of the NEAR blockchain, meanwhile, archival RPC nodes preserve older blocks, and account states for queries at earlier blocks. Exchanges can operate a regular RPC node and use its own archival node or an archival RPC provider for older data. Storage recommendations: RPC hardware · Archival hardware.

​
Regular RPC Node

A regular RPC node provides a gateway for day-to-day exchange operations. Use it to:
  • Read finalized blocks and receipt outcomes to monitor incoming deposits.
  • Submit withdrawals and track their execution.
  • Query current native and fungible-token balances for reconciliation.

​
Resources

​
Archival Node

An archival RPC node provides past blocks, transaction and receipt outcomes, and account and contract states. Use it to:
  • Backfill deposits after downtime that exceeds a regular RPC node’s retention window.
  • Investigate older deposits, withdrawals, and their receipt chains.
  • Query native or fungible-token balances at older block heights for reconciliation.

​
Resources

​
Running Private Nodes

Exchanges running RPC nodes can reduce public exposure and unsolicited peer connections by restricting RPC access and disabling inbound peering. This setup ensures that only authorized applications or nodes can interact with the RPC node, thus enhancing security. RPC access and peering are configured separately. Add the relevant settings below into the node’s config.json, then restart neard.

​
Private RPC Access

Bind RPC to the loopback interface to prevent direct access from other hosts:
For applications on other hosts, bind RPC to a private interface and restrict access through a firewall or VPN.

​
Outbound-only Peering

A node can initiate its ordinary peer connections and exchange blocks and transactions over those connections. Disable inbound connections from ordinary peers with:
NEAR nodes accept inbound peer connections on TCP port 24567 by default - configured through network.addr. Once your node is synchronized, you can close this port in the firewall while keeping inbound_disabled: true.

​
State Sync Caveats

Nodes can follow the chain and catch up over outbound peer connections (i.e. inbound_disabled: true) while the inbound peering port is closed. However, if your node is too far behind, you can open the inbound peering port temporarily to allow incoming connections and catch up more efficiently. Open the port and follow the Epoch Sync setup to refresh network.boot_nodes before starting neard. Once synchronization completes, you can close the peering port to new inbound connections again.
Archival nodes download and process missing blocks instead of using Epoch Sync and state sync to skip ahead. They can use outbound-only peering, but need peers that retain the missing history. Recovery after extended downtime can be slow. Follow archival setup for storage configuration and historical data requirements.

​
Frequently Asked Questions

Yes. Set network.experimental.inbound_disabled to true and restrict RPC access separately. Regular nodes need inbound connectivity for peer state sync during setup or recovery after falling far behind. Archival nodes process missing blocks and need peers that retain that history. See Running Private Nodes for configuration and recovery caveats.
Yes, with an archival configuration and a complete history source. The run flag is:
Follow split-storage archival setup for the network and supported node version. The flag preserves history as the node processes it; it does not restore data missing from an existing pruned database. Epoch Sync and state sync do not provide a complete archive.
Yes. JSON-RPC can be enabled or disabled; configure its listening address with rpc.addr in the node’s config.json file.
Yes.
Yes. GET /status and GET /health provide this interface.
  • /status: node version, block context, and syncing status. Use network RPC for peer information.
  • /health: success/failure if node is up running & progressing
Yes. Use a supported neard release or container image, persist the node’s home and storage volumes, and supply the network’s genesis and configuration. Pin the release and follow node operation guidance.
For regular RPC nodes, follow the Epoch Sync setup, then let the node download recent state through peer state sync. Archival nodes require the archival setup.
Nodes signal supported protocol versions, and upgrades activate according to the protocol upgrade rules. Normal upgrades preserve the chain’s genesis and history. Follow supported node releases and test your integration before an activation boundary.