Although the majority of RPC methods follow the same behavior as in Ethereum, some methods might produce a different result, or add more information, when used on an Arbitrum chain. This page covers the differences in response body fields you'll find when calling RPC methods on an Arbitrum chain vs on Ethereum.
Comprehensive documentation on all generally available JSON-RPC methods for Ethereum can be found at ethereum.org. As Arbitrum has
go-ethereum at its core, most of the documented methods there can be used with no modifications.
eth_getTransactionByHash and other methods that return a transaction, Arbitrum includes a few additional fields and leverages some existing fields in different ways than Ethereum.
On RPC calls that return transactions, the
type field will reflect the custom codes where applicable.
|Transaction type code
|Transaction type name
|Used to deposit ETH from L1 to L2 via the Arbitrum bridge
|Used to call an L2 contract from L1, originated by a user through the Arbitrum bridge
|Used to call an L2 contract from L1, originated by a contract through the Arbitrum bridge
|Used to manually redeem a retryable ticket on L2 that failed to execute automatically (usually due to low gas)
|Used to submit a retryable ticket via the Arbitrum bridge on L1
|Internal transactions created by the ArbOS itself for certain state updates, like the L1 base fee and the block number
On RPC calls that return transactions, the following fields are added to the returned object.
|On L1 to L2 transactions, this field is added to indicate position in the Inbox queue
Existing fields with different behavior
On RPC calls that return transactions, the following fields will have a different content than what's received on Ethereum.
|On L1 to L2 transactions, this field will contain the aliased version of the L1's
eth_getTransactionReceipt, Arbitrum includes a few additional fields and leverages some existing fields in different ways than Ethereum.
On RPC calls that return transaction receipts, the following fields are added to the returned object.
|The L1 block number that would be used for
block.number calls. More information in Block numbers and time
|Amount of gas spent on L1 calldata in units of L2 gas. More information in Gas and fees
eth_getBlockByHash and other methods that return a block, Arbitrum includes a few additional fields and leverages some existing fields in different ways than Ethereum.
On RPC calls that return a block, the following fields are added to the returned object.
|An approximate L1 block number that occurred before this L2 block. More information in Block numbers and time
|The number of L2 to L1 messages since Nitro genesis
|The Merkle root of the outbox tree state
Existing fields with different behavior
On RPC calls that return a block, the following fields will have a different content than what's received on Ethereum.
|This field is equivalent to
|First 8 bytes is equivalent to
sendCount, second 8 bytes is equivalent to
|Value is fixed at
0x4000000000000, but it's important to note that Arbitrum One currently has a 32M gas limit per block. See Chain params for the gas limit of other chains
Other methods that are slightly different
eth_syncing returns false when the node is fully synced (just like on Ethereum). If the node is still syncing,
eth_syncing returns an object with data about the synchronization status. Here, we provide more details.
Understanding messages, batches, and blocks
Nitro nodes receive transactions from their parent chain and the sequencer feed in the form of messages. These messages may contain multiple transactions that are executed by the node, which then produces blocks. Each message produces exactly one block. In most Nitro chains, the message number and the block number are the same. However, Arbitrum One has pre-Nitro (classic) blocks, so for that chain, message 0 produced block
22207818 (blocks prior to that one are 'classic' blocks). Keep in mind that the offset between message and block number is constant in the chain.
On the parent chain, messages appear in batches. The number of messages per batch changes between batches.
Note that the exact output for the
eth_syncing RPC call of an out-of-sync Nitro node is not considered a stable API. It is still being actively developed and can be modified without notice between versions.
|Last batch number observed on the parent chain
|Last batch that was processed on the parent chain. Processing means dividing the batch into messages
|Last message in the last processed batch
|Number of messages known/queued by the Nitro node
|Last block created by the Nitro node (up-to-date L2 block the node is synced to)
|Message that was used to produce the block above
|If different than 0, this is expected to be greater than
msgCount. This field notes a message that was read from the feed but not processed because earlier messages are still missing
|Last block number from the parent chain that Nitro sees. This is used to debug the connection with the parent chain
|Last block hash from the parent chain that Nitro sees. This is used to debug the connection with the parent chain
Note that if the sync process encounters an error while trying to collect the data above (not expected) this error will be added to the response.
Understanding common scenarios
batchProcessed, some batches have still not been processed
messageOfLastBlock, some messages have been processed, but not all relevant blocks have been built (this is usually the longest stage while syncing a new node)
msgCount, the feed is ahead of the last message known to the node