Skip to content

Skip undeterministic deployment verification - #807

Open
hiletmis wants to merge 4 commits into
mainfrom
fix-issue-806
Open

Skip undeterministic deployment verification#807
hiletmis wants to merge 4 commits into
mainfrom
fix-issue-806

Conversation

@hiletmis

Copy link
Copy Markdown
Contributor

Closes #461

Problem

verify-deployments fails on both Filecoin chains:

Error: filecoin GnosisSafeWithoutProxy creation tx could not be fetched
Error: filecoin-testnet GnosisSafeWithoutProxy creation tx could not be fetched

All contracts on these two chains are deployed undeterministically, so they are verified
through their creation transactions. Filecoin's Ethereum JSON-RPC implementation only
indexes recent messages, which means eth_getTransactionByHash returns null for the
deployment transactions and verification cannot proceed.

This is a property of the chains' RPC retention rather than a problem with the
deployments themselves.

Solution

Add skippedChainAliasesInUndeterministicDeploymentVerification to scripts/constants.ts,
following the existing skip-list convention in that file. For the listed chains,
verify-deployments confirms that contract code exists at the deployment address instead
of fetching and comparing the creation transaction.

@hiletmis hiletmis mentioned this pull request Jul 28, 2026
@hiletmis
hiletmis marked this pull request as ready for review July 28, 2026 08:15

@bdrhn9 bdrhn9 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this PR addresses issue #461. Issue #461 asks for the opposite: maintaining an allowlist of chains that were deployed non-deterministically. This is because non-deterministic deployments are normally validated using this else condition, and CI passes. For example, ronin, mantle-sepolia-testnet, and taiko have non-deterministic deployments for the OwnableCallForwarder, AccessControlRegistry, and Api3ServerV1 contracts.

For this PR, it's probably better to keep the behavior as-is but have it only say "Skip verify-deployments on Filecoin, whose RPC does not index historical transactions". We should then create a follow-up PR, maybe with a function written specifically for this chain, to verify the contract code, probably by calling eth_getCode and checking the immutable parts of the code. Otherwise, skipping verification completely isn't acceptable, imo.

Comment thread scripts/verify-deployments.ts Outdated
Comment on lines +171 to +186
}
if (goFetchContractCode.data === '0x') {
throw new Error(`${network} ${contractName} (undeterministic) contract code does not exist`);
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The else if body is identical to the if body, except the two error strings use undeterministic instead of deterministic. I'd suggest the following implementation to reduce duplication:

const deployedDeterministically = deployment.address === expectedDeterministicDeploymentAddress;
if (deployedDeterministically || skippedChainAliasesInUndeterministicDeploymentVerification.includes(network)) {
  const deploymentType = deployedDeterministically ? 'deterministic' : 'undeterministic';
  const goFetchContractCode = await go(async () => provider.getCode(deployment.address), goAsyncOptions);
  if (!goFetchContractCode.success || !goFetchContractCode.data) {
    throw new Error(`${network} ${contractName} (${deploymentType}) contract code could not be fetched`);
  }
  if (goFetchContractCode.data === '0x') {
    throw new Error(`${network} ${contractName} (${deploymentType}) contract code does not exist`);
  }
} else {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Only allow contracts to be deployed non-deterministically for chains with exclusive permission

2 participants