bug: verification in forge create with custom explorer when passing --verifier etherscan with --etherscan-api-key doesn't work

[antoinedc]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (a428ba6 2024-10-29T00:21:52.576754000Z)

What command(s) is the bug in?

forge create

Operating System

macOS (Apple Silicon)

Describe the bug

When running:

forge create \
  --rpc-url http://localhost:8545 \
  --private-key 0x1234 \
  contracts/UniswapV2Factory.sol:UniswapV2Factory \
  --constructor-args 0xF4E864F40476ac400a5AD55f8eA06c6CCd08597d --legacy \
  --verify \
  --verifier etherscan \
  --verifier-url http://localhost:8888/api \
  --etherscan-api-key anvil-23

I get this ouput:

[⠊] Compiling...
[⠆] Compiling 11 files with Solc 0.5.16
[⠰] Solc 0.5.16 finished in 250.35ms
Compiler run successful!
Error: ETHERSCAN_API_KEY must be set

Setting ETHERSCAN_API_KEY env variable does the same
http://localhost:8888/api is an Etherscan compatible API (https://tryethernal.com)

forge verify-contract works as expected though

[grandizzy]

@antoinedc pls check book on how to add unknown chains in config https://book.getfoundry.sh/reference/config/etherscan#etherscan so smth like this should work

[rpc_endpoints]
anvil = "http://127.0.0.1:8545"

[etherscan]
anvil = { key = "anvil-23", url = "http://localhost:8888/api", chain = "anvil"}

forge create \
  --rpc-url anvil \
  --private-key 0x2a871d... \
  src/Counter.sol:Counter \
  --verify

Deployer: 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720
Deployed to: 0x700b6A60ce7EaaEA56F065753d8dcB9653dbAD35
Transaction hash: 0xa0c56fe7347058f526206c4dbb7ba92ce70306fdf80bc23bcaf7a86d06a3f149
Starting contract verification...
Waiting for etherscan to detect contract deployment...
Start verifying contract `0x700b6A60ce7EaaEA56F065753d8dcB9653dbAD35` deployed on anvil-hardhat

going to close for now, please reopen if still issues. thank you!

[antoinedc]

Thanks @grandizzy for the reply. I had actually seen that page before, but I'm looking at being able to do the verification without having to create or edit an extra file, directly in the forge create command.

Are there any technical reasons why this can't be supported?

This really does make a difference on my end. Contract verification is obviously very important for any explorer, and so is compatibility with user tooling/workflow. Not being able to be a drop-in replacement to Blockscout or Etherscan hurts adoption. And "gatekeeping" this feature to those two explorers seems a bit too opinionated.

As an example, Hardhat verification system works perfectly with any endpoint (based on Etherscan API-), and users can switch explorers by just changing a value, without having to change anything in their workflow.

[grandizzy]

I see, IMO is easier and cleaner to put an alias in a config file (that could be easily reused in other projects) opposed to change command but I can understand your point.

As an example, Hardhat verification system works perfectly with any endpoint (based on Etherscan API-), and users can switch explorers by just changing a value, without having to change anything in their workflow.

This is valid in the config I put above too, just specify desired URL

anvil = { key = "anvil-23", url = "http://localhost:8888/api", chain = "anvil"}

@zerosnacks @yash-atreya could you please share your thoughts? thanks!

[zerosnacks]

Hi @antoinedc

I think this issue arises because you are passing the verifier as etherscan forcing a check for ETHERSCAN_API_KEY

In lieu of a more generalized solution I would be open to accept a PR that adds your custom explorer Ethereal as an EtherscanVerificationProvider to here:

foundry/crates/verify/src/provider.rs

Lines 152 to 176 in a428ba6

	#[derive(Clone, Debug, Default, PartialEq, Eq, clap::ValueEnum)]
	pub enum VerificationProviderType {
	#[default]
	Etherscan,
	Sourcify,
	Blockscout,
	Oklink,
	}
	impl VerificationProviderType {
	/// Returns the corresponding `VerificationProvider` for the key
	pub fn client(&self, key: &Option<String>) -> Result<Box<dyn VerificationProvider>> {
	match self {
	Self::Etherscan => {
	if key.as_ref().map_or(true, |key| key.is_empty()) {
	eyre::bail!("ETHERSCAN_API_KEY must be set")
	}
	Ok(Box::<EtherscanVerificationProvider>::default())
	}
	Self::Sourcify => Ok(Box::<SourcifyVerificationProvider>::default()),
	Self::Blockscout => Ok(Box::<EtherscanVerificationProvider>::default()),
	Self::Oklink => Ok(Box::<EtherscanVerificationProvider>::default()),
	}
	}
	}

[antoinedc]

Hi @zerosnacks,

Shouldn't this check pass if I provide the key? My assumption was that the command would work as long as the verifier-url is an Etherscan compatible endpoint & that an api key is passed.

Thanks for the code snippet, I will take a look at that (have never done any Rust so not sure how it'll go ahah)

[zerosnacks]

Hi @antoinedc, unfortunately this is due to the incorrect use of the --verifier etherscan. When this is passed a number of assumptions are made in regards to the resolving of the Etherscan configuration using alloy-chains. Due to anvil-hardhat not having a valid Etherscan API URL we fail to resolve this api_url.

cc @grandizzy, this incorrectly casts to None on failure of etherscan_urls()?; resulting in the ETHERSCAN_API_KEY must be set error

foundry/crates/config/src/lib.rs

Line 1296 in 48930a6

return Ok(ResolvedEtherscanConfig::create(key, chain));

foundry/crates/config/src/etherscan.rs

Line 263 in 48930a6

let (api_url, browser_url) = chain.etherscan_urls()?;

I think the simplest solution here is to ask alternative explorers to add themselves to the VerificationProviderType and declare that they are compatible with an API rather than us inferring it. It is explicit and standardized.

We should also disallow the --etherscan-api-key flag to be passed if a verifier other than --verifier etherscan is set.

Re-opening as there are some action items

[antoinedc]

When this is passed a number of assumptions are made in regards to the resolving of the Etherscan configuration using alloy-chains. Due to anvil-hardhat not having a valid Etherscan API URL we fail to resolve this api_url.

Aah got it, I see. Thanks for the explanation! From what I've seen in other verifiers, the "method" (ie etherscan, sourcify, etc...), is more about knowing what api format to expect (and then allowing any endpoint) rather than something that will "force" the usage of a specific platform.