Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

JSON-RPC overview

Compatibility and integration guidance
View as Markdown

Radius exposes a JSON-RPC 2.0 API that works with common Ethereum tooling. Use this page to understand what works as expected, what differs from Ethereum, and where to find method-level details.

Use compatible tooling

Radius works with:

  • viem for TypeScript and Node.js integrations
  • WAGMI for React wallet integrations
  • Foundry for smart contract development and scripting

Most eth_* methods behave as expected. Some methods are divergent or pseudo-supported. Review those differences before production deployment.

Understand key behavior differences

Radius is EVM compatible, but not Ethereum-identical. Keep these differences in mind:

  • eth_blockNumber returns the current timestamp in milliseconds
  • eth_getBalance returns native balance plus convertible USD balance
  • eth_feeHistory returns a pseudo-supported response

For full context and implications, read Ethereum compatibility.

Configure gas and fees correctly

Radius uses fixed gas pricing and accepts both legacy and EIP-1559 fee fields. eth_maxPriorityFeePerGas and eth_gasPrice both return the correct fixed gas price, so viem's built-in fee estimation works with a standard defineChain() — no fee overrides are needed.

Read Gas pricing for details and Tooling configuration for the full chain definition.

Submit transactions synchronously for lower latency

Radius supports eth_sendRawTransactionSync (EIP-7966), which combines transaction submission and receipt retrieval into a single RPC call. Unlike the standard eth_sendRawTransaction, this method waits synchronously for the transaction receipt before returning — eliminating the polling round-trip entirely.

This reduces transaction confirmation latency by approximately 50% and is particularly valuable for latency-sensitive applications such as x402 payment flows, where settlement speed directly affects end-to-end request response time.

  • On success: returns the full transaction receipt object
  • On timeout: returns error code 4 with the transaction hash, so you can continue monitoring
  • On nonce gap: returns error code 6 with the expected nonce, avoiding a separate eth_getTransactionCount call

An optional second parameter sets the maximum wait time in milliseconds. If omitted, the node default is used (recommended: 2 seconds).

See eth_sendRawTransactionSync in the method reference for full parameter and error code details.

Use WebSocket subscriptions with the right access

eth_subscribe is supported for logs only and requires an RPC key with elevated privileges.

  • Supported: logs
  • Not supported: newHeads, newPendingTransactions, syncing

For access and limits, see Network and RPC.

Find the complete method reference

For the full list of divergent, pseudo-supported, and unsupported methods, see:

Related pages