Conversation
- Add GatewayUpgrade module for upgrading Gateway proxy contracts - Add GatewayDeployProxy module for initial proxy deployments - Create parameter files for all 11 networks (arbitrumOne, base, bsc, polygon, mainnet, optimisticEthereum, scroll, celo, assetChain, lisk, baseSepolia) - Update README with Hardhat Ignition deployment instructions - Support both parameter file and inline parameter approaches - Include deployment records, artifacts, and generated types - Update .gitignore to exclude only network-chain-ids.json
📝 WalkthroughWalkthroughAdds a Hardhat v3 config and Ignition-based deployment artifacts for a new Gateway system (Gateway, GatewaySettingManager, IGateway), migrates artifact/build-info formats to hh3, removes legacy OpenZeppelin debug artifacts, and updates CI/node and README/gitignore to reflect Ignition workflows and ignored files. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant Gateway as "Gateway (contract)"
participant Token as "ERC20 Token"
participant Settings as "GatewaySettingManager"
participant Treasury as "Treasury/Protocol"
participant LP as "Liquidity Provider"
User->>Gateway: createOrder(token, amount, rate, senderFeeRecipient, senderFee, refundAddress, msgHash)
Gateway->>Token: transferFrom(User -> Gateway, amount + senderFee)
Gateway->>Settings: getTokenFeeSettings(token)
Settings-->>Gateway: TokenFeeSettings(senderToProvider, providerToAggregator, senderToAggregator, providerToAggregatorFx)
Gateway-->>User: emit OrderCreated(orderId)
Note right of Gateway: order state stored (sender, token, amount, fees)
LP->>Gateway: settle(splitOrderId, orderId, lpAddress, settlePercent, rebatePercent)
Gateway->>Settings: getTokenFeeSettings(token)
Gateway->>Token: transfer(Gateway -> LP/provider/aggregator/treasury) -- fee-splitting according to settings
Gateway->>Treasury: transfer(protocol fees)
Gateway-->>LP: emit OrderSettled(splitOrderId, orderId, lpAddress, settlePercent, rebatePercent)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
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. 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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
README.md (2)
1-1: Solidity badge shows 0.8.18 but build uses 0.8.20.Update the badge to avoid confusion or pin the compiler version used by Hardhat.
49-59:updateProtocolFee.tsis referenced butprotocolFeePercentis deprecated in code.Either remove this command from docs or clarify that the field is kept only for storage layout and should not be used.
♻️ Duplicate comments (1)
ignition/deployments/chain-137/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json (1)
59-61: Same Gateway issues apply in this build-info.Please apply the Gateway fixes here as well (emit param, nonReentrant, SafeERC20, refund accounting).
🧹 Nitpick comments (4)
.gitignore (1)
13-18: Clarify section structure and deployment artifact handling.A few organizational concerns:
- Line 14 introduces a
# typessection header, but the related entries (typechain,typechain-types) are several lines above (lines 6–7), breaking logical grouping.- Line 13's
# artifactscomment has no entries beneath it—likely vestigial.- Line 17 shows
# ignition/deployments/as a commented entry, which is non-standard for.gitignoreand creates ambiguity about whether deployment records should be committed.Per the PR summary, new artifacts, deployments, and generated types are added to the repo. Verify whether build outputs (e.g.,
ignition/artifacts/,ignition/build-info/, or similar) should also be excluded, or if intentionally committing them.Consider consolidating comment headers and removing the stray commented entry. Example structure:
-typechain -typechain-types +typechain +typechain-types privateKey.txt publicKey.txt -# Hardhat files -cache -# artifacts -# types +# Hardhat files +cache -# Hardhat Ignition deployments (contains deployment records) -# ignition/deployments/ +# Hardhat Ignition ignition/network-chain-ids.jsonThen, confirm whether the following should also be ignored:
ignition/artifacts/ignition/build-info/- Any other generated build or deployment output directories
README.md (1)
33-47: Chained&&upgrades will stop on first failure.Consider documenting
set -ebehavior or suggest per-network runs with logging to improve operability in CI.ignition/deployments/chain-10/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json (1)
31-35: Remove duplicate remapping in compil configuration.Line 32 and 33 contain identical remappings for
@openzeppelin/contracts-upgradeable, which is redundant. While Hardhat may tolerate this, it suggests an issue in the build configuration or build process.Verify that the Hardhat configuration does not inadvertently add duplicate entries during the upgrade from V2 to V3, and remove the duplicate before finalizing deployments.
ignition/deployments/chain-42161/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json (1)
31-35: Duplicate remapping persists across chain deployments.Line 32 and 33 contain the same redundant remapping for
@openzeppelin/contracts-upgradeable@4.9.5. This issue appears consistently in the chain-10 build-info as well, indicating a systematic problem in the Hardhat V3 build or deployment configuration.This should be corrected in the Hardhat configuration to prevent similar artifacts in future deployments across all chains.
Verify that your
hardhat.config.tsdoes not explicitly define duplicate remappings in thecompilerOptions.remappingsarray or that Hardhat V3 is not auto-duplicating them during build.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (55)
.gitignore(1 hunks)README.md(2 hunks)artifacts/@openzeppelin/contracts-upgradeable/access/Ownable2StepUpgradeable.sol/Ownable2StepUpgradeable.dbg.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/access/Ownable2StepUpgradeable.sol/Ownable2StepUpgradeable.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol/OwnableUpgradeable.dbg.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol/OwnableUpgradeable.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol/Initializable.dbg.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol/Initializable.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol/PausableUpgradeable.dbg.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol/PausableUpgradeable.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol/AddressUpgradeable.dbg.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol/AddressUpgradeable.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/utils/ContextUpgradeable.sol/ContextUpgradeable.dbg.json(0 hunks)artifacts/@openzeppelin/contracts-upgradeable/utils/ContextUpgradeable.sol/ContextUpgradeable.json(0 hunks)artifacts/@openzeppelin/contracts/token/ERC20/ERC20.sol/ERC20.dbg.json(0 hunks)artifacts/@openzeppelin/contracts/token/ERC20/ERC20.sol/ERC20.json(0 hunks)artifacts/@openzeppelin/contracts/token/ERC20/IERC20.sol/IERC20.dbg.json(0 hunks)artifacts/@openzeppelin/contracts/token/ERC20/IERC20.sol/IERC20.json(0 hunks)artifacts/@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol/IERC20Metadata.dbg.json(0 hunks)artifacts/@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol/IERC20Metadata.json(0 hunks)artifacts/@openzeppelin/contracts/utils/Context.sol/Context.dbg.json(0 hunks)artifacts/@openzeppelin/contracts/utils/Context.sol/Context.json(0 hunks)artifacts/build-info/solc-0_8_20-11c139c572509cc55b8bc0acb648f3544f45b6c1.json(1 hunks)artifacts/build-info/solc-0_8_20-11c139c572509cc55b8bc0acb648f3544f45b6c1.output.json(1 hunks)artifacts/build-info/solc-0_8_20-30f6338e4a4b8728ca8a0716c9d710a1b26d40b7.json(1 hunks)artifacts/build-info/solc-0_8_20-32286d087051e35025cad535aaaac947e68287bf.json(1 hunks)artifacts/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json(1 hunks)artifacts/contracts/Gateway.sol/Gateway.dbg.json(0 hunks)artifacts/contracts/Gateway.sol/artifacts.d.ts(1 hunks)artifacts/contracts/GatewaySettingManager.sol/GatewaySettingManager.dbg.json(0 hunks)artifacts/contracts/GatewaySettingManager.sol/GatewaySettingManager.json(2 hunks)artifacts/contracts/GatewaySettingManager.sol/artifacts.d.ts(1 hunks)artifacts/contracts/interfaces/IGateway.sol/IGateway.dbg.json(0 hunks)artifacts/contracts/interfaces/IGateway.sol/IGateway.json(2 hunks)artifacts/contracts/interfaces/IGateway.sol/artifacts.d.ts(1 hunks)artifacts/contracts/mocks/MockUSDC.sol/MockUSDT.dbg.json(0 hunks)artifacts/contracts/mocks/MockUSDC.sol/MockUSDT.json(2 hunks)artifacts/contracts/mocks/MockUSDC.sol/artifacts.d.ts(1 hunks)ignition/deployments/chain-10/artifacts/Gateway#Gateway.json(1 hunks)ignition/deployments/chain-10/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json(1 hunks)ignition/deployments/chain-10/deployed_addresses.json(1 hunks)ignition/deployments/chain-10/journal.jsonl(1 hunks)ignition/deployments/chain-137/artifacts/Gateway#Gateway.json(1 hunks)ignition/deployments/chain-137/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json(1 hunks)ignition/deployments/chain-137/deployed_addresses.json(1 hunks)ignition/deployments/chain-137/journal.jsonl(1 hunks)ignition/deployments/chain-42161/artifacts/Gateway#Gateway.json(1 hunks)ignition/deployments/chain-42161/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json(1 hunks)ignition/deployments/chain-42161/deployed_addresses.json(1 hunks)ignition/deployments/chain-42161/journal.jsonl(1 hunks)ignition/deployments/chain-42220/artifacts/Gateway#Gateway.json(1 hunks)ignition/deployments/chain-42220/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json(1 hunks)ignition/deployments/chain-42220/deployed_addresses.json(1 hunks)ignition/deployments/chain-42220/journal.jsonl(1 hunks)ignition/deployments/chain-534352/artifacts/Gateway#Gateway.json(1 hunks)
💤 Files with no reviewable changes (24)
- artifacts/@openzeppelin/contracts/utils/Context.sol/Context.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol/AddressUpgradeable.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/utils/ContextUpgradeable.sol/ContextUpgradeable.dbg.json
- artifacts/@openzeppelin/contracts/token/ERC20/IERC20.sol/IERC20.dbg.json
- artifacts/contracts/interfaces/IGateway.sol/IGateway.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol/OwnableUpgradeable.dbg.json
- artifacts/@openzeppelin/contracts/token/ERC20/ERC20.sol/ERC20.json
- artifacts/@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol/IERC20Metadata.json
- artifacts/@openzeppelin/contracts/utils/Context.sol/Context.json
- artifacts/@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol/IERC20Metadata.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol/PausableUpgradeable.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/access/Ownable2StepUpgradeable.sol/Ownable2StepUpgradeable.dbg.json
- artifacts/@openzeppelin/contracts/token/ERC20/IERC20.sol/IERC20.json
- artifacts/contracts/GatewaySettingManager.sol/GatewaySettingManager.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol/Initializable.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol/AddressUpgradeable.json
- artifacts/@openzeppelin/contracts-upgradeable/utils/ContextUpgradeable.sol/ContextUpgradeable.json
- artifacts/@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol/Initializable.json
- artifacts/@openzeppelin/contracts/token/ERC20/ERC20.sol/ERC20.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/access/Ownable2StepUpgradeable.sol/Ownable2StepUpgradeable.json
- artifacts/@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol/OwnableUpgradeable.json
- artifacts/contracts/Gateway.sol/Gateway.dbg.json
- artifacts/contracts/mocks/MockUSDC.sol/MockUSDT.dbg.json
- artifacts/@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol/PausableUpgradeable.json
🔇 Additional comments (25)
ignition/deployments/chain-534352/artifacts/Gateway#Gateway.json (1)
1-774: This is an auto-generated artifact file from Hardhat V3 compilation.The artifact file is properly formatted and uses the Hardhat V3 artifact format (
hh3-artifact-1on line 2). All required fields are present: contract metadata, complete ABI with functions and events, bytecode, deployedBytecode, and build information. No issues detected.Note: Artifacts are typically generated during compilation and not committed to version control. However, given the PR objectives reference "deployment records, artifacts, and generated types," this appears to be intentional for tracking deployments across chain 534352 (Scroll). If this pattern extends to other chains in the PR, ensure there's a clear deployment record strategy documented.
artifacts/contracts/interfaces/IGateway.sol/artifacts.d.ts (1)
1-27: LGTM! Auto-generated Hardhat V3 artifact typing.This auto-generated TypeScript artifact type file follows Hardhat V3 conventions correctly. The empty bytecode fields are expected for an interface, and the module augmentation pattern properly extends Hardhat's type system.
artifacts/contracts/GatewaySettingManager.sol/GatewaySettingManager.json (2)
2-2: Artifact format successfully updated to Hardhat V3.The artifact format change from
hh-sol-artifact-1tohh3-artifact-1is correct for the Hardhat V3 upgrade.
323-326: New Hardhat V3 artifact metadata fields added correctly.The new fields (
deployedLinkReferences,immutableReferences,inputSourceName,buildInfoId) are standard additions in the hh3-artifact-1 format and properly populated.artifacts/contracts/mocks/MockUSDC.sol/MockUSDT.json (2)
2-2: Artifact format successfully updated to Hardhat V3.The artifact format change from
hh-sol-artifact-1tohh3-artifact-1is correct for the Hardhat V3 upgrade.
318-321: New Hardhat V3 artifact metadata fields added correctly.The new fields (
deployedLinkReferences,immutableReferences,inputSourceName,buildInfoId) are standard additions in the hh3-artifact-1 format and properly populated for the MockUSDT contract.ignition/deployments/chain-10/deployed_addresses.json (1)
1-3: I need to verify whether this address is a legitimate Gateway contract deployment on Optimism.Let me search more specifically for this address:
Based on my verification attempts, the address
0xafbf71A72d30f81eb66baaF904ea537fD35dd106does not appear in publicly available search results or well-indexed contract databases. This doesn't indicate the address is invalid—it simply means it may be a newly deployed contract, a project-specific deployment, or not yet indexed by search engines.The original review comment is appropriate in requesting manual verification on Optimistic Etherscan, as this is the only definitive way to confirm:
- The contract exists at that address on Optimism (chain-10)
- The contract code is correct
- The contract is properly initialized
Verify this deployment exists on Optimistic Etherscan at the address
0xafbf71A72d30f81eb66baaF904ea537fD35dd106.Visit https://optimistic.etherscan.io/address/0xafbf71A72d30f81eb66baaF904ea537fD35dd106 to confirm the contract is deployed and verify its bytecode matches the expected Gateway contract implementation.
ignition/deployments/chain-10/journal.jsonl (1)
1-8: Deployment verification confirms successful Gateway contract deployment.The review comment is accurate:
- ✓ Contract address
0xafbf71A72d30f81eb66baaF904ea537fD35dd106matchesdeployed_addresses.json- ✓ Journal documents successful deployment with receipt status "SUCCESS"
- ✓ All deployment lifecycle events correctly recorded
ignition/deployments/chain-42161/deployed_addresses.json (1)
1-3: Verify the deployment address against on-chain records.Web search found no public records of this address being a deployed Arbitrum Gateway contract. Verify this address directly on Arbiscan at https://arbiscan.io/address/0xC3D112F5C03F050c64ADc8EF94469Eadba7A0861 or confirm it against your deployment logs and bridge configuration.
ignition/deployments/chain-137/deployed_addresses.json (1)
1-3: Review comment is appropriate as-is; no changes needed.The review comment already provides sound guidance. Since on-chain verification of smart contract deployments requires external API access (Polygonscan or Polygon RPC endpoints) that is not available in automated testing environments, manual verification via Polygonscan is the correct and standard approach. The comment appropriately directs the developer to verify the deployment by visiting the Polygonscan link with the correct address and chain identifier.
artifacts/build-info/solc-0_8_20-11c139c572509cc55b8bc0acb648f3544f45b6c1.json (1)
36-41: IGateway looks consistent; ensure event param semantics match implementation.Interface declares
OrderCreated(sender, ...). After fixing Gateway emit to usemsg.sender, interface/impl will align.artifacts/contracts/interfaces/IGateway.sol/IGateway.json (1)
392-396: Artifact metadata looks good.
_format,inputSourceName, andbuildInfoIdalign with the new hh3 format. No action needed.artifacts/build-info/solc-0_8_20-11c139c572509cc55b8bc0acb648f3544f45b6c1.output.json (1)
1-1: No actionable issues in compiler output.Build info matches IGateway surface; primary fixes are in the implementation.
ignition/deployments/chain-42220/journal.jsonl (1)
2-8: Direct Gateway deployment confirmed for chain-42220; proxy infrastructure exists but was not used.The journal correctly shows
Gateway#Gatewayas a direct contract deployment to0xD293fCd3dBc025603911853d893A4724CF9f70a0, not aTransparentUpgradeableProxywrapper. However, the codebase contains proxy-capable Ignition modules (GatewayDeployProxy.tsdeploys aTransparentUpgradeableProxy, andGatewayUpgrade.tshandles proxy upgrades), suggesting the intended pattern differs from what was executed on chain-42220.The Gateway contract itself uses
Ownable2StepUpgradeable, confirming upgradeable design. Verify whether the direct implementation deployment is intentional or ifGatewayDeployProxyshould have been executed instead.ignition/deployments/chain-42161/journal.jsonl (1)
2-8: Gateway deployment journal for chain 42161 is internally consistentThe sequence of initialize → network interaction → tx prepare/send → confirm → complete is coherent, with matching
futureId,networkInteractionId, transaction hash, and contract address across entries. Nothing to change here.ignition/deployments/chain-42220/build-info/solc-0_8_20-7d0fb87933a3e81eaffd16a88ca58fbb4054f174.json (1)
1-70: Build-info JSON for chain 42220 looks structurally correctThe build-info document follows the expected hh3 build-info layout, with coherent compiler settings, remappings, and embedded sources, and an
idsuitable for linkage from artifacts. No changes needed here.ignition/deployments/chain-10/artifacts/Gateway#Gateway.json (1)
1-774: Gateway artifact for chain 10 is consistent and ready for useThe artifact uses the hh3 artifact format, has a complete ABI for Gateway (including order, fee, and ownership APIs), and references the expected
inputSourceNameandbuildInfoId. No adjustments required.ignition/deployments/chain-42220/artifacts/Gateway#Gateway.json (1)
1-774: Gateway artifact for chain 42220 matches the shared implementationThis artifact is structurally identical to the chain-10 Gateway artifact (same ABI,
inputSourceName, andbuildInfoId), differing only by deployment context, which is what we want for multi-chain deployment. No changes needed.ignition/deployments/chain-137/journal.jsonl (1)
2-8: Gateway deployment journal for chain 137 is coherentThe deployment flow and metadata (nonce, hash,
networkInteractionId, receipt, and final result) line up correctly, and the additional native-token accounting log is expected for Polygon. No edits required.artifacts/contracts/Gateway.sol/artifacts.d.ts (1)
7-27: Typed Gateway artifact wiring looks correct
Gateway$Typematches the hh3 artifact shape and theArtifactMapaugmentation correctly exposes both the short and fully-qualified keys; nothing to change here. Just rely on regeneration if the contract ABI/bytecode changes.ignition/deployments/chain-137/artifacts/Gateway#Gateway.json (1)
1-774: Gateway Ignition artifact for chain 137 is consistentThe hh3 artifact structure, ABI, bytecode/deployedBytecode, and
buildInfoIdall look consistent with the typed Gateway artifact; this should work fine for Ignition deployments on chain 137.artifacts/contracts/mocks/MockUSDC.sol/artifacts.d.ts (1)
7-27: MockUSDT artifact typing matches the contract surfaceThe
MockUSDT$Typeinterface correctly reflects the ERC‑20 style ABI and the ArtifactMap entries for both short and fully‑qualified names are set up properly; no issues here.artifacts/contracts/GatewaySettingManager.sol/artifacts.d.ts (1)
7-27: GatewaySettingManager artifact typing looks goodThe
GatewaySettingManager$Typeinterface andArtifactMapaugmentation correctly describe the contract ABI and metadata for hh3 artifacts; no changes needed on this TypeScript side.artifacts/build-info/solc-0_8_20-30f6338e4a4b8728ca8a0716c9d710a1b26d40b7.json (1)
51-53: Incorrect root cause analysis; the actual deployment bug is in the Ignition moduleThe review comment correctly identifies a critical problem, but misdiagnoses its cause. While
GatewaySettingManagerindeed lacks an initializer, it's a base contract never deployed standalone. The real issue is thatignition/modules/GatewayDeployProxy.tsdeploys theGatewayproxy with empty initialization data ("0x"), preventingGateway.initialize()from being invoked during deployment. This leavesMAX_BPS = 0and_owner = address(0), breaking all owner-protected functions.The hardhat
scripts/deploy.tscorrectly usesupgrades.deployProxy(factory)which callsinitialize(), but the Ignition module does not. The fix requires updatingGatewayDeployProxy.tsto encode proper initialization data when creating the proxy, not modifying the Solidity source files.Likely an incorrect or invalid review comment.
ignition/deployments/chain-42161/artifacts/Gateway#Gateway.json (1)
2-4: Artifact format is compliant with Hardhat V3 standards.The artifact correctly uses the
hh3-artifact-1format, includes all required fields (ABI, bytecode, deployedBytecode, linkReferences, immutableReferences), and properly maps source names.
artifacts/build-info/solc-0_8_20-32286d087051e35025cad535aaaac947e68287bf.json
Outdated
Show resolved
Hide resolved
artifacts/build-info/solc-0_8_20-100c86a0ad428850c64dd979e8770b5f8b18515c.json
Show resolved
Hide resolved
- Removed outdated dependencies from package.json and added new ones for hardhat toolbox and verification. - Deleted deploy.ts and upgrade.ts scripts as they are no longer needed for the current deployment strategy. - Updated hardhat version to 3.0.12 and typechain to 8.3.2. - Set module type in package.json for better compatibility with ES modules.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @hardhat.config.ts:
- Around line 6-7: The RPC URL construction currently uses env values from
dotEnvResult/ env which can be undefined and will stringify to "undefined" in
URLs; update the hardhat config to validate required vars (e.g.,
SHIELD3_API_KEY) after reading dotEnvResult and env, and either throw a clear
error if missing or supply a safe fallback (empty string or placeholder) before
using them in network RPC URL templates (the code that builds the Shield3 RPC
URLs). Ensure the validation runs at startup (before network objects are
created) and that any thrown error includes the missing variable name and a
brief remediation message so deployments fail fast with a clear message.
- Around line 19-21: The config contains network options using the
hardhat-deploy-specific key saveDeployments (e.g., the object with chainId:
42161, saveDeployments: true) which Hardhat v3 will ignore; either install and
configure the hardhat-deploy plugin or remove every saveDeployments: true entry
from the network configuration objects in hardhat.config.ts (search for
saveDeployments across the 12 network blocks) so configs are not dead code—if
you choose the plugin, add it to package.json and import/register it in
hardhat.config.ts; if you choose removal, simply delete the saveDeployments
lines from each network object.
🧹 Nitpick comments (1)
hardhat.config.ts (1)
96-124: Inconsistent optimizer settings across compiler versions.The optimizer is disabled for Solidity 0.8.18 and 0.8.9 but enabled for 0.8.20. If this is intentional (e.g., different contracts require different settings), consider adding a comment explaining the rationale. Otherwise, enabling the optimizer consistently would reduce deployment gas costs.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
hardhat.config.tspackage.jsonscripts/deploy.tsscripts/upgrade.ts
🔇 Additional comments (3)
hardhat.config.ts (3)
126-130: LGTM!The verify configuration correctly pulls the API key from environment variables with a sensible empty string fallback for development environments.
11-12: LGTM!The migration to Hardhat v3's
defineConfigpattern with explicit plugin registration is correct.
131-161: VerifychainDescriptorsschema for Hardhat v3 verify plugin.The
urlandapiUrlproperties appear to have inverted semantics (e.g.,urlcontains the API endpointhttps://api.celoscan.io/apiwhileapiUrlcontains the browser URLhttps://celoscan.io/). This naming is counterintuitive and may cause verification failures if the plugin expects different semantics.Hardhat v3 hardhat-verify chainDescriptors configuration schema blockExplorers
… to latest version
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @hardhat.config.ts:
- Around line 6-7: The code currently sets env from dotEnvResult.parsed only,
which ignores system/CI environment variables; update the logic that defines env
(and any uses of env) to merge process.env with dotEnvResult.parsed so system
variables take effect (e.g., compute env = { ...(dotEnvResult.parsed ?? {}),
...process.env } or prefer process.env over parsed values), locating the
assignment to dotEnvResult and env in hardhat.config.ts and replacing it with
the merged approach so CI-injected secrets are honored.
- Around line 109-139: The chainDescriptors entries for networks 42220 (celo),
534352 (scroll) and 1135 (lisk) have their explorer fields reversed: swap the
values so that `url` holds the human-facing explorer web URL and `apiUrl` holds
the API endpoint used for verification; update the
`chainDescriptors[42220].blockExplorers.etherscan`,
`chainDescriptors[534352].blockExplorers.etherscan`, and
`chainDescriptors[1135].blockExplorers.etherscan` objects accordingly so each
`url` is the UI URL (e.g., https://celoscan.io/, https://scrollscan.com/,
https://explorer.lisk.com) and each `apiUrl` is the API endpoint (e.g.,
https://api.celoscan.io/api, https://api.scrollscan.com/api,
https://explorer.lisk.com/api).
- Around line 104-108: The current verify configuration uses a single global
etherscan.apiKey which fails for networks needing separate explorers; update the
verify object to provide per-network API keys (use Hardhat network identifiers
like 'celo', 'scrollOne', 'lisk') under verify.etherscan with keys mapping to
env variables (e.g., env.CELOSCAN_API_KEY, env.SCROLLSCAN_API_KEY,
env.LISK_API_KEY), and add a customChains entry for Lisk in the verify
configuration (using the verify.customChains array) so the Lisk explorer is
registered with the correct chainId and API/URL settings; modify the verify
block and ensure references to etherscan.apiKey are replaced by the per-network
mapping and the customChains includes the Lisk definition.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
artifacts/build-info/solc-0_8_20-100c86a0ad428850c64dd979e8770b5f8b18515c.jsonartifacts/build-info/solc-0_8_20-100c86a0ad428850c64dd979e8770b5f8b18515c.output.jsonartifacts/contracts/Gateway.sol/Gateway.jsonartifacts/contracts/Gateway.sol/artifacts.d.tsartifacts/contracts/GatewaySettingManager.sol/GatewaySettingManager.jsonartifacts/contracts/GatewaySettingManager.sol/artifacts.d.tsartifacts/contracts/interfaces/IGateway.sol/IGateway.jsonartifacts/contracts/interfaces/IGateway.sol/artifacts.d.tsartifacts/contracts/mocks/MockUSDC.sol/MockUSDT.jsonartifacts/contracts/mocks/MockUSDC.sol/artifacts.d.tshardhat.config.tstypes/ethers-contracts/factories/GatewaySettingManager__factory.tstypes/ethers-contracts/factories/mocks/MockUSDC.sol/MockUSDT__factory.ts
✅ Files skipped from review due to trivial changes (1)
- artifacts/build-info/solc-0_8_20-100c86a0ad428850c64dd979e8770b5f8b18515c.json
🚧 Files skipped from review as they are similar to previous changes (4)
- artifacts/contracts/interfaces/IGateway.sol/IGateway.json
- artifacts/contracts/GatewaySettingManager.sol/artifacts.d.ts
- artifacts/contracts/interfaces/IGateway.sol/artifacts.d.ts
- artifacts/contracts/GatewaySettingManager.sol/GatewaySettingManager.json
🔇 Additional comments (5)
artifacts/contracts/mocks/MockUSDC.sol/MockUSDT.json (1)
2-2: LGTM - Hardhat V3 artifact format update.The artifact format change from
hh-sol-artifact-1tohh3-artifact-1and the addition of new fields (immutableReferences,inputSourceName,buildInfoId) are consistent with the Hardhat V3 migration objective.Also applies to: 318-321
artifacts/contracts/mocks/MockUSDC.sol/artifacts.d.ts (1)
1-27: LGTM - Auto-generated Hardhat V3 artifact types.This file is auto-generated by Hardhat (as noted in line 1) and correctly defines type-safe artifact access for the MockUSDT contract. The
MockUSDT$Typeinterface and module augmentation follow Hardhat V3's standard pattern for typed artifacts.artifacts/contracts/Gateway.sol/artifacts.d.ts (1)
1-27: No action needed—auto-generated artifacts are intentionally tracked in this repository.The file is correctly generated and committed. The
.gitignoreincludes# artifactsas a commented-out rule, indicating a deliberate decision to track these files. Multiple auto-generated artifact type declarations (.d.tsfiles) and build metadata are already committed across the repository, confirming this is the project's standard practice.hardhat.config.ts (2)
11-72: LGTM!Network configurations correctly use Hardhat V3's
type: "http"syntax with consistent environment variable handling across all networks.
73-103: LGTM!Per-compiler optimizer settings are correctly structured. The optimizer is enabled only for 0.8.20 (production contracts) while older versions have it disabled.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/hardhat.yml:
- Around line 12-15: Update the GitHub Actions step name to match the configured
Node.js version: change the step title "Use Node.js 18" to "Use Node.js 22" in
the workflow step that uses actions/setup-node@v3 with node-version: 22.18.0 so
the label accurately reflects the Node runtime being installed.
🧹 Nitpick comments (2)
.github/workflows/hardhat.yml (1)
12-12: Update the step label to match the new Node version.♻️ Proposed fix
- - name: Use Node.js 18 + - name: Use Node.js 22hardhat.config.ts (1)
17-73: Avoid defaulting live networks to a known test key; normalize key format.
Line 20+ (repeated): usingtestPrivateKeyas a fallback can mask missing secrets and lead to accidental/failed deployments. Also ensure private keys are 0x‑prefixed for Hardhat v3.♻️ Safer pattern (apply across networks)
-const testPrivateKey = "0000000000000000000000000000000000000000000000000000000000000001" +const normalizePk = (pk?: string) => + pk ? (pk.startsWith("0x") ? pk : `0x${pk}`) : undefined; +const deployerKey = normalizePk(env.DEPLOYER_PRIVATE_KEY);-accounts: [env.DEPLOYER_PRIVATE_KEY || testPrivateKey], +accounts: deployerKey ? [deployerKey] : [],
| - name: Use Node.js 18 | ||
| uses: actions/setup-node@v3 | ||
| with: | ||
| node-version: 18.16.0 | ||
| node-version: 22.18.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Hardhat v3 Node.js version support requirements
💡 Result:
Hardhat v3’s Node.js requirements are:
- Minimum Node.js version: v22.10.0 or newer. (hardhat.org)
- Support policy: Hardhat 3 supports even-numbered major Node.js releases (e.g., 22, 24, 26, …) while they’re maintained by the Node.js team (release status: Current / Active LTS / Maintenance). (hardhat.org)
- When support is dropped: Hardhat stops supporting a Node version after it’s no longer maintained (Hardhat notes it will stop testing against it and may start using newer Node features). (hardhat.org)
- Docs’ practical prerequisite wording: “Node.js v22 or later.” (hardhat.org)
Citations:
- 1: https://hardhat.org/docs/reference/nodejs-support?utm_source=openai
- 2: https://hardhat.org/nodejs-versions?utm_source=openai
- 3: https://hardhat.org/docs/reference/nodejs-support?utm_source=openai
- 4: https://hardhat.org/getting-started?utm_source=openai
🌐 Web query:
@nomicfoundation hardhat-verify Node.js version compatibility
💡 Result:
@nomicfoundation/hardhat-verify doesn’t define its own Node.js support window in isolation—its Node compatibility follows the Hardhat version it’s meant to be used with.
- If you’re using Hardhat 3 / hardhat-verify v3.x: Hardhat 3 requires Node.js ≥ 22.10.0 and supports subsequent even-numbered Node majors while they’re maintained (so Node 23.x is not supported, but 22.x and 24.x are). [1][2]
- If you’re using Hardhat 2 / older hardhat-verify: Hardhat supports released and supported even Node.js versions (Current/Active LTS/Maintenance) and drops support shortly after a Node version reaches EOL. [3]
Practical rule: pick your Hardhat major version first, then use a maintained even Node version that Hardhat supports (today that typically means an LTS even version). [3]
Sources
[1] https://hardhat.org/docs/reference/nodejs-support
[2] https://hardhat.org/docs/reference/nodejs-support.md
[3] https://v2.hardhat.org/hardhat-runner/docs/reference/stability-guarantees
🌐 Web query:
Node.js 22 compatibility issues Hardhat
💡 Result:
Common Node.js 22 + Hardhat compatibility issues (and fixes):
- Hardhat v2 prints “Node.js v22 is not supported”
- Cause: you’re on an older Hardhat v2 that didn’t yet whitelist Node 22.
- Fix: upgrade Hardhat v2 (the warning goes away once you’re on a newer v2 release). (ethereum.stackexchange.com)
- Hardhat 3 requires a minimum Node 22 patch level
- Hardhat 3 supports Node.js ≥ v22.10.0 (and also supports newer even majors while maintained). If you’re on early Node 22 (e.g., 22.0.0), you can hit warnings/errors—upgrade Node within v22. (hardhat.org)
- Hardhat’s Node support policy can make “odd” versions warn
- Hardhat targets supported even-numbered Node releases (Current / Active LTS / Maintenance), and warns once a Node line is out of its support window. (hardhat.org)
Quick checklist to resolve most reports:
- Ensure you’re using a local Hardhat install (not global). (hardhat.org)
- If staying on Hardhat v2: update
hardhatto a recent v2. - If moving to Hardhat v3: use Node ≥ 22.10.0 (e.g., via
nvm install 22.11.0andnvm use 22.11.0). (hardhat.org)
If you paste your hardhat version, Node version (node -v), and the exact warning/error text, I can tell you which bucket you’re in and the minimal upgrade path.
Citations:
- 1: https://ethereum.stackexchange.com/questions/167982/unsupported-nodejs-version-when-deploying-contracts-using-hardhat?utm_source=openai
- 2: https://hardhat.org/docs/reference/nodejs-support?utm_source=openai
- 3: https://hardhat.org/nodejs-versions?utm_source=openai
- 4: https://hardhat.org/docs/reference/errors/?utm_source=openai
- 5: https://hardhat.org/docs/reference/nodejs-support?utm_source=openai
Update step name to match Node.js version.
The step name "Use Node.js 18" should be updated to "Use Node.js 22" for clarity, since the configured version is 22.18.0.
Note: Node.js 22.18.0 is fully supported by Hardhat v3 (which requires ≥ 22.10.0) and @nomicfoundation/hardhat-verify, so no compatibility concerns exist.
🧰 Tools
🪛 actionlint (1.7.10)
13-13: the runner of "actions/setup-node@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
In @.github/workflows/hardhat.yml around lines 12 - 15, Update the GitHub
Actions step name to match the configured Node.js version: change the step title
"Use Node.js 18" to "Use Node.js 22" in the workflow step that uses
actions/setup-node@v3 with node-version: 22.18.0 so the label accurately
reflects the Node runtime being installed.
1 participant
This pull request primarily updates the deployment and upgrade instructions in the
README.mdto add support for Hardhat Ignition, and removes several OpenZeppelin contract artifacts from theartifactsdirectory. The documentation changes provide clearer, more comprehensive guidance for deploying and upgrading contracts across multiple EVM chains, while the artifact removals help clean up the repository.Documentation improvements:
README.mdto include detailed steps for using Hardhat Ignition, supporting both parameter files and inline parameters, and providing examples for upgrading across all EVM chains and testnets. Also clarified legacy script usage and improved Tron network instructions. [1] [2]Repository cleanup:
artifactsdirectory, includingOwnableUpgradeable,Ownable2StepUpgradeable,Initializable,PausableUpgradeable,AddressUpgradeable, andContextUpgradeableJSON files, as well as the debug files for these and the ERC20 contract. [1] [2] [3] [4] [5] [6] [7] [8]- Add GatewayUpgrade module for upgrading Gateway proxy contractsDescription
References
closes #75
closes #74
Testing
Checklist
mainBy submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.
Summary by CodeRabbit
New Features
Documentation
Infrastructure
Chores
✏️ Tip: You can customize this high-level summary in your review settings.