feat: resolve evm_version per chain and detect PUSH0 support automatically - #21
Merged
Conversation
|
👋 aelmanaa, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
…cally Target shanghai by default and pin an older EVM only where a chain needs it, instead of holding the whole repo back to paris. The setting does double duty in Foundry: it is the compile target AND the version of the local EVM that forge scripts execute in. Pinned to paris, a script cannot run any contract built with a current toolchain, so operations against an operator-supplied token fail before a transaction is signed, and the failure is easy to misread as a fault in that token. Reading decimals() off a healthy BYO token is the costly case, because the value that gets substituted when the read fails decides the deployed pool's decimals. A few chains have not activated PUSH0, and bytecode compiled for shanghai is undeployable there, so the pin cannot simply be raised. config/chains/<name>.json gains an optional evmVersion key and every chain-scoped target forwards it as --evm-version. add-chain probes the chain and records the pin only when the chain rejects PUSH0, so the value is measured rather than maintained by hand; detect-evm-version re-checks a chain already in the repo. The probe is eth_call with initcode, needing no funds or keys. The probe refuses rather than guesses, because a pin it writes is permanent and valid enough to pass review. It records one only when the node reports an invalid opcode: a timeout or a rate limit is not a rejection, and pinning on absence of success would return a chain to the compile target this mechanism exists to move it off. It asserts eth_chainId before trusting an endpoint, since public RPC directories carry chainId collisions, and it refuses when it cannot identify the endpoint at all. Missing tools and unparseable config are separated from "this chain needs nothing", so neither can exit as a silent success. The resolver reads its default from forge config so it cannot drift from foundry.toml, and validates a declared value: broadcasting targets abort on an unrecognised one or an unreadable config, while read-only paths fall back and report it, so a typo can never quietly deploy bytecode built for the wrong EVM. ignored_error_codes now lists code-size and init-code-size explicitly alongside too-many-warnings, because setting the key replaces Foundry's defaults rather than extending them, and shanghai adds enough EIP-3860 warnings to cross solc's 256-warning cap. Chains that support PUSH0 need no key and their configs are untouched. Contracts deployed after this change carry PUSH0, so their bytecode differs from before.
aelmanaa
force-pushed
the
feat/change-evm-version
branch
from
July 31, 2026 12:00
ceac88c to
a31c3da
Compare
SyedAsadKazmi
approved these changes
Jul 31, 2026
SyedAsadKazmi
approved these changes
Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces per-chain EVM version support to the deployment and configuration workflow, ensuring that all
forge scriptinvocations use the correct EVM version for each chain. This is especially important for chains that do not support newer opcodes (such asPUSH0). The implementation adds a mechanism to detect, declare, and forward the appropriate--evm-versionflag for each chain, defaulting to the repository-wide setting when not specified. It also updates documentation to reflect these changes and clarifies the new configuration schema.Makefile and Deployment Workflow Enhancements:
evm-versionandevm-version-flagmacros to theMakefilefor per-chain EVM version resolution, using a new shell script to detect the required version and forwarding it to all relevantforge scriptinvocations.Makefileto forward the correct--evm-versionflag, ensuring compatibility with each chain’s requirements. [1] [2] [3] [4] [5] [6] [7] [8]Documentation and Schema Updates:
README.md,docs/config-architecture.md, anddocs/config-schema.mdto document the new per-chainevmVersionfield, its purpose, and how it is set or detected. This includes schema tables, field descriptions, and example config files. [1] [2] [3] [4] [5] [6]These changes make the deployment process more robust and future-proof by ensuring that bytecode is always compiled and simulated with the correct EVM version for each target chain.