contracts/deployments.json is the single source of truth and is read at runtime by the shared contracts module and by the /verify page.
Mainnet
EVM testnets
MerchantRegistry is at the same address on every chain — 0x42eB264955fC0eE4A9Bd74AEf98DA9b01a142f21 — which is the CREATE2 property working as intended.
“Registry only” means
RouterFee was not deployed because it needs Uniswap infrastructure absent from that testnet. It is a Phase-2 opt-in swap path, so its absence does not affect the pool rails — those need only the registry and the canonical CREATE2 factory, both of which are present.TRON Nile
Pool gate verified.
0x41 CREATE2 predicted equals deployed, proven on Nile for MerchantPoolTron and InvoiceForwarderTron, with a full pay → sweep → distribute → claim cycle netting 99% through Create2FactoryTron. Verified 2026-06-19.End-to-end verification
The v3 pool rail was proven on all six EVM testnets via a Foundry script running the full flow live per chain: deploy pool and forwarder via CREATE2, customer pays 1 USDC, forwarder sweeps 100% into the pool, permissionless distribute, pull claim. Each chain was RPC-verified. The merchant netted 985,050 base units of 1,000,000 — 98.505%, with the distributor reward carved from the merchant share exactly as the contract specifies.Working with the file
forge test rewrites contracts/deployments.json because Deploy.t.sol writes fixtures into it. Always run git checkout -- contracts/deployments.json afterwards. CI fails if it is dirty. A polluted copy breaks the shared contracts module and /verify at runtime.contracts/deployments/ is gitignored; the merged top-level file is not. Reset before every broadcast.
Verification and explorers
The same Etherscan v2 multichain API key works for Etherscan, Basescan, Polygonscan, Arbiscan, and the rest./verify renders the deployed contracts so a customer or operator can independently confirm what they are paying into. It should render the pool and forwarder CREATE2 model alongside the atomic-rail deployments.