Repository navigation
A consumer deploying to a subset of supportedNetworks() cannot bind RainDeployVerify #250
Description
Activity
Duplicate of #246 — same gap, same consumer, same proposed shape. Consolidating
on #246 because it is already labelled and has a PR in progress against it.Two things stated here and not there, ported onto #246 so they are not lost:
-
The
[etherscan]half needs its own answer. A network with no Etherscan
deployment is a fact about the network rather than about any consumer, so
scopingtestSupportedNetworksAreFullyConfiguredto the consumer's own
roster still fails on st0x's correct config — Robinhood has no entry on
purpose, since chain 4663 is not indexed by Etherscan v2 and it verifies
through Sourcify. Membership against the networks that HAVE an Etherscan
deployment, rather than against every deploy target. -
Why it is more than a config nit. The README's argument for
RainDeployVerifybeing the one binding is that "a check a repo has to opt
into is a check most repos do not run". A consumer that cannot bind it runs
none of them, which is worse than opting out of one — st0x hand-enumerates
~695 lines of per-version, per-chain pins instead, which is what this
package exists to delete.
The call-site inventories also differ: this issue names
RainDeployVerifyChain.testSuitesLiveOnEverySupportedNetwork, #246 names
checkDeployedOnSupportedNetworksandtestSupportedNetworkChainIdsAreBound.
All three are being checked against the current tree rather than either list
being trusted.-
RainDeployVerifyChain.testSuitesLiveOnEverySupportedNetworkandRainDeployVerifySnapshot.testSupportedNetworksAreFullyConfiguredboth readLibRainDeploy.supportedNetworks(), which isinternal purewith a fixed list of nine. Neither the function nor the tests arevirtual, so a consumer whose deploy targets are a subset of the org's nine cannot bindRainDeployVerifyat all.st0x.deployis that consumer. It deploys to five — Base, Ethereum, HyperEVM, Robinhood, BSC — andLibRainDeploy.supportedNetworks()adds Arbitrum, Base Sepolia, Flare and Polygon. Binding the stack today fails two ways:NotDeployedOnNetworkfor every release — not a defect in st0x, a different question being asked.[etherscan]key. st0x deliberately has none for Robinhood: chain 4663 is not indexed by Etherscan's v2 API, and its own comment records that an entry there "would only make foundry demand an API key it cannot use". Its verification path is--verifier sourcifyinstead. So the one check that enforces the[etherscan]half fails on a config that is correct.The asymmetry is already acknowledged for the broadcast:
RainDeployBroadcast.deployNetworks()isvirtual, and its docstring names st0x's per-dispatch network selection as the reason. The verification side has no equivalent, so the same consumer can deploy through this package but cannot verify through it.What makes this more than a config nit
The README's argument for
RainDeployVerifybeing the ONE binding is that "a check a repo has to opt into is a check most repos do not run". A consumer that cannot bind it runs none of them, which is strictly worse than opting out of one — st0x currently hand-enumerates ~695 lines of per-version, per-chain pins, which is exactly what this package exists to delete.Shape of a fix, for discussion
A
deployTargets()hook onRainDeploySuitesBasedefaulting toLibRainDeploy.supportedNetworks(), read by both groups in place of the direct call. That keeps the default behaviour for a repo that deploys everywhere, and it is the same override shapedeployNetworks()already has, so the declaration stays the single place a repo says where it deploys.The
[etherscan]half needs its own answer regardless, since a network with no Etherscan deployment is a fact about the network rather than about any consumer — perhaps membership against the networks that have one, rather than against every target.🤖 Generated with Claude Code