Arc Foundry extends standard Foundry with Arc-specific precompile logic.
Standard Foundry tools simulate a generic EVM and can’t reproduce Arc-specific
failures like blocklisted address reverts or native USDC transfer errors. The
Arc Foundry tool you use depends on your debugging scenario.
Replay failed transactions
arc-cast run replays a transaction at the block it was included in, showing
the exact revert reason, call trace, and state changes. Unlike standard
cast run, it includes Arc’s precompile logic, so it can reproduce reverts from
blocklisted addresses, failed native USDC transfers, and other Arc-specific
conditions.
Fork testnet state
arc-anvil --fork-url starts a local node seeded with a snapshot of testnet
state. You can call contracts, send transactions, and impersonate accounts
without spending gas or waiting for block inclusion.
Once the fork is running, arc-forge test and arc-cast can target it. You can
also call contracts directly:
Fork a specific block to reproduce a historical issue: pass
--fork-block-number <BLOCK> to arc-anvil. The local node serves the chain
state exactly as it appeared at that block.
Test USDC interactions
arc-forge test --fork-url runs your test suite against a live fork of Arc
testnet. A test that passes on standard anvil can still revert on Arc if your
contract treats msg.value and USDC.balanceOf as independent amounts. Both
views share one balance, but msg.value uses 18 decimals while USDC.balanceOf
uses 6 (see EVM differences for details).
Standard anvil doesn’t simulate this.
If any test fails, check whether your contract assumes separate native and
ERC-20 balances. On Arc, msg.value and USDC.balanceOf reflect the same
underlying balance at different decimal precisions. Adjust your assertions to
account for the 18-to-6 decimal conversion.
For more information about how Arc transactions behave differently from other
EVM blockchains, see EVM differences. 
