Mumbai deprecation breaks repeatable CI: migrating Polygon test suites to Amoy or a pinned local fork

Resolution

Amoy is not a drop-in replacement for Mumbai. Because the chainId changes from 80001 to 80002, any pre-signed transactions, EIP-155 replay protection, or contract-level chain ID checks will fail. For maximum CI repeatability and determinism, a pinned-block local fork of Polygon PoS mainnet is preferable, provided your tests do not rely on testnet-specific infrastructure.

Amoy vs. Mumbai: Integration Gaps

Confirmed Differences:

• Chain ID: Mumbai (80001) → Amoy (80002). This breaks all existing signed payloads and deployment scripts that hardcode the ID.
• Contract Addresses: System contracts, predeploys, and common test tokens (WETH, USDC) have different addresses on Amoy. Fixtures must be updated.

Likely Behavioral Shifts:

• Gas Dynamics: Amoy uses a different base fee schedule than Mumbai. Hardcoded gas limits or legacy gas price fields in CI scripts may cause unexpected reverts or overpayment.
• Faucet Reliability: Amoy faucets often have stricter rate limits than Mumbai did, which can introduce flakiness in automated pipelines.

Local Forking for Reproducibility

A pinned-block fork of Polygon PoS mainnet (chainId 137) provides a frozen state, eliminating the drift associated with live testnets.

Trade-offs:

• Pros: Deterministic state, no RPC rate limits for faucets, and identical behavior to production for mainnet-compatible contracts.
• Cons: You lose exposure to real-world mempool dynamics, validator reorgs, and testnet-only mock contracts (e.g., mock bridges).

Implementation for Deterministic State

To ensure deployment hashes and state remain consistent across CI runs, use the following approach:

1. Pin the Block: Specify a fixed block number in your configuration. This prevents the fork from drifting as the live chain progresses.
2. Archive Node: Use an archive node RPC (e.g., via Alchemy or QuickNode), as standard nodes often prune historical state required for older block pins.
3. Deterministic Deployment: To keep contract addresses stable across runs, use CREATE2 factories or a deterministic deployment proxy.

Verification Commands:

# Verify Chain ID matches expectations
cast chain-id --rpc-url <YOUR_RPC_URL>

# Verify fork block hash matches explorer
cast block <PINNED_BLOCK_NUMBER> --rpc-url <YOUR_RPC_URL>

Missing Diagnostic: Do your existing tests rely on Mumbai-specific mock contracts or pre-signed transactions that cannot be easily re-generated? If so, a mainnet fork will require you to deploy custom mocks to replace that testnet-only infrastructure.