Solidity support
Learn how Solidity behaves differently on Arbitrum compared to Ethereum, including blockhash, block.coinbase, block.number, msg.sender, and other EVM opcode differences for smart contract developers.
Arbitrum chains are Ethereum-compatible and, therefore, allow you to trustlessly deploy Solidity smart contracts, as well as contracts written in Vyper or any other language that compiles to EVM bytecode. However, when calling certain properties and functions on a Solidity smart contract, there are some differences between the result you'd obtain if that contract were on Ethereum and the result on Arbitrum.
This page compiles a list of functions and properties that return a different result when called in Arbitrum.
Differences from Solidity on Ethereum
Although Arbitrum supports Solidity code, there are differences in the effects of a few operations, including language features that don't make sense in the child chain context.
| Operation | Description |
|---|---|
blockhash(x) | Returns a cryptographically insecure, pseudo-random hash for x within the range block.number - 256 <= x < block.number. If x is outside of this range, blockhash(x) will return 0. This hash includes blockhash(block.number), which always returns 0 just like on Ethereum. The returned hashes do not come from the parent chain. ⚠️ Arbitrum's child chain block hashes should not be relied on as a secure source of randomness. |
block.coinbase | Returns the designated internal address 0xA4b000000000000000000073657175656e636572 if a sequencer posted the message. If it's a delayed message, it returns the address of the delayed message's poster (Note: the handling of delayed message's block.coinbase will likely be changed in a future ArbOS version). |
block.difficulty | Returns the constant 1. |
block.prevrandao | Returns the constant 1. |
block.number | Returns an "estimate" of the block number of the first non-Arbitrum ancestor chain at which the sequencer received the transaction. For more information, see Block numbers and time. |
msg.sender | Works the same way it does on Ethereum for regular child chain to child chain transactions. For transactions submitted via the delayed inbox, it will return the child chain address alias of the parent chain contract that triggered the message. For more information, see address aliasing. The aliased value also appears in the from field on RPC responses — see RPC methods. |
OPCODE PUSH0 | This OPCODE was added as part of ArbOS 11 and is now supported. |
RPC methods
Compare Arbitrum and Ethereum RPC method responses, including additional transaction types, fields, and blocks returned by Arbitrum nodes. Covers eth_getTransactionByHash, eth_getBlockByHash, and other JSON-RPC methods.
Precompiles
Arbitrum-specific precompiled contracts and their interfaces.