Execution clients add JSON-RPC methods every few releases, and wallets, indexers and bridges start to call them. This post lists the newer methods that other clients announced, and says for each one what xOneRS serves on main. When this post first went out on 2026-11-15, five of them were missing. The same day, pull requests added four of the five and registered the fifth: eth_simulateV1, eth_callMany and eth_callBundle (#1046), eth_getProof (#1097), and debug_traceBadBlock and debug_intermediateRoots (#1047). None of these is in the v0.1.0 release, and each PR lists checks against geth-XDC that are still to be done.

For the whole surface see the xOne RPC surface and the generated docs/rpc/methods.md.

Which newer read and send methods does xOne serve?

REFERENCE TABLEScroll to explore all columns →
Method What it returns Limits
eth_getStorageValues {address: [slot, ...]} in, {address: [word, ...]} out, 32-byte words, at one block 1 to 1,024 slots in all; else -32602
eth_getAccountInfo {address, balance, codeSize, codeHash, nonce, storageHash} at one block A missing account has zero codeHash and storageHash
eth_sendRawTransactionSync Sends a transaction and waits for its receipt Waits up to 60 s; error 4 at the timeout; error 5 when the transaction leaves the pool with no receipt; 64 waiters per transport
eth_config (EIP-7910) {"current":null,"next":null,"last":null} Every XDC fork is block-gated, so there is no timestamp fork to report, as on geth-XDC
eth_capabilities The head and, for state, transactions, logs, receipts and blocks, the oldest block the node holds Since #1097, stateproofs is enabled and follows the state floor

Sources: spec/rpc/xdc-eth-extensions.md, PR #802, PR #883. The eth_getStorageValues answer is checked against a recorded geth-XDC archive answer at block 131,072. eth_getAccountInfo, eth_getStorageValues and eth_getTransactionAndReceiptProof are also served under the xdc_ prefix.

What do the methods added on 2026-11-15 do?

REFERENCE TABLEScroll to explore all columns →
Method What it does Limits and open checks
eth_simulateV1 Runs blockStateCalls with state and block overrides on a throw-away overlay; later calls see earlier writes; stored state never changes At most 256 blocks and 1,024 calls per request; validation: true is refused; traceTransfers is accepted and ignored. Not yet compared with the execution-apis fixtures or with 50 archive answers
eth_callMany Erigon bundle format Same overlay and limits
eth_callBundle Flashbots-style raw transactions Same overlay and limits
eth_getProof (EIP-1186) Account and storage Merkle proofs over the retained state window Outside the window: the typed unsupported history error. Unit proofs verify; a byte-compare with the geth-XDC archive was not run
debug_traceBadBlock Traces a refused block again from its invalid/ evidence dump, by hash Live-node check still open
debug_traceChain Traces a canonical range At most 32 blocks
debug_standardTraceBlockToFile Writes struct-logger output under <datadir>/traces/
debug_intermediateRoots Registered, but refused Waits for a trie view that can compute roots after each transaction

The limits and open checks are as each PR states them (#1046, #1047, #1097).

How does this compare with what other clients announced?

REFERENCE TABLEScroll to explore all columns →
Method Announced by xOneRS on main
eth_simulateV1 ethrex v31.0.0 served (#1046)
eth_callBundle ethrex v31.0.0 served (#1046)
eth_getStorageValues ethrex v31.0.0, reth 2.0 served
eth_getProof standard in geth and the other Ethereum clients served (#1097)
debug_traceBadBlock reth 2.0 served (#1047)
debug_intermediateRoots reth 2.0 registered, refused (#1047)

The ethrex and reth entries are what their release notes say (ethrex releases, reth v2.0.0). A method a node does not serve answers -32601 the method <name> does not exist/is not available.

What should a bridge use for proofs today?

On a build from main after #1097, eth_getProof for account and storage proofs, inside the node's state window; check eth_capabilities for the floor. For a transaction and its receipt, eth_getTransactionAndReceiptProof, the XDC method that geth-XDC also serves: it returns the transaction and receipt trie paths, root first, and the roots equal the block header's roots. On v0.1.0, only the second is available.

Frequently asked questions

Does xOne support eth_simulateV1?

Yes, on main since PR #1046, with at most 256 blocks and 1,024 calls per request. validation: true is refused for now. It is not in v0.1.0.

Does xOne support eth_getProof?

Yes, on main since PR #1097, inside the retained state window. It is not in v0.1.0, and a byte-compare with geth-XDC is still to be run.

What does eth_sendRawTransactionSync do on xOne?

It sends the transaction and waits up to 60 seconds for its receipt. It answers error 4 at the timeout and error 5 if the transaction leaves the pool without a receipt.

Why does eth_config return three nulls on XDC?

EIP-7910 reports timestamp-based forks. Every XDC fork is activated by block number, so there is nothing to report. geth-XDC answers the same.

Sources