RPC Endpoint Deprecation and Migration Guide

The NEAR Protocol's JSON-RPC API is the primary interface for exchanges, data indexers, wallets, and application backends to query chain state, submit transactions, and monitor network activity. As the protocol evolves through Nightshade sharding, stateless validation, and congestion improvements, the underlying data models and query patterns change. This forces the deprecation, modification, or replacement of specific RPC methods. Teams that do not track these changes risk broken integrations, stuck withdrawals, or corrupted data pipelines when a deprecated endpoint is removed or begins returning unexpected results.

RPC endpoint deprecations on NEAR are tied to specific nearcore client releases and protocol version bumps. A method may be marked as deprecated in one release, begin returning warnings or degraded data in the next, and be fully removed in a subsequent mandatory upgrade. The EXPERIMENTAL_ prefix on methods like EXPERIMENTAL_tx_status signals that the interface is unstable and subject to breaking changes without a standard deprecation cycle. Operators and builders must correlate the RPC methods their systems call with the rpc_changes sections of nearcore release notes to build a migration timeline before a breaking change reaches mainnet.

For exchanges and custodians, the highest-risk endpoints are those involved in the deposit and withdrawal lifecycle: query, broadcast_tx_commit, tx, and EXPERIMENTAL_tx_status. A change to the finality parameter or the structure of the status response can break balance reconciliation. For indexers and data platforms, changes to chunk or EXPERIMENTAL_receipt methods can corrupt historical data. Chainscore Labs provides integration impact assessments that map your system's RPC dependency graph against the NEAR deprecation timeline, identifying which services will break, in which release, and what migration work is required to maintain continuity.

NEAR Protocol manages RPC endpoint deprecations through a phased lifecycle tied to the nearcore client release cadence. When a method is identified for removal—often due to architectural shifts like the move to stateless validation or the introduction of a more efficient query pattern—it is first flagged as deprecated in a specific client version. During this phase, the method remains functional but generates warnings in node logs, signaling to operators that its support is temporary. This deprecation window, which typically spans multiple protocol versions, is the critical period for downstream teams to update their services.

The final removal occurs in a subsequent nearcore release, often aligned with a protocol version bump that makes the upgrade mandatory for validators. At this point, calls to the deprecated method return an error, which can cause immediate failures in exchange deposit workflows, indexer data pipelines, and application backends. The operational impact is not uniform: a method used by a block explorer for historical data queries may cause a degraded user experience, while a method used by a custodian for balance checks can halt withdrawals. Teams must correlate the nearcore release notes with their own RPC call patterns to assess the blast radius.

Effective migration requires more than a simple endpoint swap; new methods may have different request parameters, pagination models, or response schemas. For example, a deprecated query might be replaced by a more performant method that requires state witnesses or operates under a different access control model. Chainscore Labs provides integration impact assessments for teams dependent on specific RPC methods, mapping their call surfaces against the deprecation schedule to identify breaking changes, estimate migration effort, and prevent service disruptions before a mandatory client upgrade forces the issue.