docs: wire Hardhat verify for Arcscan on Arc Testnet

[kutluhaneth46]

Summary

Addresses #84 by wiring @nomicfoundation/hardhat-verify for Arc Testnet in this repository.

Official Deploy on Arc docs already show Foundry/arc-forge verify-contract against https://testnet.arcscan.app/api/. Hardhat users still had no working customChains config here, so Arcscan's "verify manually" path had no in-repo Hardhat reference.

Changes

• Import @nomicfoundation/hardhat-verify and register Arc Testnet (5042002) with Arcscan Blockscout URLs in hardhat.config.ts
• Disable Sourcify so it does not race Arcscan verification
• Add a short verify section to contracts/README.md
• Declare @nomicfoundation/hardhat-verify explicitly in package.json

Usage

export ARC_TESTNET_RPC_URL=https://rpc.testnet.arc.io
npx hardhat verify --network testnet <address> [constructorArgs...]

Notes

• Verified the explorer API responds at https://testnet.arcscan.app/api
• Chain ID matches TESTNET_CHAIN_ID / genesis (5042002)
• Left evmVersion: 'prague' unchanged; that is separate from verification wiring
• Intentionally omitted mainnet customChains: issue docs: Arcscan (Blockscout) smart contract source verification undocumented — hardhat-verify customChains configuration missing #84 suggested 4564, but this repo's networks.mainnet.chainId is 5042

Test plan

• npx hardhat verify --network testnet --help loads with the new plugin
• End-to-end against Arcscan: npx hardhat verify --network testnet --contract contracts/src/memo/Memo.sol:Memo --force 0x5294E9927c3306DcBaDb03fe70b92e01cCede505 reaches Arcscan and reports the genesis Memo contract is already verified (full config path exercised; fresh deploy/verify still welcome from a maintainer with a funded deployer)

[osr21]

Disclosure: I'm an external community contributor, not affiliated with Circle, not a maintainer, and I have no write access to this repository. This is advisory review only.

---

I verified this against the @nomicfoundation/hardhat-verify@2.1.3 source, and the config is wired correctly. Etherscan.getCurrentChainConfig picks the chain config by calling eth_chainId and matching the numeric chainId, not by the network label, so the arcTestnet label only needs to match the key used in etherscan.apiKey (which it does) — it doesn't need to match the networks.testnet key used for --network testnet. The chain ID 5042002 also matches the networks.testnet.chainId already in hardhat.config.ts, so eth_chainId on that network resolves to the new custom entry as intended. I also queried https://testnet.arcscan.app/api directly and it returned a standard Blockscout/Etherscan-shaped error response, confirming the apiURL is live and correctly shaped, and I confirmed the non-empty apiKey placeholder is required (Blockscout ignores its value, but resolveApiKey throws on an empty string), matching the comment already added in the diff.

It's also worth noting the verify task itself wasn't actually missing before this PR: @nomicfoundation/hardhat-toolbox-viem (already a dependency here) loads @nomicfoundation/hardhat-verify internally and lists it as a peer dependency, so the plugin was already active. What this PR actually fixes is the missing etherscan/customChains/sourcify config that tells the plugin where to send verification requests — declaring hardhat-verify directly in package.json on top of that just makes an already-implicit dependency explicit, which is a reasonable but secondary improvement.

One good scoping call: issue #84's suggested config also included an arcMainnet entry with chainId: 4564, but this repo's own hardhat.config.ts has networks.mainnet.chainId: 5042. This PR correctly leaves mainnet out entirely instead of propagating that inconsistent chain ID, which would have shipped a broken mainnet verification config.

On CI: all real jobs on the head commit pass (Rust unit/integration tests, lint/format, Contracts build/test/lint, StepSecurity); only release/publish matrix jobs are skipped, which is expected for this kind of change. The combined status API reports pending with no individual statuses, which looks like an outstanding review/merge-queue gate rather than a failing check.

One open item for the maintainer: the PR's own test plan checkbox for verifying a real deployed testnet contract against Arcscan is still unchecked. I'd do that end-to-end check before merging, since it would catch anything a static config review can't — for example how Arcscan's Blockscout instance handles multi-file source or optimizer metadata for this specific solc version.

[kutluhaneth46]

Thanks @osr21 for the careful advisory review. Agree on the framing: the missing piece was the etherscan/customChains/sourcify wiring, and leaving mainnet out avoids shipping the #84 / repo chain-id mismatch.

I ran the live path from this branch:

1. npx hardhat verify --network testnet --help loads cleanly with the plugin.
2. After compile, npx hardhat verify --network testnet --contract contracts/src/memo/Memo.sol:Memo --force 0x5294E9927c3306DcBaDb03fe70b92e01cCede505 hits Arcscan and returns that the genesis Memo contract is already verified. Same result for Multicall3From at 0x522fAf9A91c41c443c66765030741e4AaCe147D0.

That exercises eth_chainId matching, apiURL, and the non-empty apiKey path end to end. A fresh deploy then verify from a funded maintainer wallet would still be the cleanest merge checkbox for optimizer/metadata edge cases; I updated the PR test plan to reflect what was run.