Repository navigation
The [etherscan] config assertion needs the networks that have an Etherscan deployment, not the deploy roster #259
Description
Activity
Closing — the premise is wrong.
This issue assumed a network Etherscan does not index should have no
[etherscan]entry, and that the assertion demanding one is therefore wrong.
rain.deploy's ownfoundry.tomlonmainalready answers it the other way:robinhood = { key = "${CI_DEPLOY_ROBINHOOD_ETHERSCAN_API_KEY}", chain = 4663, url = "https://robinhoodchain.blockscout.com/api" }
Robinhood's Blockscout explorer speaks the Etherscan API, so the entry points
there and the key is whatever the variable carries — Blockscout ignores it. The
comment above it records the fallback: if--verifyfails on that network,
verify afterwards through Sourcify.#237 keeps that shape rather than modelling absence. Its
SupportedNetwork
carriesexplorerUrl, documented as "the explorer API--verifyposts to, or
empty for the one Etherscan V2 resolves fromchainId", so every network gets
an entry and a chain Etherscan does not index gets its explorer URL instead of
nothing.So there is no second set to introduce and the assertion is not wrong. The
outlier isst0x.deploy, which omits the entry on the grounds that one "would
only make foundry demand an API key it cannot use" — which the entry above
disproves. That is a fix in st0x's config, not here.#246 remains open for the roster hook, which is the real half.
- added a commit that references this issue
on Oct 5, 2026
Split out of #246, which is the roster hook. This is the other half and does not
follow from it.
The gap
RainDeployVerifySnapshot.testSupportedNetworksAreFullyConfiguredrequires an[etherscan]entry for every network in the set it checks. #246 makes that setthe consumer's own roster rather than the org's nine, which is right for
[rpc_endpoints]and does not help here.A network with no Etherscan deployment is a fact about the NETWORK, not about
any consumer.
st0x.deploydeliberately has no[etherscan]entry forRobinhood: chain 4663 is not indexed by Etherscan's v2 API, its own comment
records that an entry "would only make foundry demand an API key it cannot use",
and it verifies with
--verifier sourcify. So even scoped to st0x's own fivenetworks, the assertion fails on a config that is correct.
Shape of a fix
The
[etherscan]requirement wants its own set — the networks that HAVE anEtherscan deployment — rather than a scoping of the deploy roster. That set is a
property of the networks, so it belongs beside
supportedNetworks()inLibRainDeployrather than being overridable per consumer.Interaction with #237
Open PR #237 (
fix-233) generates[rpc_endpoints]and[etherscan]fromLibRainDeploy.supportedNetworkConfigs()and DELETES bothtestSupportedNetworksAreFullyConfiguredandcheckNetworksConfigured. If thatlands, this assertion goes with it and this issue is moot — the generator then
has to know which networks carry an Etherscan entry, which is the same fact
stated once in the roster instead of asserted against it.
So the answer here may be "wait for #237" rather than a separate mechanism. #237
is out of scope for the Protofire round and ordered after it, which is why this
is filed rather than folded into that PR.