Will I be able to find bugs using AI? #1199
Description
Pull Request
https://github.com/ethereum/ercs/blob/master/ERCS/erc-4337.md
What happened?
If I send the code to the AI, will it find errors that a normal user won't? I basically did that, it found some bugs, but I'm not sure if they can be approved.
Relevant log output
Brief verdict: the link points not to “code,” but to the ERC‑4337 specification in Markdown. I compared it against the current version of the spec and related docs. Below are concrete gaps and potential errors/outdated areas worth fixing to keep the document accurate and aligned with the current ecosystem.
What I found
1. Outdated wording about replay protection
* The section on signatures says the signature “should depend on chainid and EntryPoint.” In the current specification this requirement is MUST; otherwise cross‑chain/cross‑EntryPoint replays are possible. I suggest replacing should → MUST. Source: the current EIP‑4337 page. (eips.ethereum.org)
1. References to 3074 instead of 7702
* In “Motivation/Support other use cases” and elsewhere there are still mentions of EIP‑3074. Today it’s more relevant to reference EIP‑7702 and the already documented 4337↔7702 compatibility path. The published web version of ERC‑4337 already has explicit 7702 support (including “factory = 0x7702” as a flag), so the GitHub version should be synchronized. Sources: the published ERC‑4337, EIP‑7702. (ercs.ethereum.org, eips.ethereum.org)
1. Ambiguity around the UserOperation format (unpacked vs. packed)
* In one place the table describes an “unpacked” UserOperation (factory/factoryData), while lower down, in the simulation and account‑creation description, “initCode” is used—that’s the “packed” format (PackedUserOperation: initCode = factory || data). This is conceptually correct, but the document lacks an explicit note that these are two representations of the same object and where each is used. You can link directly to the PackedUserOperation section from the EIPs roundup. (eips.exposed)
1. Simulation: “EntryPoint does not implement simulate…” — outdated
* The text claims EntryPoint does not contain simulation methods and that you must use “EntryPointSimulations.” In current releases EntryPoint includes simulateValidation (and others) via the IEntryPointSimulations interface; they are invoked off‑chain. This is important, otherwise readers get the wrong picture of bundler integration. Sources: AA docs on EntryPoint, DeepWiki on IEntryPointSimulations. (docs.erc4337.io, deepwiki.com)
1. Missing EIP‑7702 integration in the UserOperation structure
* In the current EIP‑4337 text, “factory” can be used as the 0x7702 flag (an EOA with 7702 authorization), and factoryData is used to initialize 7702. If your version lacks this, add it (and sync with the web ERC‑4337). Sources: current EIP‑4337 and the web ERC‑4337. (eips.ethereum.org, ercs.ethereum.org)
1. Normative guidance on bundlers and PBS
* Several formulations around bundlers and inclusion via Flashbots have been expanded: it’s now recommended to explicitly mention PBS/MEV‑Boost and EIP‑7732. The web version already reflects this—port it to the GitHub text. (ercs.ethereum.org)
1. The “0x7702” sentinel address is non‑obvious
* The phrase “factory = 0x7702” can be ambiguous: this should be a full 20‑byte address in the 0x000…7702 style used as a sentinel, not a “short” string. The published version explains this conceptually; in the GitHub version, explicitly specify the format to avoid misinterpretation. Source: published ERC‑4337 (see the paragraph “If the factory address is 0x7702…”). (ercs.ethereum.org)
1. Penalty for unused execution gas
* The spec introduces a 10% penalty on unused callGasLimit/paymasterPostOpGasLimit to discourage over‑padding bundles with gas. Some summaries and implementations document this already. Ensure the text correctly describes exactly when the penalty applies (including the case of an empty paymaster context—historically there were doc/implementation inconsistencies). Source: OpenZeppelin’s incremental audit with the penalty details. (blog.openzeppelin.com)
1. Requirement to not revert on bad signatures
* Validation must return SIG_VALIDATION_FAILED (and not revert) on an invalid signature. Emphasize this as MUST/SHOULD NOT revert—audits have found deviations. Add explicit language. Source: OpenZeppelin’s 4337 audit. (blog.openzeppelin.com)
1. Tie the “Simulation/Validation rules” section to ERC‑7562
* Rules for simulation and opcode/state‑access constraints are now standardized in ERC‑7562. The text hints at reputation/bans, but it’s best to link directly and summarize the requirements to avoid interpretational drift across integrators. Source: ERC‑7562 (AA docs). (docs.erc4337.io)
1. Divergences between the ERCs website and GitHub and some broken links
* The repo has had issues about broken relative links and mismatches between “erc‑XX.md”/“eip‑XX.md.” Check internal links inside the file—historically they could 404 from the GitHub UI. Source: discussion in repo issues. (github.com)
1. Releases and EntryPoint addresses
* The text mentions a “pre‑published global EntryPoint.” In practice, multiple EntryPoint versions coexist (v0.6/0.7/0.8) with different addresses; bundlers use whitelisting to select supported ones. I recommend stating versioning explicitly and not hard‑coding a single address in the spec. Sources: AA docs with addresses and the reference implementation repo. (docs.erc4337.io, github.com)
Proposed edits (short and to the point)
* Signature: change “should depend” to “MUST depend” for chainId+EntryPoint.
* Add an explicit subsection on EIP‑7702 compatibility: using “factory = 0x000…7702” and the corresponding signature/authorization handling.
* Clarify that the document uses two representations of UserOperation: “unpacked” (factory/factoryData) and “packed” (initCode, accountGasLimits, gasFees, etc.), with a link to the relevant section.
* Update the simulation section: note that simulateValidation/Simulations API exists on EntryPoint itself and is called off‑chain via eth_call/debug_traceCall.
* Explicitly tie simulation/reputation rules to ERC‑7562.
* Re‑check the examples of the 10% penalty and describe precisely what is penalized and under which conditions.
* Replace remaining EIP‑3074 mentions with EIP‑7702 where the topic is batching/sponsorship/compatibility.
* Sweep internal relative links in the file and fix targets to live pages.
Useful references for cross‑checking
* Canonical EIP‑4337 page and its current UserOperation structure (including 7702): (eips.ethereum.org)
* ERC‑4337 on the ERCs site (with 7702 integration and “latest” semantics): (ercs.ethereum.org)
* EntryPoint and simulation docs: (docs.erc4337.io)
* ERC‑7562 (simulation/reputation rules): (docs.erc4337.io)
* Reference implementation and release notes (to verify 10% penalty behavior and APIs): (github.com/eth-infinitism/account-abstraction)
* OpenZeppelin audit (practical notes and corrections): (blog.openzeppelin.com)
If you like, I can draft targeted wording diffs in English for this file—say the word, and I’ll prepare minimal phrase/paragraph replacements ready for a PR.