feat: Deploy EPV0.7 contracts for Arc Testnet, Monad Testnet, and Monad

[hdang-circle]

Summary

Contracts are deployed and verified:

Monad
Plugin Manager
UpgradableMSCAFactory
ColdStorageAddressBookPlugin
WeightedWebauthnMultiSigPlugin
EPV0.7 Paymaster Proxy
EPV0.7 Paymaster Implementation

Monad Testnet
Plugin Manager
UpgradableMSCAFactory
ColdStorageAddressBookPlugin
WeightedWebauthnMultiSigPlugin
EPV0.7 Paymaster Proxy
EPV0.7 Paymaster Implementation

Arc Testnet
Plugin Manager
UpgradableMSCAFactory
ColdStorageAddressBookPlugin
WeightedWebauthnMultiSigPlugin
EPV0.7 Paymaster Proxy
EPV0.7 Paymaster Implementation

Detail

Contracts are deployed for Monad, Monad Testnet, and Arc Testnet for epv0.7. All contracts are verified

Changeset

N/A

Checklist

• Did you add new tests and confirm all tests pass? (yarn test)
• Did you ensure any new Solidity source code files meet minimum test coverage requirements? (yarn coverage)
• Did you update relevant docs? (docs are found in the docs folder)
• Do your commits follow the Conventional Commits standard?
• Does your PR title also follow the Conventional Commits standard?
• Did you run lint (yarn lint) and fix any issues?
• Did you run formatter (yarn format:check) and fix any issues (yarn format:write)?

Testing

Tests passed

Documentation

N/A

[huaweigu]

Do you mind filing a story to investigate the root cause? Initially I thought we didn't pin down the foundry version, but it seems like we did that.

[osr21]

Arc-specific runtime constraints for the deployed SponsorPaymaster

The contracts are live and visible on ArcScan — confirming the deployment tooling handled evmVersion: "paris" and the single-immutable constructor requirement correctly. A few Arc-specific behaviors that don't show up in deployment verification but affect Paymaster operation at runtime:

1. ERC-7562 + nonReentrant on validatePaymasterUserOp

If SponsorPaymaster.validatePaymasterUserOp (or any function it delegates to during validation) uses a ReentrancyGuard modifier, ERC-7562-compliant bundlers including Pimlico will silently drop UserOps at simulation time — no on-chain error, no revert trace, the UserOp just never appears in a bundle.

The reason: ReentrancyGuard writes _locked — a global storage slot — at function entry. ERC-7562 forbids any global storage write during the validation phase for unstaked Paymasters. onlyEntryPoint provides equivalent protection without the storage write (the EntryPoint's own reentrancy guard prevents nested calls), so nonReentrant is redundant on validation functions and actively harmful.

This is safe to use on postOp (execution phase, not validation phase) if needed.

We hit this on a custom USDC Paymaster built for Arc Testnet — documented in detail at circlefin/arc-node #141.

2. USDC decimal split in postOp gas accounting

Arc's native gas token is USDC with two decimal representations:

Context	Decimals
actualGasCost passed to postOp	18 (wei, native gas accounting)
USDC ERC-20 (0x3600000000000000000000000000000000000000)	6

Converting actualGasCost to a USDC-6 amount requires dividing by 1e12 (not 1e18). An off-by-1e12 error silently mismeasures the charge by a factor of one trillion — the symptom would be USDC Paymaster balances draining orders of magnitude faster or slower than expected, with no obvious on-chain error.

3. Gas estimation for complex UserOp inner calls

eth_estimateGas on Arc Testnet is unreliable for multi-step contract calls (CCTP depositForBurn, receiveMessage, etc.) — it returns data:null rather than a gas estimate (arc-node #80, #108). Bundlers use eth_estimateUserOperationGas internally which handles most cases, but for UserOps with particularly complex inner calls (e.g. a bridging operation as the UserOp's main call), end-to-end testing through Pimlico on Arc is worth doing before assuming estimation works.

---

Arc-specific ERC-4337 constraints (compilation + runtime) are documented with worked examples in circlefin/arc-node PR #114.