Uniswap V2 Router pairFor hardcodes a stale init-code hash, every Router flow reverts

Hi team

Finding: the Uniswap V2 library pairFor uses a hardcoded init-code hash that does not match the Pair bytecode this repo builds. Every Router flow resolves a phantom pair address and reverts, so the shipped Router cannot add liquidity, remove liquidity or swap.

Reproduction, forge against the pinned checkout. The pairFor test fails with PAIRFOR MISMATCH, which is the buggy outcome. An extended suite of five passes around it: addLiquidity reverts at the getReserves staticcall to the phantom with zero fund movement, swap and getAmountsOut revert identically, the fee-on-transfer path rolls back atomically with no stranding, and a direct Pair control proves the Factory and the Pair work, so the Router resolver is the sole broken leg.

// pairFor as shipped resolves a phantom address; the direct control shows
// Factory.getPair and the Pair itself behave, isolating the Router.

The Router holds 19 direct pairFor call expressions. Impact is liveness only: no value moves and no succeeding transaction strands funds, which is why this is High and not Critical.

Suggested fix: update the library constant from the same build that compiles the Pair, or resolve through the Factory registry, or derive the address from the Factory PAIR_HASH value.

Shahmeer

Thank you for your report!

Could you dive deeper into your issue? We have deployed these contracts on Hoodi (an Ethereum testnet) and Mordor (an Ethereum Classic testnet), and they worked fine without any reported issues. The contract addresses are:

  • Hoodi: 0xF140342cB5C29C1468d91Aee408d7b7271C48b5A
  • Mordor: 0x909f96C1a436B3386E9962e30f3Ce753070ff524