Why Do Tests Pass on Hardhat/Anvil Forks but Break on Mainnet? What Hidden Differences Are We Missing?

This is one of those problems you only respect after getting burned in production.
For us, the biggest culprit was mempool behaviour, not the contract code itself. Local forks have no mempool congestion, no MEV bots, and no delay between tx broadcast → inclusion. On mainnet, even a 3–5 second delay changed the ordering of two dependent transactions and caused a settlement mismatch that never appeared locally.

Another huge difference is real oracle cadence. Chainlink price feeds don’t update at the neat intervals your local mock assumes. During volatile markets, updates cluster — and if your logic depends on “freshness checks,” local environments never reproduce that burst pattern.

Finally: gas estimation lies on forks. Mainnet gas surfing, refunds, and hot storage slots change everything. A function that cost 110k locally suddenly cost 135k on mainnet because surrounding storage slots weren’t empty anymore.

The only mitigation that worked for us:
run a nightly test suite on real mainnet RPCs with no snapshots and sequential state growth.
It’s painfully slow — but brutally honest.

For me the “aha moment” came from storage residue. I always assumed forking “latest block” meant I was testing real state, but in reality Hardhat drops a lot of low-level traces and storage warm/cold slot patterns differ. When I replayed our staking flows on a full archive RPC, gas spiked by 20–30% purely because the storage tree was already bloated from years of writes.

Another trap: some RPCs compress traces or throttle logs. My tests passed on Alchemy but failed on Infura because of slight differences in how they returned historical calls. After that, I started running every critical test across multiple RPC providers.

My personal trap was evm_snapshot addiction 
Locally everything felt “clean” — reset state, run again, perfect outputs. On mainnet nothing resets, and the moment I switched to linear tests (no snapshot, no fresh fork), random state bloat started breaking assumptions. Even integer rounding behaved differently because accumulated dust values were now real.

I now force myself to run a “dirty chain simulation” once a week — 300–400 transactions in a row without resets. That was the only way I caught subtle storage-packing problems.

One thing nobody warned me about: chain-ID mismatches.
Locally everything signs smoothly because the chain ID is whatever your config says. On mainnet, an EIP-155 mismatch broke every signature in our relayer flow. Now I randomize chain IDs and run the suite with multiple env files to make sure nothing is hardcoded. It’s a small check but saves massive pain.

This is exactly why “all tests pass locally” is not enough proof in smart contract interviews.

A stronger interview answer is not just: “I tested it on Hardhat or Anvil.” The stronger answer is: “I checked what can change between a local fork and mainnet — RPC behaviour, oracle freshness, mempool ordering, gas estimation, storage residue, chain ID, signature assumptions, block timing, and whether the test still holds when state grows without snapshots.”

That is also what many Web3 hiring teams quietly look for when they ask debugging questions. They are not only checking whether a junior Solidity developer or blockchain QA engineer knows Hardhat, Foundry, Anvil, or fork testing. They are checking whether the candidate can explain why Hardhat and Anvil fork tests pass locally but fail on Ethereum mainnet, and how they would prove mainnet-readiness before calling the contract production-safe.

For anyone preparing for smart contract debugging rounds, this thread connects well with the Smart Contract Interview Prep Hub here:
Smart Contract Interview Prep: Technical, Security, Debugging & Founder Rounds Explained | ArtofBlockchain

Also related:
Flaky smart contract tests and blockchain QA automation across networks:
As a Blockchain QA Engineer, How Do You Deal With Flaky Smart-Contract Tests That Fail Only on CI? | ArtofBlockchain

If your resume or portfolio says “Solidity testing,” “Hardhat,” “Foundry,” “Anvil,” “fork testing,” or “blockchain QA automation,” this is the kind of debugging explanation that should be visible somewhere — not as a long theory note, but as one clear example of how you handled local-fork-versus-mainnet failure.