How to determine if a target network supports a given EVM opcode?

Question

As a smart contract developer or security researcher, I want to know whether a given EVM opcode is supported on the target network before deployment. This is especially important when using newer versions of Solidity, which may implement new opcodes that aren't yet supported across all networks (e.g. PUSH0, TSTORE/TLOAD).

How can I easily check opcode support using only an RPC endpoint?

Answer 1

Assuming Foundry is installed, this is as simple as:

1. Navigating to evm.codes and identifying the desired opcode's hex value (e.g. PUSH0 -> 5f).
2. Navigating to ChainList and obtaining a public RPC endpoint for the target network.
3. Running the following command: cast call --rpc-url <example-rpc-url> --create 0x5f.
4. If the RPC call reverts, the opcode is not supported on the target network; otherwise, a successful call should print 0x in the terminal output.

Credit to all the EVM chads involved in this discussion.

Additional Context

Example Reverting Call (Unsupported Opcode)

At the time of writing, the BLOBHASH (0x49) opcode is not supported on Polygon Mainnet. Thus, running cast call --rpc-url https://polygon.llamarpc.com --create 0x49 will output the following revert message:

Error: server returned an error response: error code -32000: invalid opcode: BLOBHASH

Example Invalid Opcode

At the time of writing, 0x21 (among other hex values) has no opcode definition. Thus, running cast call --rpc-url <example-rpc-url> --create 0x21 will output the following revert message:

Error: server returned an error response: error code -32000: invalid opcode: opcode 0x21 not defined

A Note on Generalizing to All Opcodes

As noted by @natewelch_ in a comment below this answer, the outlined technique is not immediately generalizable to all opcodes. For example, the POP (0x50) opcode expects an item to already be present on the stack. Of course, the only way to achieve this is by first pushing an item to the stack using the PUSH (0x60) opcode.

So, running cast call --rpc-url <example-rpc-url> --create 0x50 will output the following revert message:

Error: server returned an error response: error code -32000: stack underflow (0 <=> 1)

However, by prepending the deployed bytecode with a PUSH instruction and the corresponding item to be pushed to the stack, running cast call --rpc-url <example-rpc-url> --create 0x607750 is successful and proves that POP is indeed supported.

This caveat applies to all opcodes that require stack input and thus expect a specific stack structure as a precondition to their usage (as documented on evm.codes or elsewhere).