[Application Development] Target EVM version for Solidity contracts

[guidanoli]

Did you check the documentation?

• Yes
• No

Documentation Feedback (Optional)

The documentation doesn't clearly specify which EVM version to target when compiling Solidity smart contracts to EVM bytecode. The closest to an accurate answer is analyze the EIPs included in each network upgrade, and see if all the EIPs in an Ethereum execution-layer hardfork are contemplated.

What type of issue are you experiencing?

• Error
• Feature Request
• General Question

Issue Description

I would like to know which official resource from the OP Stack documentation states which EVM version I should target when compiling Solidity smart contracts meant to be deloyed to OP Stack networks (such as OP Mainnet, OP Sepolia, Base Mainnet, Base Sepolia, etc). This is crucial information. For example, compiling contracts with Solidity 0.8.35 targets the Osaka EVM version, which features the CLZ opcode. However, executing such opcode on OP Mainnet today would fail, because it is an invalid opcode there.

Steps to Reproduce

Consult the official documentation.

Are you using a specific library or SDK?

• OP-SDK
• Viem
• Other
• Not Sure

Are you using the latest version of the library/SDK?

• Yes
• No

Environment Details

No response

Troubleshooting Attempts

No response

What type of support do you need?

• Technical support for issue resolution
• Feature implementation guidance
• General advice or consultation
• Documentation or learning resources

Additional Information

No response

Feedback

No response

[artofbitcoin]

There isn't a single "EVM version" setting in the docs, but each OP Stack network upgrade states which Ethereum execution-layer fork it adopts, so the target follows from which upgrades are active on the chain you deploy to:

OP Stack upgrade	Adopts L1 fork	Highest evmVersion it enables
Canyon	Shanghai	shanghai (PUSH0)
Ecotone	Cancun	cancun (MCOPY, TSTORE/TLOAD, BLOBBASEFEE; no blob transactions on L2)
Isthmus	Prague (7702, 2537, 2935, 7623, …)	prague
Karst	Osaka (7939 CLZ, 7823/7883 MODEXP, 7825 tx gas cap, 7951)	osaka

Sources: the "Execution Layer" sections of the Isthmus and Karst specs, and the Upgrade 19 – Karst notice.

Your CLZ example has changed since you asked. Karst activated on OP Mainnet (and OP, Soneium, Ink, Unichain, Mode, Metal, Zora) at timestamp 1783526401 (2026-07-08 16:00:01 UTC), and on OP Sepolia on 2026-06-17. I checked it against mainnet.optimism.io with a tiny creation-code call that runs CLZ(1):

eth_call {data: 0x60011e60005260206000f3}
block 153963811 (ts 1783526399) -> EVM error: NotActivated
block 153963812 (ts 1783526401) -> 0x...ff   (255, correct)

So osaka bytecode (e.g. solc 0.8.35 defaults) runs on OP Mainnet and OP Sepolia today. Base is on its own upgrade track now; Base Azul adopted the same Osaka EIPs, and the same call returns 0xff on Base Mainnet and Base Sepolia.

For any other OP Stack chain, don't assume: check which upgrades it has activated (its rollup config / superchain-registry entry), or run the same one-liner against its RPC before deploying:

cast call --create 0x60011e60005260206000f3 --rpc-url <RPC>

0x…ff means Osaka opcodes are live; an invalid opcode / NotActivated error means target prague (or lower, per the table) until that chain activates Karst. Setting evmVersion explicitly in your compiler config, rather than relying on the solc default, keeps a solc upgrade from silently changing this.

[guidanoli]

Thank you for such a detailed answer!

[artofbitcoin]

Glad it helped! If this answers your question, could you mark it as the answer? That way others looking for which EVM version to target on OP Stack chains can find it quickly.