# JSON-RPC overview

*Compatibility and integration guidance*

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](/developer-resources/ethereum-compatibility.md).

## 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](/developer-resources/ethereum-compatibility.md#gas-pricing) for details and [Tooling configuration](/developer-resources/tooling-configuration.md#chain-definition) for the full chain definition.

## Submit transactions synchronously for lower latency

Radius supports `eth_sendRawTransactionSync` ([EIP-7966](https://eips.ethereum.org/EIPS/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.

What is distinctive on Radius is what the returned receipt means: because Radius has instant finality, the sync receipt is both fast and **final** (\~100 ms, no reorg). On a typical L2 the equivalent sync receipt reflects only transaction *inclusion* and can still be reorganized until it settles on L1.

This reduces transaction confirmation latency by approximately 50% and is particularly valuable for latency-sensitive applications such as [x402 payment flows](/developer-resources/x402-integration.md), 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
* **On async sends with `NonceTooHigh`**: standard `eth_sendRawTransaction` may queue the transaction for automatic retry instead of discarding it immediately

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

See [`eth_sendRawTransactionSync`](/developer-resources/json-rpc-api.md#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](/developer-resources/network-configuration.md).

## Find the complete method reference

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

* [JSON-RPC API](/developer-resources/json-rpc-api.md)

## Related pages

* [Network and RPC](/developer-resources/network-configuration.md)
* [Fees](/developer-resources/fees.md)
* [Contract addresses](/developer-resources/contract-addresses.md)
* [Ethereum compatibility](/developer-resources/ethereum-compatibility.md)