bug(pop fork): Foundry deploy fails on local Asset Hub fork eth-rpc with metadata incompatibility

[Daanvdplas]

Summary

pop fork + local eth-rpc works for basic Asset Hub fork checks (cast chain-id, cast balance), but Foundry deploy still fails on the local fork endpoint.

Current blocker error:

server returned an error response: error code -32000: Metadata error: The generated code is not compatible with the node

Context

This follows work from branch feat/asset-hub-fork-eth-rpc (plus follow-up notes captured in c305bc12) intended to improve Asset Hub fork eth-rpc compatibility.

Expected behavior

On a local Asset Hub fork started with --dev, users should be able to:

1. deploy contracts via Foundry (forge create)
2. interact afterwards (cast send, cast call)

against the emitted local eth-rpc endpoint.

Actual behavior

Fork and bridge startup succeed, but deploy path fails with metadata incompatibility.

Reproduction

1) Start local fork + eth-rpc bridge

pop fork \
  --endpoint wss://sys.ibp.network/asset-hub-paseo \
  --dev \
  --port 9946 \
  --eth-rpc-port 8546

Expected startup output includes local endpoints for fork WS and eth-rpc WS.

2) Sanity checks pass

cast chain-id --rpc-url ws://127.0.0.1:8546
cast balance 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 --rpc-url ws://127.0.0.1:8546

3) Foundry deploy fails

forge create Counter --resolc \
  --rpc-url ws://127.0.0.1:8546 \
  --private-key 0x5fb92d6e98884f76de468fa3f6278f8807c48bebc13595d45af5bdc4da702133 \
  --broadcast \
  --constructor-args 0

Observed:

Metadata error: The generated code is not compatible with the node

What already landed (not enough yet)

• Asset Hub eth-rpc startup fallback/retry logic.
• Added/whitelisted runtime API handling paths for revive-related state calls.
• Added anvil compatibility methods (getAutomine, setAutomine).
• Added eth-rpc process wiring to fork/network flows and tests.

These improvements make startup/connectivity better, but do not resolve deploy-path compatibility.

Likely root cause

A runtime/API compatibility mismatch in the deploy execution path (not startup), likely in how deploy-triggered runtime calls are proxied/executed in the fork RPC server path.

Proposed next step

Instrument the exact failing runtime call during forge create, then patch that specific method/path:

1. run fork + eth-rpc with focused debug logs,
2. capture first failing method in deploy path,
3. map it to fork server handling (state_call proxy vs local execution),
4. implement targeted compatibility fix,
5. verify with full deploy + interact flow on local fork.

Notes

• Manual startup argument permutations (including explicit --chain=staging --no-prometheus) were already tried and did not fix deploy.
• Basic connectivity checks are already green; remaining work is deploy-path correctness.

[moliholy]

@Daanvdplas I guess you did, but just to check: did you use specilized polkadot foundry?

[flipchan]

had same problem my workaround was to run the revive test node thats in the polkadot sdk @Daanvdplas