B20 caldata simulate can't support

[chencang]

When I use Foundry to simulate certain call data, I aim to trace the details of the stack exceptions that occur during execution. The tokens involved in these transactions come from the B20 protocol on the Base chain. In such cases, an error occurs in the execution stack, indicating “[OpcodeNotFound] EvmError: OpcodeNotFound.” How can I use Foundry to track and resolve such errors?

[VivensB]

OpcodeNotFound is worth separating from the error people usually assume it is, because the common fix does not apply to it. revm raises two different errors here, and I checked both on Foundry 1.8.1.

A valid opcode your EVM version predates gives NotActivated. Etching runtime code that uses TSTORE/TLOAD, which are Cancun-only:

--evm-version cancun     [PASS]  returns 0x2a
--evm-version shanghai   ← [NotActivated] EvmError: NotActivated
--evm-version paris      ← [NotActivated] EvmError: NotActivated

A byte that is not an opcode in any revision gives OpcodeNotFound:

vm.etch(A, hex"0c");                  // 0x0c is undefined
vm.etch(A, hex"deadbeefcafebabe");    // data executed as code

← [OpcodeNotFound] EvmError: OpcodeNotFound
← [OpcodeNotFound] EvmError: OpcodeNotFound

So if you are seeing OpcodeNotFound rather than NotActivated, bumping evm_version will not help. The EVM is not refusing a future opcode, it is executing bytes that are not code.

On a fork that usually comes down to one of:

• The address has no code at the block you forked. Forking before deployment, or a factory-deployed address that does not exist yet at that height. Check with cast code <address> --rpc-url <url> --block <block> at the same block your test uses, not at latest.
• A proxy whose implementation slot is empty at that block. The proxy itself has code, the delegatecall target does not, and execution walks into whatever is there. Read the slot directly: cast storage <proxy> 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url <url> for EIP-1967.
• Code fetched from the wrong chain. Easy to hit when an RPC URL and a chain id disagree, since the address exists on both but holds different bytes.

For tracing it once you know where it lands, forge test -vvvv prints the full call tree and the error sits on the frame that failed, which tells you which address was executing. --debug --match-test <name> steps the same trace opcode by opcode if you need the exact program counter.

If it does turn out to be NotActivated on some other call, then it is the version knob after all, and Base is on Cancun, so evm_version = "cancun" in foundry.toml or --evm-version cancun.

Checked on Foundry 1.8.1 (982849d), with vm.etch rather than a live Base fork, so the error taxonomy is verified but I have not reproduced against the B20 contracts themselves.

[JulienKervarrec]

For B20 tokens specifically there is a more direct cause than a missing contract.

Since the Beryl upgrade, B20 tokens on Base are native Rust precompiles, not EVM contracts. The token address only holds a 1-byte marker: on Base mainnet, eth_getCode for a B20 token (for example 0xb2000000000000000000008f4864d17869e8b3f9, STAR) returns 0xef.

Stock Foundry doesn't know these precompiles. When it forks Base and your calldata reaches a B20 token, it fetches that 0xef byte from the RPC and executes it as bytecode. 0xEF is not an opcode, so revm stops with OpcodeNotFound. Changing evm_version won't help.

Options:

1. base-anvil (base/base-anvil), a Foundry fork that registers the B20 factory, B20 tokens, PolicyRegistry and ActivationRegistry in its EVM. Install with base-foundryup, then use base-forge / base-cast / base-anvil (or base = true in a foundry.toml profile, or FOUNDRY_BASE=true).
2. Upstream Base support is in progress in feat: add Base support MVP #16809 (still open), which adds Base execution and B20 trace decoding to Forge and Cast.
3. Meanwhile, trace on the node instead of locally: debug_traceCall / debug_traceTransaction against a Base RPC with the debug namespace runs the real precompile.

Researched with the help of an AI assistant; the 0xef code was checked on Base mainnet via Blockscout.