Skip to main content

RPC Differences

Monad aims to match the RPC behavior as close as possible to Geth’s behavior, but due to fundamental architectural differences, there are some differences listed below.

Logs​

  1. eth_getLogs has a maximum block range, configured by RPC provider but typically set to 1000. Because Monad blocks are much larger than Ethereum blocks, we recommend using small block ranges (e.g. 1-10 blocks) for optimal performance. When requesting a longer range, requests can take a long time to be fulfilled, and may time out.

Transactions​

  1. eth_sendRawTransaction may not immediately reject transactions with a nonce gap or insufficient gas balance as they would on Ethereum. The RPC server was designed with asynchronous execution in mind, and under asynchronous execution, the RPC server may not have the latest account state. Thus, these transactions are initially allowed, as they may become valid transactions during block creation.

  2. eth_sendRawTransaction, eth_call and eth_estimateGas do not accept EIP-4844 transaction type, because EIP-4844 is not supported.

eth_call​

  1. eth_calls that are reliant on old state (i.e. with an old block number) may fail, because full nodes do not provide access to arbitrary historic state. See Historical Data for a fuller discussion.
  1. eth_maxPriorityFeePerGas currently returns a hardcoded suggested fee of 2 gwei. This is temporary.
  2. eth_feeHistory currently also returns default values. This is temporary.

WebSocket (eth_subscribe) behavior​

Parent page: WebSocket Guide

  1. eth_subscribe does not support the syncing or newPendingTransactions subscription types
  2. Reorganizations never occur in the newHeads and logs subscription types, because only real-time data for finalized blocks is presented
  3. Monad-specific extensions to the newHeads and logs subcription types (called monadNewHeads and monadLogs) are provided to offer better latency