bug(anvil): calling function on succesfully deployed contract raises: OpcodeNotFound

[blablalf]

Component

Anvil

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.3.0 (a5c5be5 2025-01-06T00:23:40.588668993Z)

What command(s) is the bug in?

anvil -a 100 --code-size-limit 100000 --host 0.0.0.0 --fork-url $FORK_URL --auto-impersonate --chain-id 31337 --prune-history

Operating System

Linux

Describe the bug

Hello, I am testing my backend with an anvil node inside a docker image. Just after I launch the image container I compile inside it a solidity project with solidity version 0.8.26 that needs cancun upgrade (cancun flag is enabled on these projects). Then I'm forking mainnet with cancun upgrade and deploy the contracts successfully :

Get anvil chain info:

curl -s -X POST  -H "Content-Type: application/json"  --data '{"jsonrpc":"2.0","method":"anvil_nodeInfo","params":[],"id":1}' "localhost:8545"

output:

{"jsonrpc":"2.0","id":1,"result":{"currentBlockNumber":"0x14912bf","currentBlockTimestamp":1736174346,"currentBlockHash":"0x84852a9ccc1cbef898c03e016dc56e095079dc3d9aa046aa54a3e869ab0b1ee8","hardFork":"Cancun"

When I call a specific function of my solidity code, I get the following error:

The contract function "*******" reverted with the following reason:
EVM error OpcodeNotFound

Contract Call:
  function:  *******("arg_types arg_names")
  args:             ("args")
  sender:    0xF343DC09b76CA48F614af06d53C73c4072C38aB3

Docs: https://viem.sh/docs/contract/simulateContract
Version: [email protected]

(I anonymised some data like func name and args).

Since the call doesn't revert in mainnet, I wonder where can this error (OpcodeNotFound) come from.

[grandizzy]

@blablalf could you provide more details (like if you're using foundry docker image and the version or yours), or a simplified way to reproduce the error. It's quite hard to figure out what goes wrong without such.

[blablalf]

@blablalf could you provide more details (like if you're using foundry docker image and the version or yours), or a simplified way to reproduce the error. It's quite hard to figure out what goes wrong without such.

Hello, yes of course.

---

About the image/environnement:
I used the foundry latest tag and created my own image from it. The image used is the following one.

From the foundry image I create my own image by adding a private repo and installing a private dependency. The private repo/dependency are foundry projects with evm version set to cancun and solidity 0.8.26.
Here are the versions of foundry tools of the image (sorry I provided the version of my own laptop into the original issue):

anvil 0.2.0 (fb5f0e1 2024-11-20T16:31:30.573912538Z)
forge 0.2.0 (fb5f0e1 2024-11-20T16:31:30.537736602Z)

Using this image, when I deploy a container I start a script that compiles the repo, start anvil and deploy the contrats.
Here is the anvil start command:
anvil -a 100 --code-size-limit 100000 --host 0.0.0.0 --fork-url ${an_alchemy_mainnet_rpc} --auto-impersonate --chain-id ${FORK_CHAIN_ID:-31337} --prune-history.

---

About the contracts:

• Contracts are using tstore and tload opcodes.
• Used public libs are the following ones:

{ ERC20 } from "solmate/src/tokens/ERC20.sol"
{ IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"
{ SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol"
{ IERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/IERC20Permit.sol"
{ IERC20Metadata } from "@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol"
{ ERC165, IERC165 } from "@openzeppelin/contracts/utils/introspection/ERC165.sol"
{ IWETH9 } from "@uniswap/universal-router/contracts/interfaces/external/IWETH9.sol"
{ Payments } from "@uniswap/universal-router/contracts/modules/Payments.sol"
{ BytesLib } from "@uniswap/universal-router/contracts/modules/uniswap/v3/BytesLib.sol"
{ V3SwapRouter } from "@uniswap/universal-router/contracts/modules/uniswap/v3/V3SwapRouter.sol"
{ IAllowanceTransfer } from "permit2/src/interfaces/IAllowanceTransfer.sol"
{ SafeTransferLib } from "solmate/src/utils/SafeTransferLib.sol"
{ LidoRouterLib } from "../libraries/lido/LidoRouterLib.sol"
{ UniswapV2RouterLib } from "../libraries/uniswap/UniswapV2RouterLib.sol"
{ LidoImmutables } from "../modules/lido/LidoImmutables.sol"
{ IUniswapV2Pair } from "@uniswap/v2-core/contracts/interfaces/IUniswapV2Pair.sol"
{ UniswapV2Library } from "@uniswap/universal-router/contracts/modules/uniswap/v2/UniswapV2Library.sol"
{ Constants } from "@uniswap/universal-router/contracts/libraries/Constants.sol"
{ SafeCast } from "@openzeppelin/contracts/utils/math/SafeCast.sol"
{ IUniswapV2Router } from "../../interfaces/uniswap/IUniswapV2Router.sol"
{ IUniswapV2RouterErrors } from "../../interfaces/uniswap/IUniswapV2RouterErrors.sol"

---

About how I get the error:

• The error I get is specific to the contract I described earlier (I can make successfull calls to other contracts deployed on my anvil network).
• The contract seems well deployed since the cast code command gives me a relevant output.

[grandizzy]

@blablalf could you please try the same with nightly tag (instead latest) and see if same issue? https://github.com/foundry-rs/foundry/pkgs/container/foundry/332065449?tag=nightly

[blablalf]

@blablalf could you please try the same with nightly tag (instead latest) and see if same issue? https://github.com/foundry-rs/foundry/pkgs/container/foundry/332065449?tag=nightly

After using the nightly I got the same error unfortunately.

[grandizzy]

@blablalf could you please try the same with nightly tag (instead latest) and see if same issue? https://github.com/foundry-rs/foundry/pkgs/container/foundry/332065449?tag=nightly

After using the nightly I got the same error unfortunately.

I see, wanted to make sure you run the version with Cancun enabled by default. Just to double check, in

anvil -a 100 --code-size-limit 100000 --host 0.0.0.0 --fork-url ${an_alchemy_mainnet_rpc} --auto-impersonate --chain-id ${FORK_CHAIN_ID:-31337} --prune-history

${an_alchemy_mainnet_rpc} is mainnet rpc, any reason you set different chain id?

[blablalf]

@blablalf could you please try the same with nightly tag (instead latest) and see if same issue? https://github.com/foundry-rs/foundry/pkgs/container/foundry/332065449?tag=nightly

After using the nightly I got the same error unfortunately.

I see, wanted to make sure you run the version with Cancun enabled by default. Just to double check, in

anvil -a 100 --code-size-limit 100000 --host 0.0.0.0 --fork-url ${an_alchemy_mainnet_rpc} --auto-impersonate --chain-id ${FORK_CHAIN_ID:-31337} --prune-history

${an_alchemy_mainnet_rpc} is mainnet rpc, any reason you set different chain id?

I understand, by the way the last time this error was mentioned was in an issue that was over a year old on this repo and was related to cancun support.

31337 is the default anvil chain id, in the current case I don't edit it. I think it can therefore be ignored excepted if you think I should use another chain id.

[grandizzy]

31337 is the default anvil chain id, in the current case I don't edit it. I think it can therefore be ignored excepted if you think I should use another chain id.

Probably won't make any difference but what if you don't specify any (that is inheriting the mainnet chain id)?

[blablalf]

31337 is the default anvil chain id, in the current case I don't edit it. I think it can therefore be ignored excepted if you think I should use another chain id.

Probably won't make any difference but what if you don't specify any (that is inheriting the mainnet chain id)?

Oh yes you are right it will follow the forked chain id. I tested it but it didn't change the error.