[Solidity] Upgrade @openzeppelin/contracts to 5.5.0-rc.0 #681
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughDependency updates to OpenZeppelin Contracts 5.5.0-rc.0 and Hardhat; renaming signer option from ERC7702 to EIP7702 across core, tests, and UI; snapshot and import-path updates for OZ 5.5.0-rc.0; configuration tweaks for upgradeable handling and compatible version constant. Changes
Sequence Diagram(s)(omitted) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🧪 Early access (Sonnet 4.5): enabledWe are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience. Note:
Comment |
|
Caution Review the following alerts detected in dependencies. According to your organization's Security Policy, you must resolve all "Block" alerts before proceeding. Learn more about Socket for GitHub.
|
| "@nomicfoundation/hardhat-toolbox": "^6.1.0", | ||
| "hardhat": "^2.16.1" | ||
| "@openzeppelin/contracts": "^5.5.0-rc.0", | ||
| "hardhat": "^2.22.0" |
There was a problem hiding this comment.
5.5.0-rc.0 requires Cancun support for mcopy. This is supported by hardhat since 2.22.0.
| "@openzeppelin/contracts": "^5.5.0-rc.0", | ||
| "@openzeppelin/contracts-upgradeable": "^5.5.0-rc.0", | ||
| "@openzeppelin/hardhat-upgrades": "^3.0.0", | ||
| "hardhat": "^2.22.0" |
There was a problem hiding this comment.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (4)
packages/core/solidity/src/zip-hardhat.test.ts.md (2)
58-61: Consider pinning RC versions for deterministic snapshots.Using caret with pre-releases can drift to newer rc tags and cause snapshot churn. For the zipped sample, pin "@openzeppelin/contracts(-upgradeable)" to "5.5.0-rc.0" to avoid flakiness, unless you intentionally want auto-drift.
Please confirm your desired policy for RC ranges in sample package.json files (pin vs caret).
Also applies to: 131-134, 206-211
169-176: Use upgradeable-variant imports for Initializable and UUPSUpgradeable
Both contracts are exposed in v5.5.0-rc.0 under@openzeppelin/contractsand@openzeppelin/contracts-upgradeable; upgradeable templates should import them from@openzeppelin/contracts-upgradeable/proxy/utils/{Initializable,UUPSUpgradeable}.solto include initializer modifiers and storage gaps.packages/ui/src/solidity/AccountControls.svelte (1)
28-35: Auto-clear upgradeability when selecting EIP7702 to keep state coherent.UI disables the section but keeps any previously selected upgradeability in opts. To avoid invalid state leaking into generation, clear it when EIP7702 is chosen.
$: { - if (opts.signer === 'EIP7702') { + if (opts.signer === 'EIP7702') { + // Ensure incompatible state is cleared + opts.upgradeable = false; upgradeNotSupported = true; upgradeNotSupportedReason = 'EOAs can upgrade by redelegating to a new account'; } else { upgradeNotSupported = false; upgradeNotSupportedReason = ''; } }packages/core/solidity/src/erc721.test.ts.md (1)
560-565: Use upgradeable package imports for both Initializable and UUPSUpgradeable
Both contracts exist in “@openzeppelin/contracts” and “@openzeppelin/contracts-upgradeable” in v5.5.0-rc.0; for upgradeable implementations import from@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.soland@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.solfor consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (13)
packages/core/solidity/src/account.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/contract.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/custom.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/environments/hardhat/package-lock.jsonis excluded by!**/package-lock.jsonpackages/core/solidity/src/environments/hardhat/upgradeable/package-lock.jsonis excluded by!**/package-lock.jsonpackages/core/solidity/src/erc1155.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/erc20.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/erc721.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/governor.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/stablecoin.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/zip-foundry.test.ts.snapis excluded by!**/*.snappackages/core/solidity/src/zip-hardhat.test.ts.snapis excluded by!**/*.snapyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (19)
packages/core/solidity/package.json(2 hunks)packages/core/solidity/src/account.test.ts(1 hunks)packages/core/solidity/src/contract.test.ts.md(19 hunks)packages/core/solidity/src/custom.test.ts.md(10 hunks)packages/core/solidity/src/environments/hardhat/package.json(1 hunks)packages/core/solidity/src/environments/hardhat/upgradeable/package.json(1 hunks)packages/core/solidity/src/erc1155.test.ts.md(14 hunks)packages/core/solidity/src/erc20.test.ts.md(43 hunks)packages/core/solidity/src/erc721.test.ts.md(23 hunks)packages/core/solidity/src/generate/account.ts(1 hunks)packages/core/solidity/src/get-imports.test.ts(2 hunks)packages/core/solidity/src/governor.test.ts.md(20 hunks)packages/core/solidity/src/set-upgradeable.ts(2 hunks)packages/core/solidity/src/signer.ts(4 hunks)packages/core/solidity/src/stablecoin.test.ts.md(20 hunks)packages/core/solidity/src/utils/version.ts(1 hunks)packages/core/solidity/src/zip-foundry.test.ts.md(21 hunks)packages/core/solidity/src/zip-hardhat.test.ts.md(6 hunks)packages/ui/src/solidity/AccountControls.svelte(2 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: .changeset/sour-hats-grow.md:2-6
Timestamp: 2025-08-15T22:49:25.653Z
Learning: In OpenZeppelin contracts-wizard, breaking changes that have concrete migration paths (like dependency migrations from Community Contracts to OpenZeppelin Contracts) can be handled as minor version bumps instead of major bumps, per maintainer ernestognw's versioning policy.
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/signer.ts:45-49
Timestamp: 2025-08-19T01:15:58.945Z
Learning: The OpenZeppelin contracts-upgradeable package includes upgradeable versions of signer contracts like SignerECDSAUpgradeable, SignerP256Upgradeable, SignerRSAUpgradeable, MultiSignerERC7913Upgradeable, and MultiSignerERC7913WeightedUpgradeable in the contracts/utils/cryptography/signers directory.
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/signer.ts:45-49
Timestamp: 2025-08-19T01:15:58.945Z
Learning: All OpenZeppelin signer contracts have upgradeable variants available in the contracts-upgradeable package: SignerECDSAUpgradeable, SignerP256Upgradeable, SignerRSAUpgradeable, MultiSignerERC7913Upgradeable, and MultiSignerERC7913WeightedUpgradeable all exist in contracts/utils/cryptography/signers/ directory.
📚 Learning: 2025-08-15T23:23:13.097Z
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/signer.ts:31-38
Timestamp: 2025-08-15T23:23:13.097Z
Learning: In OpenZeppelin contracts-wizard, the `setUpgradeableAccount` function deliberately sets `c.upgradeable = false` after upgradeable setup to exclude EIP712Upgradeable and ERC7739Upgradeable variants (avoiding per-call SLOAD overhead). This architectural pattern necessitates manual `_disableInitializers()` setup in both account.ts and signer.ts since the standard upgradeable constructor logic doesn't apply when upgradeability is disabled post-setup.
Applied to files:
packages/core/solidity/src/generate/account.tspackages/ui/src/solidity/AccountControls.sveltepackages/core/solidity/src/signer.tspackages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/set-upgradeable.tspackages/core/solidity/src/zip-hardhat.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/governor.test.ts.mdpackages/core/solidity/src/erc1155.test.ts.mdpackages/core/solidity/src/account.test.tspackages/core/solidity/src/erc20.test.ts.mdpackages/core/solidity/src/custom.test.ts.md
📚 Learning: 2025-08-19T01:15:58.945Z
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/signer.ts:45-49
Timestamp: 2025-08-19T01:15:58.945Z
Learning: All OpenZeppelin signer contracts have upgradeable variants available in the contracts-upgradeable package: SignerECDSAUpgradeable, SignerP256Upgradeable, SignerRSAUpgradeable, MultiSignerERC7913Upgradeable, and MultiSignerERC7913WeightedUpgradeable all exist in contracts/utils/cryptography/signers/ directory.
Applied to files:
packages/ui/src/solidity/AccountControls.sveltepackages/core/solidity/src/signer.tspackages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/account.test.tspackages/core/solidity/src/erc20.test.ts.md
📚 Learning: 2025-08-19T01:15:58.945Z
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/signer.ts:45-49
Timestamp: 2025-08-19T01:15:58.945Z
Learning: The OpenZeppelin contracts-upgradeable package includes upgradeable versions of signer contracts like SignerECDSAUpgradeable, SignerP256Upgradeable, SignerRSAUpgradeable, MultiSignerERC7913Upgradeable, and MultiSignerERC7913WeightedUpgradeable in the contracts/utils/cryptography/signers directory.
Applied to files:
packages/ui/src/solidity/AccountControls.sveltepackages/core/solidity/src/signer.tspackages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/account.test.tspackages/core/solidity/src/erc20.test.ts.md
📚 Learning: 2025-08-15T22:49:25.653Z
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: .changeset/sour-hats-grow.md:2-6
Timestamp: 2025-08-15T22:49:25.653Z
Learning: In OpenZeppelin contracts-wizard, breaking changes that have concrete migration paths (like dependency migrations from Community Contracts to OpenZeppelin Contracts) can be handled as minor version bumps instead of major bumps, per maintainer ernestognw's versioning policy.
Applied to files:
packages/core/solidity/src/environments/hardhat/upgradeable/package.jsonpackages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/zip-hardhat.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/custom.test.ts.md
📚 Learning: 2025-08-20T20:23:30.259Z
Learnt from: ericglau
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/set-upgradeable.ts:0-0
Timestamp: 2025-08-20T20:23:30.259Z
Learning: In OpenZeppelin contracts-wizard, upgradeable contracts use two different strategies for Initializable imports: Account contracts directly import from contracts-upgradeable/proxy/utils/Initializable.sol for explicit clarity, while other upgradeable contracts (ERC20, ERC721, Governor, etc.) use helpers to automatically transpile imports to upgradeable versions. This architectural separation is intentional due to the special ERC-4337 requirements of account contracts.
Applied to files:
packages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/set-upgradeable.tspackages/core/solidity/src/zip-hardhat.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/get-imports.test.tspackages/core/solidity/src/governor.test.ts.mdpackages/core/solidity/src/erc1155.test.ts.mdpackages/core/solidity/src/erc20.test.ts.mdpackages/core/solidity/src/custom.test.ts.md
📚 Learning: 2025-08-21T19:44:06.797Z
Learnt from: ericglau
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/account.ts:191-204
Timestamp: 2025-08-21T19:44:06.797Z
Learning: Initializable is available in both openzeppelin/contracts and openzeppelin/contracts-upgradeable packages, so conditional imports like `openzeppelin/${opts.upgradeable ? 'contracts-upgradeable' : 'contracts'}/proxy/utils/Initializable.sol` are valid and will resolve correctly.
Applied to files:
packages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/set-upgradeable.tspackages/core/solidity/src/zip-hardhat.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/get-imports.test.tspackages/core/solidity/src/governor.test.ts.mdpackages/core/solidity/src/erc20.test.ts.mdpackages/core/solidity/src/custom.test.ts.md
📚 Learning: 2025-08-15T22:52:34.129Z
Learnt from: ernestognw
PR: OpenZeppelin/contracts-wizard#609
File: packages/core/solidity/src/account.ts:89-0
Timestamp: 2025-08-15T22:52:34.129Z
Learning: In OpenZeppelin contracts-wizard, non-upgradeable accounts still require initializer logic (Initializable, _disableInitializers(), and initialize() function) because ERC-4337 accounts are typically deployed by factories as minimal clone proxies, which cannot use constructors effectively for initialization. This is the intended deployment pattern for ERC-4337 account abstraction, even for non-upgradeable accounts.
Applied to files:
packages/core/solidity/src/erc721.test.ts.mdpackages/core/solidity/src/set-upgradeable.tspackages/core/solidity/src/zip-hardhat.test.ts.mdpackages/core/solidity/src/zip-foundry.test.ts.mdpackages/core/solidity/src/governor.test.ts.mdpackages/core/solidity/src/erc1155.test.ts.mdpackages/core/solidity/src/erc20.test.ts.mdpackages/core/solidity/src/custom.test.ts.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: boostsecurity - boostsecurityio/semgrep-pro
- GitHub Check: mcp
- GitHub Check: semgrep-cloud-platform/scan
🔇 Additional comments (26)
packages/core/solidity/src/contract.test.ts.md (1)
11-13: Snapshots updated to OZ ^5.5.0-rc.0 — LGTMHeader bump is consistent with the version constant and dependency updates.
Also applies to: 23-25, 35-37, 49-51, 64-66, 79-81, 95-97, 107-109, 127-129, 151-153, 164-166, 179-181, 194-196, 211-213, 226-228, 242-244, 255-257, 269-271, 281-283
packages/core/solidity/src/utils/version.ts (1)
4-4: Consistent with the RC bumpUpdating
compatibleContractsSemverto^5.5.0-rc.0matches the snapshots and deps. If the plan is to switch to the final 5.5.0 tag on release day, consider tracking a follow-up to drop the-rc.0suffix then.packages/core/solidity/src/stablecoin.test.ts.md (1)
11-13: Stablecoin snapshots align with OZ ^5.5.0-rc.0 and pinned Community Contracts commit — LGTMNo functional diffs beyond headers.
Also applies to: 27-29, 45-47, 84-86, 127-129, 166-167, 206-207, 227-228, 243-244, 297-298, 314-315, 329-331, 365-366, 411-412, 457-458, 493-494, 529-530, 574-575, 591-592
packages/core/solidity/src/get-imports.test.ts (3)
41-41: Bytes.sol added — OKExpected with OZ 5.5 where ERC721Utils depends on Bytes.
81-81: New Bytes and LowLevelCall imports — OKAligns with OZ 5.5 internal refactors (LowLevelCall split).
Also applies to: 83-83
74-75: Ignore non-upgradeable proxy utils imports
get-importsintentionally emits@openzeppelin/contracts/proxy/utils/...paths forInitializable.solandUUPSUpgradeable.solin both modes and relies on the upgradeable‐transformation step inset-upgradeable.tsto swap in the-upgradeablevariants. No changes needed.Likely an incorrect or invalid review comment.
packages/core/solidity/src/erc1155.test.ts.md (3)
12-12: Compatibility banner bumped to ^5.5.0-rc.0 — OKSnapshot headers uniformly updated.
Also applies to: 35-35, 58-58, 95-95, 118-118, 135-135, 159-159, 200-200, 237-237, 290-290, 327-327, 360-360, 444-444, 537-537
367-367: Cannot verify compilation due to npm errors
The Hardhat compile step failed withENOTEMPTYand one environment is missing@openzeppelin/contracts-upgradeable. Ensurepackages/core/solidity/src/environments/hardhat/package.jsonlists both@openzeppelin/contractsand@openzeppelin/contracts-upgradeable, then run:npm ci --force npx hardhat compileIf it still fails, please share that
package.jsonand yourhardhat.config.tsfor further troubleshooting.
374-374: Confirm plugin supports –reachable variant — Verify that your @openzeppelin/hardhat-upgrades version (in your project’s package.json) supports theoz-upgrades-unsafe-allow-reachableconstructor annotation. Applies also at lines 460 and 549.packages/core/solidity/src/governor.test.ts.md (1)
12-12: Compatibility banner bumped to ^5.5.0-rc.0 — OKConsistent across governor snapshots.
Also applies to: 102-102, 189-189, 281-281, 373-373, 462-462, 557-557, 909-909, 995-995, 1085-1085, 1171-1171, 1257-1257, 1346-1346, 1432-1432, 1521-1521, 1607-1607
packages/core/solidity/src/environments/hardhat/package.json (1)
13-14: Approve Hardhat and OpenZeppelin version bumps. Versions^5.5.0-rc.0and^2.22.0match those used in the upgradeable environment.packages/core/solidity/src/environments/hardhat/upgradeable/package.json (1)
13-16: Dependencies validated
No^5.4.xreferences remain, and@openzeppelin/hardhat-upgrades@3.0.0’s peer dependency on Hardhat^2.0.2is satisfied by Hardhat^2.22.0.packages/core/solidity/src/generate/account.ts (1)
11-11: Signer list update LGTM.EIP7702 added and ordering aligns with the test matrix. No further action.
packages/core/solidity/src/erc20.test.ts.md (4)
12-12: Version header update looks goodHeader correctly targets OZ ^5.5.0-rc.0; same change elsewhere in this file is fine.
863-863: Initializable import and reachable-constructor tag
- Importing Initializable from @openzeppelin/contracts is valid in v5.x.
- The “@Custom:oz-upgrades-unsafe-allow-reachable constructor” tag is the right form for reachable constructors; please confirm Foundry Upgrades recognizes it in your pipeline. (Based on learnings)
Also applies to: 869-869
900-900: Same notes for superchain upgradeable variantNon-upgradeable Initializable import and the reachable-constructor tag look correct; verify plugin compatibility passes.
Also applies to: 906-906
1035-1038: UUPS import source changeImporting UUPSUpgradeable from @openzeppelin/contracts/proxy/utils is acceptable in v5.x; no issue spotted.
Also applies to: 1046-1049
packages/core/solidity/src/signer.ts (1)
6-6: Rename to EIP7702: check downstream referencesThe option rename (string literal), switch-case label, and OptionsError key (‘eip7702’) look consistent here. Please verify any UI, schema, or error-handling code that consumed ‘ERC7702’/‘erc7702’ has been updated accordingly.
Also applies to: 16-22, 67-67
packages/core/solidity/src/zip-foundry.test.ts.md (8)
40-41: Foundry install linePinning to @vX.Y.Z-rc.0 is aligned with the PR scope; ensure this token resolves to v5.5.0-rc.0 in tests.
333-347: Upgradeable example imports and reachable-constructor tag
- Using Initializable/UUPSUpgradeable from @openzeppelin/contracts is valid in v5.x.
- Reachable-constructor tag looks correct; confirm validations pass under openzeppelin-foundry-upgrades.
Also applies to: 352-352
479-480: contracts-upgradeable install pinMake sure contracts and contracts-upgradeable are pinned to the same rc to keep submodule versions aligned with remappings (as per Foundry upgrades docs). (docs.openzeppelin.com)
574-587: UUPS minimal example header and tagHeader bump and reachable-constructor tag look good.
761-771: ERC721 UUPS exampleInitializable/UUPS imports from base package + reachable-constructor tag are fine in v5.x.
846-847: ERC1155 basic install lineOK to pin contracts to rc here; same note about ensuring token resolves to 5.5.0-rc.0.
1092-1101: ERC1155 transparent exampleHeader and reachable-constructor tag LGTM.
1175-1175: Compatibility headerHeader updated to ^5.5.0-rc.0; looks good here and throughout.
| for (const signer of [false, 'ECDSA', 'EIP7702', 'P256', 'RSA', 'Multisig', 'MultisigWeighted'] as const) { | ||
| for (const upgradeable of [false, 'uups', 'transparent'] as const) { | ||
| if (signer === 'ERC7702' && !!upgradeable) continue; | ||
| if (signer === 'EIP7702' && !!upgradeable) continue; | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
EIP7702 rename + skip logic look correct; please confirm no stale ERC7702 references remain.
Matrix uses 'EIP7702' and correctly skips upgradeable combos. Run a quick sweep to catch any lingering keys, error paths, or UI bindings still using ERC7702/erc7702.
🏁 Script executed:
#!/bin/bash
# Find any leftovers after the rename
rg -nP 'ERC7702|erc7702'Length of output: 2343
Remove all stale ERC7702 references
Several artifacts still use ERC7702 and must be updated to EIP7702 for consistency:
- In packages/ui/api/ai-assistant/function-definitions/solidity.ts, update the enum entry on line 205.
- In packages/mcp/src/solidity/schemas.ts, replace z.literal('ERC7702') on line 126.
- In packages/common/src/ai/descriptions/solidity.ts, adjust the descriptive bullet at line 69.
- In the CHANGELOG.md files under packages/mcp and packages/core/solidity, rename all mentions of SignerERC7702 and related entries.
🤖 Prompt for AI Agents
In packages/core/solidity/src/account.test.ts around lines 64 to 67, update
stale ERC7702 references to EIP7702 and clean up related artifacts: replace any
occurrence of 'ERC7702' with 'EIP7702' in the listed files
(packages/ui/api/ai-assistant/function-definitions/solidity.ts line ~205,
packages/mcp/src/solidity/schemas.ts line ~126,
packages/common/src/ai/descriptions/solidity.ts line ~69) and rename
SignerERC7702 mentions in CHANGELOG.md under packages/mcp and
packages/core/solidity to the new EIP7702 naming; ensure any conditional logic
or enums that previously referenced ERC7702 are updated to use the exact string
'EIP7702' and run tests to confirm no remaining stale references.
| import {TimelockControllerUpgradeable} from "@openzeppelin/contracts-upgradeable/governance/TimelockControllerUpgradeable.sol";␊ | ||
| import {UUPSUpgradeable} from "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";␊ | ||
| import {UUPSUpgradeable} from "@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol";␊ | ||
| ␊ |
There was a problem hiding this comment.
🧩 Analysis chain
Governor (upgradeable) now imports Initializable/UUPS from non‑upgradeable paths
Same pattern as ERC1155. Please verify there’s no duplicate Initializable in the linearization.
Based on learnings
🏁 Script executed:
#!/bin/bash
# Sanity: ensure no mixed Initializable symbols across paths in generated governor sources
rg -nP 'import\s+\{?\s*Initializable\s*\}?\s+from\s+"@openzeppelin/contracts(-upgradeable)?/proxy/utils/Initializable\.sol"' -C1Length of output: 70996
Use upgradeable imports for Initializable and UUPSUpgradeable in Governor (upgradeable)
Lines 1616–1617: replace non-upgradeable paths with upgradeable ones to avoid duplicate Initializable in inheritance
-import {Initializable} from "@openzeppelin/contracts/proxy/utils/Initializable.sol";
-import {UUPSUpgradeable} from "@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol";
+import {Initializable} from "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
+import {UUPSUpgradeable} from "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/core/solidity/src/governor.test.ts.md around lines 1616 to 1617, the
file imports non-upgradeable variants which causes duplicate Initializable in
inheritance; change the import paths to the upgradeable versions (e.g. use
@openzeppelin/contracts-upgradeable/... for Initializable and UUPSUpgradeable)
so both Initializable and UUPSUpgradeable come from the upgradeable package and
avoid inheritance conflicts.
| ␊ | ||
| contract MyGovernor is Initializable, GovernorUpgradeable, GovernorCountingSimpleUpgradeable, GovernorVotesUpgradeable, GovernorVotesQuorumFractionUpgradeable, GovernorTimelockControlUpgradeable, UUPSUpgradeable {␊ | ||
| /// @custom:oz-upgrades-unsafe-allow constructor␊ | ||
| /// @custom:oz-upgrades-unsafe-allow-reachable constructor␊ |
There was a problem hiding this comment.
🧩 Analysis chain
“reachable constructor” annotation — OK
Matches updated guidance; just ensure docs and codegen comments elsewhere use the same wording.
🏁 Script executed:
#!/bin/bash
# Check for legacy “oz-upgrades-unsafe-allow constructor” occurrences
rg -n 'oz-upgrades-unsafe-allow constructor'Length of output: 418
Replace legacy “oz-upgrades-unsafe-allow constructor” annotations
Ensure all docs and codegen comments use @custom:oz-upgrades-unsafe-allow-reachable constructor instead of the old form:
- packages/core/solidity/src/zip-hardhat.test.ts.md:172
- packages/core/solidity/src/custom.test.ts.md:66
- packages/core/solidity/src/print.ts:92, 127
🤖 Prompt for AI Agents
In packages/core/solidity/src/governor.test.ts.md around line 1621, replace the
legacy oz-upgrades annotation with the new form by changing any occurrence of
"oz-upgrades-unsafe-allow constructor" (or variants) to
"@custom:oz-upgrades-unsafe-allow-reachable constructor"; update the comment
line exactly to use the new @custom:... token so docs/codegen pick up the
corrected annotation.
| c.addParent({ | ||
| name: 'Initializable', | ||
| path: '@openzeppelin/contracts/proxy/utils/Initializable.sol', | ||
| transpiled: false, | ||
| }); | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
Risk: disabling transpilation may import non-upgradeable parents in upgradeable builds
Setting transpiled: false on Initializable and UUPSUpgradeable prevents the wizard’s upgradeable transpiler from rewriting imports to @openzeppelin/contracts-upgradeable/.... For UUPS, best practice is to use the -upgradeable variant when writing upgradeable implementations. Recommend allowing transpilation (remove the flag) so upgradeable builds import from the -upgradeable package.
Apply either of the following:
Option A (preferred: let the helper do its job)
c.addParent({
name: 'Initializable',
path: '@openzeppelin/contracts/proxy/utils/Initializable.sol',
- transpiled: false,
});
...
const UUPSUpgradeable = {
name: 'UUPSUpgradeable',
path: '@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol',
- transpiled: false,
};Option B (explicit path since upgradeable !== false here)
- path: '@openzeppelin/contracts/proxy/utils/Initializable.sol',
+ path: '@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol',- path: '@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol',
+ path: '@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol',Please confirm which approach matches the current transpilation pipeline for non-account contracts. References: OZ docs and guidance recommend importing UUPS from the -upgradeable package for upgradeable implementations. (docs.openzeppelin.com)
Based on learnings.
Also applies to: 33-37
🏁 Script executed:
#!/bin/bash
set -e
echo "=== addParent occurrences in set-upgradeable.ts ==="
rg -n "addParent" -C2 packages/core/solidity/src/set-upgradeable.ts || true
echo
echo "=== UUPSUpgradeable occurrences in set-upgradeable.ts ==="
rg -n "UUPSUpgradeable" -C2 packages/core/solidity/src/set-upgradeable.ts || true
echo
echo "=== transpiled usage in set-upgradeable.ts ==="
rg -n "transpiled" -C2 packages/core/solidity/src/set-upgradeable.ts || trueLength of output: 1300
🏁 Script executed:
#!/bin/bash
rg -nR "transpiled" -C2 packages/core/solidity/srcLength of output: 404
Enable transpilation for upgradeable parents
Remove the transpiled: false properties from the Initializable and UUPSUpgradeable parent entries in packages/core/solidity/src/set-upgradeable.ts so the wizard’s transpiler rewrites their imports to @openzeppelin/contracts-upgradeable/....
🤖 Prompt for AI Agents
In packages/core/solidity/src/set-upgradeable.ts around lines 21 to 26, the
parent entries for Initializable and UUPSUpgradeable currently set transpiled:
false which prevents the wizard transpiler from rewriting their imports; remove
the transpiled: false properties from the Initializable and UUPSUpgradeable
addParent calls (so the transpiler will map imports to
@openzeppelin/contracts-upgradeable/...) and ensure no other code relies on that
property being present.
| EIP7702: { | ||
| name: 'SignerEIP7702', | ||
| path: '@openzeppelin/contracts/utils/cryptography/signers/SignerEIP7702.sol', | ||
| }, |
There was a problem hiding this comment.
SignerEIP7702 path/name likely incorrect for OZ 5.5 rc
OZ 5.x exposes SignerERC7702 at utils/cryptography/signers/SignerERC7702.sol (docs and releases still reference ERC, not EIP). Keeping the user-facing option string as 'EIP7702' is fine, but map it to the existing contract.
Apply this diff:
EIP7702: {
- name: 'SignerEIP7702',
- path: '@openzeppelin/contracts/utils/cryptography/signers/SignerEIP7702.sol',
+ name: 'SignerERC7702',
+ path: '@openzeppelin/contracts/utils/cryptography/signers/SignerERC7702.sol',
},Sources: OZ docs and releases list SignerERC7702 and EIP7702Utils, not SignerEIP7702. (docs.openzeppelin.com)
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| EIP7702: { | |
| name: 'SignerEIP7702', | |
| path: '@openzeppelin/contracts/utils/cryptography/signers/SignerEIP7702.sol', | |
| }, | |
| EIP7702: { | |
| name: 'SignerERC7702', | |
| path: '@openzeppelin/contracts/utils/cryptography/signers/SignerERC7702.sol', | |
| }, |
🤖 Prompt for AI Agents
In packages/core/solidity/src/signer.ts around lines 45 to 48, the mapping
currently references a non-existent OpenZeppelin contract name/path; update the
mapping so the user-facing option key remains 'EIP7702' but map it to the actual
OZ contract by changing the name to 'SignerERC7702' and the path to
'utils/cryptography/signers/SignerERC7702.sol' (matching OZ 5.5 RC), ensuring
the entry uses the correct contract filename and path.
| <label class:checked={opts.signer === 'EIP7702'}> | ||
| <input type="radio" bind:group={opts.signer} value="EIP7702" use:error={errors?.eip7702} /> | ||
| EOA Delegation |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
UI binding updated to errors?.eip7702 — confirm rename consistency across validators and messages.
Looks right. Verify core error keys/messages were migrated from erc7702 → eip7702 everywhere (types, validators, i18n).
🏁 Script executed:
#!/bin/bash
# Check for any stale error keys/usages
rg -nP 'erc7702\b|ERC7702\b'Length of output: 2343
Update remaining ERC7702 references to EIP7702
- packages/mcp/src/solidity/schemas.ts:126 — change
z.literal('ERC7702')→z.literal('EIP7702') - packages/ui/api/ai-assistant/function-definitions/solidity.ts:205 — replace
'ERC7702'enum entry →'EIP7702' - packages/common/src/ai/descriptions/solidity.ts:69 — update descriptive text to “EIP7702”
🤖 Prompt for AI Agents
In packages/ui/src/solidity/AccountControls.svelte around lines 178 to 180,
update the remaining ERC7702 references across the codebase to EIP7702: change
packages/mcp/src/solidity/schemas.ts line ~126 from z.literal('ERC7702') to
z.literal('EIP7702'); update
packages/ui/api/ai-assistant/function-definitions/solidity.ts around line ~205
replacing the 'ERC7702' enum entry with 'EIP7702'; and update the descriptive
text in packages/common/src/ai/descriptions/solidity.ts at ~line 69 to use
"EIP7702" instead of "ERC7702". Ensure tests/types still compile and update any
related imports or usages to the new literal/name consistently.
Fixes #660