Summary
Ethereum network upgrades change the behavior of execution-layer JSON-RPC endpoints. Compatibility means the RPC provider has updated nodes to expose new methods, return new block and transaction fields, and continue supporting older calls where backward compatibility is expected. For developers and node operators, this is an operational concern: if an endpoint lags behind a hard fork, requests can fail or return data that no longer matches the chain’s current state. This guide explains how to evaluate compatibility without relying on vendor rankings. Start by checking the provider’s documentation for upgrade support timelines and method availability, then verify behavior on Sepolia before mainnet. Blob-related methods such as eth_getBlobSidecars and eth_blobBaseFee are common post-Dencun additions, but future upgrades may introduce new transaction types or state queries. OnFinality documents current plan details for Ethereum mainnet at /networks/eth and for Sepolia at /rpc-assistant/sepolia-eth-rpc; always confirm live values there. Use the checklist in this article to test any RPC endpoint during an upgrade cycle.
Key Takeaways
- Verify new JSON-RPC methods on testnet before relying on them in production.
- Check that blob transaction fields and methods are returned correctly by your endpoint.
- Treat capacity, rate limits, and WebSocket support as plan-specific settings that must be confirmed in current docs.
- Keep rollback plans and monitoring in place, because upgrades can introduce transient failures.
Why Upgrade Compatibility Is a Provider and Node-Operations Concern
Ethereum hard forks require every node on the network to upgrade its client software to remain in consensus. RPC providers operate many nodes, so a delayed node upgrade can break user requests even if the network itself is healthy. Node operators running their own infrastructure face the same risk: an outdated execution client may return stale state, reject new transaction types, or expose deprecated methods only.
The execution-layer JSON-RPC API is separate from the Beacon/consensus API. Upgrade compatibility for RPC means the execution client’s API continues to answer eth_* calls correctly after the fork. Providers that lag behind may still return pre-upgrade block headers, causing your application to read wrong data.
Operational impact includes failed eth_sendRawTransaction for new transaction types, missing block fields such as blobGasUsed, and timeouts when clients attempt to re-sync. For production applications, this can mean downtime during exactly the period when users expect network changes to be transparent. See /rpc-assistant/leading-ethereum-rpc-solutions-guide for broader provider evaluation criteria.
Distinguishing Execution-Layer RPC from Beacon/Consensus APIs
Execution-layer RPC endpoints handle transaction submission, block queries, receipts, logs, and state reads. The Beacon/consensus API handles validator duties, attestations, sync committees, and chain head events. These two APIs are served by different software and have separate endpoints.
When checking upgrade compatibility, test execution-layer methods first. Consensus-layer changes do not directly affect eth_* calls, but your application may also consume consensus data for staking or indexers. Keep the two separate to avoid diagnosing RPC issues incorrectly.
OnFinality’s Ethereum network page (/networks/eth) documents execution-layer HTTPS and WebSocket access. For a deeper look at the Ethereum RPC API methods, see /rpc-assistant/best-ethereum-rpc-api and /rpc-assistant/ethereum-blockchain-api-2.
Verifying New JSON-RPC Methods, Transaction Types, and Blob Support
Start by confirming the chain ID of the endpoint: a request to eth_chainId should return 0x1 for Ethereum mainnet and 0xaa36a7 for Sepolia. Then test methods introduced by recent upgrades. For Dencun (EIP-4844), the most important are eth_blobBaseFee and eth_getBlobSidecars.
Use curl to check availability on a testnet endpoint before mainnet:
A valid response returns a hexadecimal quantity. If you receive a method not found error, the node has not been upgraded. Also verify that eth_sendRawTransaction accepts type-3 transactions with maxFeePerBlobGas and blobVersionedHashes, and that eth_getTransactionByHash returns blobVersionedHashes for blob transactions.
Backward compatibility matters too: after Dencun, eth_getBlockByNumber should include blobGasUsed and excessBlobGas, while older applications that do not use blobs continue to work. Table 1 lists common checks.
| Criterion | What to check | Why it matters |
|---|---|---|
| eth_chainId | Returns 0x1 (mainnet) or 0xaa36a7 (Sepolia) | Confirms you are connected to the correct chain |
| eth_blobBaseFee | Returns current blob base fee as hex quantity | Required for estimating blob transaction costs |
| eth_getBlobSidecars | Returns sidecar data for a block or transaction hash | Needed by indexers and validators to retrieve blob payloads |
| eth_sendRawTransaction | Accepts type-3 transactions with blob fields | Ensures your application can submit blob transactions after upgrade |
| eth_getBlockByNumber / eth_getTransactionReceipt | Includes blobGasUsed, excessBlobGas, blobGasPrice fields | Maintains backward compatibility and provides new data |
Sepolia and Staging Tests Before Mainnet Rollout
Sepolia is Ethereum’s primary testnet for execution-layer upgrades. It uses chain ID 11155111 (0xaa36a7). Before deploying to mainnet, connect your application to a Sepolia RPC endpoint and run the same calls you will make in production.
OnFinality documents Sepolia HTTPS and WebSocket access, testnet setup, and supported methods at /rpc-assistant/sepolia-eth-rpc. Use that page to obtain a test endpoint and verify current plan details.
- Confirm eth_chainId returns 0xaa36a7.
- Call new methods like eth_blobBaseFee and eth_getBlobSidecars on a block that contains blob transactions.
- Submit a test blob transaction using a funded test account and placeholder private key, then wait for receipt.
- Compare responses against mainnet expectations and assert your application handles new fields.
- If your provider does not expose the method on Sepolia, do not assume it will be available on mainnet after the upgrade.
Capacity, Rate Limits, WebSocket Behavior, Monitoring, and Rollback Planning During Upgrades
During network upgrades, transaction volume and block size can spike. RPC endpoint capacity and rate limits are plan-specific; always verify current limits in the provider’s documentation. OnFinality’s network page (/networks/eth) documents current plan-dependent rate limits and regional access.
WebSocket subscriptions are critical for real-time updates. Check that the provider’s WebSocket endpoint emits new block headers with the added fields and continues to deliver log subscriptions without dropping connections. If you rely on eth_subscribe, test it during a staging period on Sepolia.
Monitoring should track request success rate, latency percentiles, block height lag, and method-specific errors. Rollback planning includes keeping a fallback endpoint or dedicated node, pinning client versions, and having a runbook for switching traffic if a provider becomes incompatible after an upgrade.
| Criterion | What to check | Why it matters |
|---|---|---|
| Rate limits | Current plan limits on requests per second, batch size, and WebSocket connections | Prevents throttling during upgrade spikes |
| WebSocket support | Subscriptions for newHeads, logs, and pending transactions remain stable | Real-time apps may break silently if subscriptions fail |
| Monitoring | Track block height, error rate, method availability | Detect upgrade-related regressions quickly |
| Rollback plan | Fallback endpoint, client version pinning, incident runbook | Allows rapid recovery without manual debugging |
Evergreen Compatibility Checklist
Use this checklist for any Ethereum upgrade, regardless of year or naming. It does not depend on specific fork labels and helps you re-evaluate RPC endpoints whenever the network changes.
- Verify chain ID on mainnet and testnet before any upgrade.
- Check provider documentation and changelog for announced support of new JSON-RPC methods and transaction types.
- Test all new methods on Sepolia first; do not treat testnet success as a guarantee for mainnet, but use it as a smoke test.
- Confirm blob-related fields are present in block, transaction, and receipt responses after the upgrade.
- Review current plan rate limits, WebSocket behavior, and archive/Trace/Debug availability on /networks/eth.
- Keep a fallback endpoint and document rollback steps in case the primary provider lags behind.
- Separate execution-layer RPC from Beacon/consensus API requirements and test each independently.
Frequently Asked Questions
How do I check if an Ethereum RPC endpoint supports a new upgrade method?
Use curl to call the method on a testnet endpoint first, such as eth_blobBaseFee on Sepolia. Compare the response against expected fields and check provider docs.
Is Sepolia safe for production traffic during upgrade testing?
No. Sepolia is a testnet. Use it only for staging and integration tests; production traffic should go to Ethereum mainnet chain ID 1.
What are blob transactions and why do RPC providers need to support them?
Blob transactions introduced in Dencun carry temporary data via blobs. Providers must expose methods like eth_getBlobSidecars and include blob fields in transaction and receipt responses.
Do I need to use a different RPC endpoint for Beacon/consensus APIs?
Yes. Execution-layer RPC (eth_ methods) is distinct from Beacon/consensus APIs. Use separate endpoints and tools for validator and consensus data.
What should a rollback plan include for Ethereum RPC during an upgrade?
Keep a fallback endpoint, pin client versions, snapshot configuration, and monitor block height and method availability on both mainnet and testnet.
Where can I find OnFinality’s current Ethereum mainnet and Sepolia access details?
See the Ethereum network page at /networks/eth and the Sepolia page at /rpc-assistant/sepolia-eth-rpc for HTTPS/WebSocket URLs, rate limits, and archive/Trace/Debug availability.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
