Deploy network megaeth #1473
Draft
Deploy network megaeth #1473
Conversation
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
Contributor
WalkthroughAdds a new network "megaeth" across configs, periphery whitelists, deployments and deployment manifests, foundry endpoints, and deployment target state; updates Composer Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested labels
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
config/whitelist.json (1)
6354-6407: Confirm scope: GasZipPeriphery intentionally omitted for megaeth?Several networks include GasZipPeriphery; if megaeth will support it, consider adding now to avoid follow-up PRs. If not in scope, ignore.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (7)
config/networks.json(1 hunks)config/permit2Proxy.json(1 hunks)config/whitelist.json(1 hunks)deployments/_deployments_log_file.json(2 hunks)deployments/megaeth.json(1 hunks)foundry.toml(2 hunks)script/deploy/_targetState.json(1 hunks)
🧰 Additional context used
🧠 Learnings (56)
📓 Common learnings
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1334
File: deployments/mainnet.json:54-54
Timestamp: 2025-08-26T02:20:52.515Z
Learning: For deployment PRs in the lifinance/contracts repository, carefully verify the specific scope mentioned in the PR title and description before suggesting updates to other networks. Not all deployments are cross-network updates - some are targeted to specific chains only.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/scroll.diamond.json:111-111
Timestamp: 2024-11-26T01:03:43.597Z
Learning: When reviewing pull requests, only point out missing contract addresses in `deployments/<network>.diamond.json` if the contract's address is present in `deployments/<network>.json` but missing in `deployments/<network>.diamond.json`. If the contract is not deployed on a network (i.e., not present in `deployments/<network>.json`), then no action is needed.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1168
File: script/deploy/_targetState.json:1564-1589
Timestamp: 2025-05-27T12:36:26.987Z
Learning: When reviewing deployment PRs in the lifinance/contracts repository, target state configuration files (like script/deploy/_targetState.json) may be updated for multiple networks even when the PR is focused on deploying to a specific network. The scope should be determined by the PR title and description, not just by all configuration changes present in the files.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-04T09:10:17.997Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1388
File: deployments/hyperevm.diamond.json:72-75
Timestamp: 2025-09-22T00:52:26.172Z
Learning: In diamond configuration files (deployments/*.diamond.json), it's acceptable to have multiple versions of the same facet (e.g., GlacisFacet v1.0.0 and v1.1.0) deployed at different contract addresses. This is intentional design for version coexistence, gradual migration, or backward compatibility purposes.
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/_targetState.json:1364-1390
Timestamp: 2024-11-21T08:25:26.214Z
Learning: For the Cronos network configuration in `script/deploy/_targetState.json`, the absence of bridge facets such as `StargateFacet`, `AcrossFacet`, `HopFacet`, and `SymbiosisFacet` is acceptable and expected.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1196
File: script/helperFunctions.sh:1447-1462
Timestamp: 2025-06-19T06:23:47.848Z
Learning: 0xDEnYO prefers to keep eval usage in local bash scripts when the security risk is acceptable in their controlled environment, prioritizing simplicity over security hardening for local tooling.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1266
File: script/deploy/safe/execute-pending-timelock-tx.ts:627-628
Timestamp: 2025-07-17T04:21:26.825Z
Learning: In the lifinance/contracts repository, 0xDEnYO prefers to keep '0x0' as a fallback address in gas estimation calls rather than throwing errors when the wallet account address is not available, prioritizing code simplicity over strict validation.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1325
File: script/tasks/diamondSyncDEXs.sh:116-116
Timestamp: 2025-08-27T08:45:59.606Z
Learning: In script/tasks/diamondSyncDEXs.sh, user 0xDEnYO has chosen to selectively apply ShellCheck fixes, keeping array assignments using $() construct and other patterns as-is in their controlled deployment environment, prioritizing functionality over strict ShellCheck compliance.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1212
File: .github/workflows/convertForkedPRsToInternal.yml:81-106
Timestamp: 2025-07-16T06:18:02.682Z
Learning: 0xDEnYO prefers to use printf "%q" for shell escaping in GitHub workflows to increase security and protection from potential injections, even when it might cause formatting issues, prioritizing security over convenience.
📚 Learning: 2025-07-04T08:59:08.108Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Applied to files:
script/deploy/_targetState.jsondeployments/_deployments_log_file.json
📚 Learning: 2024-11-21T08:24:53.059Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/_targetState.json:1453-1483
Timestamp: 2024-11-21T08:24:53.059Z
Learning: In `script/deploy/_targetState.json`, for the `abstract` network configuration, `ReceiverStargateV2` is correctly set to version `1.0.1`.
Applied to files:
script/deploy/_targetState.json
📚 Learning: 2025-08-07T10:20:01.383Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Applied to files:
script/deploy/_targetState.jsondeployments/_deployments_log_file.json
📚 Learning: 2025-09-22T00:52:26.172Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1388
File: deployments/hyperevm.diamond.json:72-75
Timestamp: 2025-09-22T00:52:26.172Z
Learning: In diamond configuration files (deployments/*.diamond.json), it's acceptable to have multiple versions of the same facet (e.g., GlacisFacet v1.0.0 and v1.1.0) deployed at different contract addresses. This is intentional design for version coexistence, gradual migration, or backward compatibility purposes.
Applied to files:
script/deploy/_targetState.jsondeployments/megaeth.jsondeployments/_deployments_log_file.json
📚 Learning: 2025-09-09T10:39:26.383Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.
Applied to files:
script/deploy/_targetState.jsondeployments/megaeth.jsondeployments/_deployments_log_file.json
📚 Learning: 2025-09-01T09:35:29.886Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1299
File: deployments/arbitrum.staging.json:59-61
Timestamp: 2025-09-01T09:35:29.886Z
Learning: 0xDEnYO has repeatedly emphasized that the target state file (script/deploy/_targetState.json) should NEVER be reviewed, verified, or mentioned in deployment PRs. This instruction has been given multiple times and must be strictly followed without exception.
Applied to files:
script/deploy/_targetState.json
📚 Learning: 2024-11-26T01:01:18.499Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/arbitrum.diamond.json:148-150
Timestamp: 2024-11-26T01:01:18.499Z
Learning: In `deployments/*.diamond.json` configuration files, facets that are part of an open PR and not yet merged into the main branch may have missing `Name` and `Version` fields.
Applied to files:
script/deploy/_targetState.json
📚 Learning: 2025-08-01T05:35:21.121Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1290
File: script/deploy/_targetState.json:20-31
Timestamp: 2025-08-01T05:35:21.121Z
Learning: 0xDEnYO has confirmed that the target state file (script/deploy/_targetState.json) is not important for verification and should not be reviewed in deployment PRs.
Applied to files:
script/deploy/_targetState.json
📚 Learning: 2024-09-27T07:10:15.586Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/polygon.diamond.json:4-11
Timestamp: 2024-09-27T07:10:15.586Z
Learning: In `deployments/polygon.diamond.json`, it's acceptable for certain facets to have empty names and versions when specified by the developer.
Applied to files:
script/deploy/_targetState.jsondeployments/megaeth.jsondeployments/_deployments_log_file.json
📚 Learning: 2025-04-21T03:15:12.236Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.diamond.json:84-85
Timestamp: 2025-04-21T03:15:12.236Z
Learning: In deployment JSON files that contain "diamond" in their filename (located in the deployments folder), periphery contracts may have empty string values for their addresses. This indicates that the contract is not deployed on that particular chain and should not be flagged as an issue during code reviews.
Applied to files:
script/deploy/_targetState.jsondeployments/megaeth.json
📚 Learning: 2025-07-15T05:05:28.134Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1140
File: config/permit2Proxy.json:3-3
Timestamp: 2025-07-15T05:05:28.134Z
Learning: In config/permit2Proxy.json, the addresses represent the Permit2 contract addresses on each chain, NOT the Permit2Proxy contract addresses. These Permit2 addresses are used as constructor arguments when deploying the Permit2Proxy contract. The Permit2Proxy acts as a wrapper/proxy that interacts with the underlying Permit2 contract on each network.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2024-11-25T09:05:43.045Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/base.diamond.json:148-148
Timestamp: 2024-11-25T09:05:43.045Z
Learning: In deployment configuration files (e.g., `deployments/base.diamond.json`), empty addresses for contracts like `Permit2Proxy` may be placeholders and will be updated after approvals are released from the multisig safe.
Applied to files:
config/permit2Proxy.jsondeployments/megaeth.json
📚 Learning: 2024-11-26T01:16:48.020Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/aurora.diamond.json:75-75
Timestamp: 2024-11-26T01:16:48.020Z
Learning: On networks where the `Permit2Proxy` contract is not deployed, the `Permit2Proxy` address is intentionally left empty in the configuration files.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2025-06-25T06:27:38.873Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1140
File: deployments/fantom.diamond.json:97-105
Timestamp: 2025-06-25T06:27:38.873Z
Learning: When contracts are redeployed, they receive new addresses. Permit2Proxy addresses in deployment files reflect the actual deployed contract addresses for each network, not a standardized address across all networks.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2024-11-26T01:17:13.212Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/cronos.diamond.json:67-67
Timestamp: 2024-11-26T01:17:13.212Z
Learning: In the `deployments/cronos.diamond.json` file, the `Permit2Proxy` address is intentionally left empty because `Permit2Proxy` is not deployed on the Cronos network.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2025-02-11T10:33:52.791Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 988
File: script/deploy/facets/DeployPermit2Proxy.s.sol:33-37
Timestamp: 2025-02-11T10:33:52.791Z
Learning: The Permit2Proxy contract must not be deployed with zero addresses for its critical dependencies (LiFiDiamond, permit2Address, safeAddress). This is enforced by passing `false` to `_getConfigContractAddress` function.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2024-11-05T17:16:19.946Z
Learnt from: maxklenk
Repo: lifinance/contracts PR: 782
File: script/demoScripts/demoPermit2.ts:0-0
Timestamp: 2024-11-05T17:16:19.946Z
Learning: In `script/demoScripts/demoPermit2.ts`, the `nextNonce` function should be called on the `PERMIT2_PROXY_ADDRESS` because the nonce is stored in the proxy contract, not in the `Permit2` contract (`PERMIT2_ADDRESS`).
Applied to files:
config/permit2Proxy.json
📚 Learning: 2025-09-16T01:39:54.099Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1381
File: deployments/arbitrum.json:65-69
Timestamp: 2025-09-16T01:39:54.099Z
Learning: When verifying facet deployments across .json and .diamond.json files, search by facet name rather than trying to cross-reference addresses between the files, as the same contract can have different addresses in different deployment files.
Applied to files:
deployments/megaeth.jsondeployments/_deployments_log_file.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.
Applied to files:
deployments/megaeth.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.
Applied to files:
deployments/megaeth.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.
Applied to files:
deployments/megaeth.jsonconfig/networks.json
📚 Learning: 2025-08-28T02:21:50.428Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1340
File: config/mayan.json:18-20
Timestamp: 2025-08-28T02:21:50.428Z
Learning: In the lifinance/contracts repository, config/*.json files (like config/mayan.json) contain configuration data such as external service addresses (e.g., bridge router addresses) that are used as constructor parameters. The deployments/_deployments_log_file.json file stores information about contracts that LI.FI deployed themselves. These two types of addresses serve different purposes and will never match - config files contain external addresses while deployment logs contain LI.FI's own deployed contract addresses.
Applied to files:
deployments/megaeth.json
📚 Learning: 2025-10-10T10:56:04.861Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1413
File: src/Facets/EverclearFacet.sol:4-13
Timestamp: 2025-10-10T10:56:04.861Z
Learning: LibAllowList is only required for facets that make arbitrary external calls to DEX aggregators (e.g., GenericSwapFacetV3). Bridge facets that call specific protocol contracts (like EverclearFacet calling IEverclearFeeAdapter) do not need to import LibAllowList.
Applied to files:
deployments/megaeth.json
📚 Learning: 2025-06-13T08:30:26.220Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1207
File: deployments/_deployments_log_file.json:34037-34080
Timestamp: 2025-06-13T08:30:26.220Z
Learning: LiFiDiamond contains generic withdrawal logic, so individual facet contracts (e.g., PioneerFacet) do not need their own Ether-withdraw functions.
Applied to files:
deployments/megaeth.json
📚 Learning: 2024-11-01T11:53:57.162Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 846
File: deployments/cronos.diamond.json:28-31
Timestamp: 2024-11-01T11:53:57.162Z
Learning: In `deployments/cronos.diamond.json`, both `GenericSwapFacet` and `GenericSwapFacetV3` are distinct facets that should be included together, as they serve different purposes.
Applied to files:
deployments/megaeth.json
📚 Learning: 2025-01-21T11:04:46.116Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 937
File: config/dexs.json:95-99
Timestamp: 2025-01-21T11:04:46.116Z
Learning: In the dexs.json configuration, utility contracts (like FeeCollector, LiFuelFeeCollector, TokenWrapper) can be treated as DEX contracts since they are handled similarly in the system's logic.
Applied to files:
deployments/megaeth.jsonconfig/whitelist.json
📚 Learning: 2025-09-25T07:47:30.735Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1324
File: src/Facets/EcoFacet.sol:306-336
Timestamp: 2025-09-25T07:47:30.735Z
Learning: In EcoFacet (src/Facets/EcoFacet.sol), the team intentionally uses variable-length validation for nonEVMReceiver addresses (up to 44 bytes) to support cross-ecosystem bridging with different address formats, rather than enforcing fixed 32-byte raw pubkeys.
Applied to files:
deployments/megaeth.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 806
File: deployments/_deployments_log_file.json:5780-5793
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The owner address `0x11f11121df7256c40339393b0fb045321022ce44` and the `DiamondCutFacet` address `0xd5cf40a2a18b633cfd6a1ae16d1771596498cf83` in the `LiFiDiamond` deployment on `xlayer` are correct and should not be flagged as issues, even if they are not referenced in the Solidity files.
Applied to files:
deployments/megaeth.json
📚 Learning: 2025-01-28T14:30:06.911Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: deployments/abstract.json:2-4
Timestamp: 2025-01-28T14:30:06.911Z
Learning: In the LiFi contract architecture, "LiFiDiamond" is the diamond proxy contract that connects all facets into a cohesive system. The facets are individual contracts that provide specific functionality, and the diamond proxy delegates calls to these facets.
Applied to files:
deployments/megaeth.json
📚 Learning: 2024-11-26T01:16:27.721Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:40-43
Timestamp: 2024-11-26T01:16:27.721Z
Learning: Version inconsistencies of 'GenericSwapFacetV3' across deployment configurations are acceptable if they are only due to differences in Solidity pragma directives.
Applied to files:
deployments/megaeth.json
📚 Learning: 2025-09-15T12:33:51.069Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1377
File: deployments/_deployments_log_file.json:5607-5619
Timestamp: 2025-09-15T12:33:51.069Z
Learning: The deployments/_deployments_log_file.json is structured as network → environment → version → array of deployment records. Always understand the file hierarchy before attempting validation, and target specific paths rather than trying to validate all objects in the JSON.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-05-28T17:33:33.959Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28060-28072
Timestamp: 2025-05-28T17:33:33.959Z
Learning: Deployment log files like `deployments/_deployments_log_file.json` are historical records that document the actual versions deployed at specific times. They should not be updated to match current contract versions - they must accurately reflect what was deployed when the deployment occurred.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/_deployments_log_file.json:1914-1927
Timestamp: 2024-10-09T03:47:21.269Z
Learning: Duplicate entries in `deployments/_deployments_log_file.json` that are outdated do not require changes.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-12-04T01:59:34.045Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 832
File: deployments/_deployments_log_file.json:23712-23720
Timestamp: 2024-12-04T01:59:34.045Z
Learning: In `deployments/_deployments_log_file.json`, duplicate deployment entries for the same version and address may occur because they correspond to deployments on different networks. These entries are acceptable and should not be flagged as duplicates in future reviews.
Applied to files:
deployments/_deployments_log_file.jsonconfig/networks.json
📚 Learning: 2025-05-28T17:33:10.529Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28706-28717
Timestamp: 2025-05-28T17:33:10.529Z
Learning: Deployment log files (like `_deployments_log_file.json`) are historical records that should not be updated to match current contract versions. They should accurately reflect the versions that were actually deployed at specific timestamps.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-08-07T10:20:01.383Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-11-07T14:57:59.929Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1452
File: deployments/_deployments_log_file.json:42713-42727
Timestamp: 2025-11-07T14:57:59.929Z
Learning: In the `deployments/_deployments_log_file.json` file, the `ZK_SOLC_VERSION` field is required for all deployment entries but should be set to an empty string `""` for non-zkEVM chains.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-02-12T09:44:12.961Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 985
File: script/deploy/_targetState.json:0-0
Timestamp: 2025-02-12T09:44:12.961Z
Learning: The bsca network intentionally maintains different facet versions between staging and production environments, specifically:
1. CalldataVerificationFacet: v1.1.1 in staging vs v1.1.2 in production
2. EmergencyPauseFacet: present only in production
3. Permit2Proxy: present only in production
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-12-03T11:02:14.195Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 807
File: script/deploy/_targetState.json:181-181
Timestamp: 2024-12-03T11:02:14.195Z
Learning: HyphenFacet v1.0.0 is intentionally included in the BSC staging environment and should not be removed even if not present in production environments.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: deployments/bsc.diamond.staging.json:4-7
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In files with "staging" in their filename, such as `deployments/bsc.diamond.staging.json`, it is acceptable for facets to have empty "Name" and "Version" fields. Do not flag missing facet information in such files during reviews.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-09-04T09:26:35.060Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1344
File: src/Facets/GardenFacet.sol:124-130
Timestamp: 2025-09-04T09:26:35.060Z
Learning: In src/Facets/GardenFacet.sol, the team has decided that registry lookup validation should only check for zero addresses and not perform additional contract existence checks (like htlcAddress.code.length > 0), preferring minimal validation for Garden HTLC registry addresses.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-12-03T11:01:57.084Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 807
File: script/deploy/_targetState.json:164-164
Timestamp: 2024-12-03T11:01:57.084Z
Learning: Version differences in `CalldataVerificationFacet` between staging and production are acceptable and not an issue.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-02-21T09:05:22.118Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: test/solidity/Facets/ChainflipFacet.t.sol:269-269
Timestamp: 2025-02-21T09:05:22.118Z
Learning: Fixed gas amounts in test files (e.g., ChainflipFacet.t.sol) don't require extensive documentation or configuration as they are only used for testing purposes.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-08-27T13:47:28.646Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: src/Periphery/Lda/Facets/UniV2StyleFacet.sol:0-0
Timestamp: 2025-08-27T13:47:28.646Z
Learning: In src/Periphery/Lda/Facets/UniV2StyleFacet.sol and similar LDA facets, mirooon prefers to rely on backend validation for pool addresses rather than adding contract code-size checks in the smart contract, as pool validation occurs during payload generation and transactions would fail anyway if sent to invalid addresses.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/fuse.json:24-25
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The `LiFiDEXAggregator.sol` contract is located in `src/Periphery/`.
Applied to files:
config/whitelist.json
📚 Learning: 2025-04-22T09:04:44.244Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1112
File: deployments/soneium.diamond.json:81-81
Timestamp: 2025-04-22T09:04:44.244Z
Learning: In the lifinance/contracts repository, it's normal and expected for periphery contracts to have empty address values in deployment files when they are not deployed on a particular network. This applies to all periphery contracts including ReceiverChainflip, ReceiverStargateV2, and others. PRs should not flag empty periphery contract addresses as issues.
Applied to files:
config/whitelist.json
📚 Learning: 2024-11-21T08:39:29.530Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/dexs.json:748-752
Timestamp: 2024-11-21T08:39:29.530Z
Learning: In the 'worldchain' network, the addresses `0x50D5a8aCFAe13Dceb217E9a071F6c6Bd5bDB4155`, `0x8f023b4193a6b18C227B4a755f8e28B3D30Ef9a1`, and `0x603a538477d44064eA5A5d8C345b4Ff6fca1142a` are used as DEXs and should be included in `config/dexs.json`.
Applied to files:
config/whitelist.jsonconfig/networks.json
📚 Learning: 2024-10-04T09:01:56.514Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/base.diamond.json:123-123
Timestamp: 2024-10-04T09:01:56.514Z
Learning: In the `lifinance/contracts` repository, it's acceptable to retain references to the old `LiFuelFeeCollector` address (`0xc4f7A34b8d283f66925eF0f5CCdFC2AF3030DeaE`) in deployment files when updating them is not necessary.
Applied to files:
config/whitelist.json
📚 Learning: 2025-07-17T11:31:50.058Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: config/networks.json:837-839
Timestamp: 2025-07-17T11:31:50.058Z
Learning: In config/networks.json for the Ronin network (chainId 2020), there is a problematic mismatch between verificationType ("blockscout") and explorerApiUrl ("https://sourcify.roninchain.com/server"). This inconsistency can lead to verification issues and should be flagged when networks.json is modified in future PRs.
Applied to files:
config/networks.json
📚 Learning: 2024-11-21T08:34:30.300Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/global.json:146-146
Timestamp: 2024-11-21T08:34:30.300Z
Learning: The project is deprecating `safeAddresses` and `safeApiUrls` in `global.json` and moving these configurations to `config/networks.json` for network configurations.
Applied to files:
config/networks.json
📚 Learning: 2025-08-28T02:02:56.965Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1136
File: config/dexs.json:0-0
Timestamp: 2025-08-28T02:02:56.965Z
Learning: Different networks in config/dexs.json naturally and appropriately have different DEX addresses. Do not flag different addresses across different networks as issues - only flag if the same network's addresses appear to have changed unintentionally between branches.
Applied to files:
config/networks.json
📚 Learning: 2024-10-08T07:14:52.296Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 825
File: config/networks.json:462-462
Timestamp: 2024-10-08T07:14:52.296Z
Learning: In the `networks.json` file and related configuration files, when updating the `name` property of a network (e.g., from `Scroll` to `zkScroll`), the key of the network object should remain unchanged (e.g., `'scroll'`) to ensure it matches references elsewhere in the codebase.
Applied to files:
config/networks.json
📚 Learning: 2024-11-21T08:24:05.881Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/safe/add-owners-to-safe.ts:8-13
Timestamp: 2024-11-21T08:24:05.881Z
Learning: In `script/deploy/safe/add-owners-to-safe.ts`, validation for network configuration when casting imported JSON data to `NetworksObject` is not required as per the user's preference.
Applied to files:
config/networks.json
📚 Learning: 2024-11-22T08:50:28.878Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 827
File: config/networks.json:448-448
Timestamp: 2024-11-22T08:50:28.878Z
Learning: In `config/networks.json`, Safe addresses (`safeAddress` fields) do not need to be verified, as they are handled separately.
Applied to files:
config/networks.json
📚 Learning: 2024-11-18T07:19:28.651Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 858
File: config/networks.json:17-17
Timestamp: 2024-11-18T07:19:28.651Z
Learning: In the `config/networks.json` file, it's expected that the `safeWebUrl` field may have different formats and URLs across networks; standardizing them is not desired.
Applied to files:
config/networks.json
🪛 Gitleaks (8.29.0)
deployments/megaeth.json
[high] 2-2: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 21-21: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
⏰ 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). (1)
- GitHub Check: run-unit-tests
🔇 Additional comments (6)
config/permit2Proxy.json (1)
35-35: Verify the Permit2 contract address for megaeth (chainId 4326).The address
0x000000000022D473030F116dDEE9F6B43aC78BA3matches the standard Permit2 address used across most networks, but confirm this is the actual Permit2 contract address deployed on megaeth (chainId 4326).foundry.toml (2)
71-71: Verify ETH_NODE_URI_MEGAETH environment variable is configured.The RPC endpoint relies on the
ETH_NODE_URI_MEGAETHenvironment variable. Ensure this is set in all CI/CD environments, deployment scripts, and documented for developers.
142-142: The testnet URL is correct—MegaETH is testnet-only.MegaETH currently has no mainnet; it's a Layer 2 solution with a public testnet (megaeth-testnet-v3) and mainnet expected in late 2025. The Blockscout URL correctly references the current testnet environment, which is the appropriate target for this initial deployment configuration.
However, the actual critical concern is the unchecked security review checklist—all reviewer items remain unchecked, including those marked "DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!". Ensure the mandatory security reviews (arbitrary contract calls, privileged calls, audit requirements) are completed and confirmed before proceeding with any deployment.
Likely an incorrect or invalid review comment.
deployments/_deployments_log_file.json (1)
42734-42768: Verify whether PR deployment scope includes megaeth deployments in the log file.Based on verification of the deployment log file:
- ✓ JSON structure is valid and the UnitFacet restructuring (top-level → nested network/environment hierarchy) has been successfully applied
- ✓ UnitFacet now contains: plasma → staging → 1.0.0 (one deployment record)
- ✗ megaeth is completely absent from the entire deployment log file—no facet or contract has megaeth entries
Key concern: The PR title states "Deploy network megaeth new" and the visible code shows deployments being added for xlayer and moonriver networks. However, megaeth has no entries anywhere in the file. This suggests either:
- The PR is incomplete and megaeth deployment records should be added to the log file
- megaeth deployments are intended for other configuration files and this log update is out of scope
Additional verification needed:
- Confirm whether UnitFacet's data loss is intentional (the original top-level structure appears to have been completely replaced with only plasma staging data)
- Clarify the intended scope: should megaeth deployment entries be added to this log file as part of this PR?
config/whitelist.json (2)
6354-6407: Megaeth periphery whitelist looks consistent.Addresses and selectors mirror existing network patterns; function signatures map to the expected 4-byte selectors. No structural issues spotted.
6354-6407: Verify selector and checksum values in your local environment.Function signatures in the source code match the whitelist declarations exactly:
FeeCollector:collectNativeFees(uint256,uint256,address)andcollectTokenFees(address,uint256,uint256,address)✓FeeForwarder:forwardNativeFees((address,uint256)[])andforwardERC20Fees(address,(address,uint256)[])✓TokenWrapper:deposit()andwithdraw()✓LiFiDEXAggregator:processRoute(address,uint256,address,uint256,address,bytes)✓The provided verification script cannot execute in this environment due to missing keccak256 libraries. Run the script locally to validate the 4-byte selectors and EIP-55 checksums for the four megaeth entries before merging. Since megaeth is a newly launched network (testnet March 2025), public verification via block explorers is not yet available.
…-network-megaeth-new
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
deployments/_deployments_log_file.json (1)
1-46519: PR is not ready for review – Draft status with incomplete checklists and security requirements unaddressed.The PR remains in Draft state with all pre-review and reviewer checklists unchecked. Critically, the reviewer checklist explicitly states "DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!" and requires:
- Verification of external contract call validation/restriction
- Verification of privileged call validation/restriction
- Minimum 1 preliminary audit conducted on [date] by [company/auditor]
All megaeth entries show
VERIFIED: "false", which conflicts with the audit requirement. Additionally, the "Why did I implement it this way?" section is empty.Before requesting review, please complete the pre-review checklist and ensure audit/verification requirements are met.
♻️ Duplicate comments (1)
config/networks.json (1)
698-698: 🔴 Critical: RPC URL placeholder must be replaced before deployment.Line 698 contains a TODO placeholder for the rpcUrl that must be updated with a valid mainnet RPC endpoint. This blocks all network interactions and is a hard blocker for deployment.
- "rpcUrl": "TODO: UPDATE ONCE MAINNET IS LIVE <<<<<<<<<<<<<<<<<<<<---------------------------------------- !!!!!!!!! TODO", + "rpcUrl": "https://megaeth.example.com", // Replace with actual mainnet RPC endpoint
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (10)
config/composerWhitelist.json(21 hunks)config/gaszip.json(1 hunks)config/networks.json(1 hunks)config/permit2Proxy.json(1 hunks)config/whitelist.json(21 hunks)deployments/_deployments_log_file.json(23 hunks)deployments/megaeth.diamond.json(1 hunks)deployments/megaeth.json(1 hunks)foundry.toml(2 hunks)script/deploy/_targetState.json(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- config/gaszip.json
- deployments/megaeth.json
🚧 Files skipped from review as they are similar to previous changes (2)
- script/deploy/_targetState.json
- foundry.toml
🧰 Additional context used
🧠 Learnings (62)
📓 Common learnings
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1334
File: deployments/mainnet.json:54-54
Timestamp: 2025-08-26T02:20:52.515Z
Learning: For deployment PRs in the lifinance/contracts repository, carefully verify the specific scope mentioned in the PR title and description before suggesting updates to other networks. Not all deployments are cross-network updates - some are targeted to specific chains only.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1168
File: script/deploy/_targetState.json:1564-1589
Timestamp: 2025-05-27T12:36:26.987Z
Learning: When reviewing deployment PRs in the lifinance/contracts repository, target state configuration files (like script/deploy/_targetState.json) may be updated for multiple networks even when the PR is focused on deploying to a specific network. The scope should be determined by the PR title and description, not just by all configuration changes present in the files.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/scroll.diamond.json:111-111
Timestamp: 2024-11-26T01:03:43.597Z
Learning: When reviewing pull requests, only point out missing contract addresses in `deployments/<network>.diamond.json` if the contract's address is present in `deployments/<network>.json` but missing in `deployments/<network>.diamond.json`. If the contract is not deployed on a network (i.e., not present in `deployments/<network>.json`), then no action is needed.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-04T09:10:17.997Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/blast.json:27-27
Timestamp: 2024-10-04T09:06:19.927Z
Learning: Audit references for older contracts deployed over 2 months ago, including `LiFiDEXAggregator.sol`, will be added early next year (estimated).
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 994
File: script/config.example.sh:107-108
Timestamp: 2025-02-13T03:07:05.721Z
Learning: The DEPLOY_NEW_NETWORK_MODE flag in deployment scripts is required during initial contract deployment because ownership hasn't been transferred to SAFE yet. This mode allows direct execution of diamondCut and registerPeriphery transactions by the deployer.
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to script/deploy/targetState.json : targetState.json in script/deploy/ must track contract versions and deployments across networks using network and environment keys
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1196
File: script/helperFunctions.sh:1447-1462
Timestamp: 2025-06-19T06:23:47.848Z
Learning: 0xDEnYO prefers to keep eval usage in local bash scripts when the security risk is acceptable in their controlled environment, prioritizing simplicity over security hardening for local tooling.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1266
File: script/deploy/safe/execute-pending-timelock-tx.ts:627-628
Timestamp: 2025-07-17T04:21:26.825Z
Learning: In the lifinance/contracts repository, 0xDEnYO prefers to keep '0x0' as a fallback address in gas estimation calls rather than throwing errors when the wallet account address is not available, prioritizing code simplicity over strict validation.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1325
File: script/tasks/diamondSyncDEXs.sh:116-116
Timestamp: 2025-08-27T08:45:59.606Z
Learning: In script/tasks/diamondSyncDEXs.sh, user 0xDEnYO has chosen to selectively apply ShellCheck fixes, keeping array assignments using $() construct and other patterns as-is in their controlled deployment environment, prioritizing functionality over strict ShellCheck compliance.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1212
File: .github/workflows/convertForkedPRsToInternal.yml:81-106
Timestamp: 2025-07-16T06:18:02.682Z
Learning: 0xDEnYO prefers to use printf "%q" for shell escaping in GitHub workflows to increase security and protection from potential injections, even when it might cause formatting issues, prioritizing security over convenience.
📚 Learning: 2025-07-15T05:05:28.134Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1140
File: config/permit2Proxy.json:3-3
Timestamp: 2025-07-15T05:05:28.134Z
Learning: In config/permit2Proxy.json, the addresses represent the Permit2 contract addresses on each chain, NOT the Permit2Proxy contract addresses. These Permit2 addresses are used as constructor arguments when deploying the Permit2Proxy contract. The Permit2Proxy acts as a wrapper/proxy that interacts with the underlying Permit2 contract on each network.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2024-11-25T09:05:43.045Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/base.diamond.json:148-148
Timestamp: 2024-11-25T09:05:43.045Z
Learning: In deployment configuration files (e.g., `deployments/base.diamond.json`), empty addresses for contracts like `Permit2Proxy` may be placeholders and will be updated after approvals are released from the multisig safe.
Applied to files:
config/permit2Proxy.jsonconfig/networks.json
📚 Learning: 2024-11-26T01:16:48.020Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/aurora.diamond.json:75-75
Timestamp: 2024-11-26T01:16:48.020Z
Learning: On networks where the `Permit2Proxy` contract is not deployed, the `Permit2Proxy` address is intentionally left empty in the configuration files.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2024-11-26T01:17:13.212Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/cronos.diamond.json:67-67
Timestamp: 2024-11-26T01:17:13.212Z
Learning: In the `deployments/cronos.diamond.json` file, the `Permit2Proxy` address is intentionally left empty because `Permit2Proxy` is not deployed on the Cronos network.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2025-06-25T06:27:38.873Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1140
File: deployments/fantom.diamond.json:97-105
Timestamp: 2025-06-25T06:27:38.873Z
Learning: When contracts are redeployed, they receive new addresses. Permit2Proxy addresses in deployment files reflect the actual deployed contract addresses for each network, not a standardized address across all networks.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2025-02-11T10:33:52.791Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 988
File: script/deploy/facets/DeployPermit2Proxy.s.sol:33-37
Timestamp: 2025-02-11T10:33:52.791Z
Learning: The Permit2Proxy contract must not be deployed with zero addresses for its critical dependencies (LiFiDiamond, permit2Address, safeAddress). This is enforced by passing `false` to `_getConfigContractAddress` function.
Applied to files:
config/permit2Proxy.json
📚 Learning: 2024-11-05T17:16:19.946Z
Learnt from: maxklenk
Repo: lifinance/contracts PR: 782
File: script/demoScripts/demoPermit2.ts:0-0
Timestamp: 2024-11-05T17:16:19.946Z
Learning: In `script/demoScripts/demoPermit2.ts`, the `nextNonce` function should be called on the `PERMIT2_PROXY_ADDRESS` because the nonce is stored in the proxy contract, not in the `Permit2` contract (`PERMIT2_ADDRESS`).
Applied to files:
config/permit2Proxy.json
📚 Learning: 2025-09-09T10:39:26.383Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.json
📚 Learning: 2025-08-07T10:20:01.383Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-08-07T10:20:01.383Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-05-28T17:33:33.959Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28060-28072
Timestamp: 2025-05-28T17:33:33.959Z
Learning: Deployment log files like `deployments/_deployments_log_file.json` are historical records that document the actual versions deployed at specific times. They should not be updated to match current contract versions - they must accurately reflect what was deployed when the deployment occurred.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-07-04T08:59:08.108Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-09-15T12:33:51.069Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1377
File: deployments/_deployments_log_file.json:5607-5619
Timestamp: 2025-09-15T12:33:51.069Z
Learning: The deployments/_deployments_log_file.json is structured as network → environment → version → array of deployment records. Always understand the file hierarchy before attempting validation, and target specific paths rather than trying to validate all objects in the JSON.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-05-28T17:33:10.529Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28706-28717
Timestamp: 2025-05-28T17:33:10.529Z
Learning: Deployment log files (like `_deployments_log_file.json`) are historical records that should not be updated to match current contract versions. They should accurately reflect the versions that were actually deployed at specific timestamps.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-04-28T10:33:48.525Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1123
File: deployments/polygon.diamond.json:124-127
Timestamp: 2025-04-28T10:33:48.525Z
Learning: In the lifinance/contracts repository, deployment environments are distinguished by filename patterns. Production deployments use standard names like "polygon.diamond.json", while staging deployments use names with "staging" suffix like "polygon.diamond.staging.json". When checking deployment logs for consistency, ensure to look in the correct environment section (production/staging) based on the filename pattern.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-04-21T03:15:12.236Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.diamond.json:84-85
Timestamp: 2025-04-21T03:15:12.236Z
Learning: In deployment JSON files that contain "diamond" in their filename (located in the deployments folder), periphery contracts may have empty string values for their addresses. This indicates that the contract is not deployed on that particular chain and should not be flagged as an issue during code reviews.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.json
📚 Learning: 2024-09-27T07:10:15.586Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/polygon.diamond.json:4-11
Timestamp: 2024-09-27T07:10:15.586Z
Learning: In `deployments/polygon.diamond.json`, it's acceptable for certain facets to have empty names and versions when specified by the developer.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 806
File: deployments/_deployments_log_file.json:5780-5793
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The owner address `0x11f11121df7256c40339393b0fb045321022ce44` and the `DiamondCutFacet` address `0xd5cf40a2a18b633cfd6a1ae16d1771596498cf83` in the `LiFiDiamond` deployment on `xlayer` are correct and should not be flagged as issues, even if they are not referenced in the Solidity files.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.json
📚 Learning: 2025-09-22T00:52:26.172Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1388
File: deployments/hyperevm.diamond.json:72-75
Timestamp: 2025-09-22T00:52:26.172Z
Learning: In diamond configuration files (deployments/*.diamond.json), it's acceptable to have multiple versions of the same facet (e.g., GlacisFacet v1.0.0 and v1.1.0) deployed at different contract addresses. This is intentional design for version coexistence, gradual migration, or backward compatibility purposes.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.json
📚 Learning: 2024-11-21T08:39:29.530Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/dexs.json:748-752
Timestamp: 2024-11-21T08:39:29.530Z
Learning: In the 'worldchain' network, the addresses `0x50D5a8aCFAe13Dceb217E9a071F6c6Bd5bDB4155`, `0x8f023b4193a6b18C227B4a755f8e28B3D30Ef9a1`, and `0x603a538477d44064eA5A5d8C345b4Ff6fca1142a` are used as DEXs and should be included in `config/dexs.json`.
Applied to files:
deployments/_deployments_log_file.jsonconfig/networks.jsonconfig/whitelist.json
📚 Learning: 2025-11-13T06:58:47.547Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1464
File: src/Facets/DexManagerFacet.sol:44-68
Timestamp: 2025-11-13T06:58:47.547Z
Learning: The DexManagerFacet in src/Facets/DexManagerFacet.sol is planned for deprecation soon and should be kept as-is without further improvements or modifications.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-01-21T11:04:46.116Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 937
File: config/dexs.json:95-99
Timestamp: 2025-01-21T11:04:46.116Z
Learning: In the dexs.json configuration, utility contracts (like FeeCollector, LiFuelFeeCollector, TokenWrapper) can be treated as DEX contracts since they are handled similarly in the system's logic.
Applied to files:
deployments/_deployments_log_file.jsonconfig/whitelist.json
📚 Learning: 2024-11-26T01:16:27.721Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:40-43
Timestamp: 2024-11-26T01:16:27.721Z
Learning: Version inconsistencies of 'GenericSwapFacetV3' across deployment configurations are acceptable if they are only due to differences in Solidity pragma directives.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-06-13T08:30:26.220Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1207
File: deployments/_deployments_log_file.json:34037-34080
Timestamp: 2025-06-13T08:30:26.220Z
Learning: LiFiDiamond contains generic withdrawal logic, so individual facet contracts (e.g., PioneerFacet) do not need their own Ether-withdraw functions.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.json
📚 Learning: 2025-02-12T09:44:12.961Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 985
File: script/deploy/_targetState.json:0-0
Timestamp: 2025-02-12T09:44:12.961Z
Learning: The bsca network intentionally maintains different facet versions between staging and production environments, specifically:
1. CalldataVerificationFacet: v1.1.1 in staging vs v1.1.2 in production
2. EmergencyPauseFacet: present only in production
3. Permit2Proxy: present only in production
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-09-04T09:26:35.060Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1344
File: src/Facets/GardenFacet.sol:124-130
Timestamp: 2025-09-04T09:26:35.060Z
Learning: In src/Facets/GardenFacet.sol, the team has decided that registry lookup validation should only check for zero addresses and not perform additional contract existence checks (like htlcAddress.code.length > 0), preferring minimal validation for Garden HTLC registry addresses.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.
Applied to files:
deployments/_deployments_log_file.jsondeployments/megaeth.diamond.jsonconfig/networks.json
📚 Learning: 2024-10-04T09:01:56.514Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/base.diamond.json:123-123
Timestamp: 2024-10-04T09:01:56.514Z
Learning: In the `lifinance/contracts` repository, it's acceptable to retain references to the old `LiFuelFeeCollector` address (`0xc4f7A34b8d283f66925eF0f5CCdFC2AF3030DeaE`) in deployment files when updating them is not necessary.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-10-09T07:06:25.731Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 829
File: deployments/optimism.diamond.staging.json:4-7
Timestamp: 2024-10-09T07:06:25.731Z
Learning: In `src/Facets/EmergencyPauseFacet.sol`, the `emergencyPause` and `emergencyUnpause` functions are correctly implemented and present.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: src/Periphery/GasZipPeriphery.sol:4-14
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In `GasZipPeriphery.sol`, `LibUtil` and `Validatable` are used, so ensure not to suggest their removal in future reviews.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-09-24T04:37:26.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1389
File: config/gaszip.json:22-22
Timestamp: 2025-09-24T04:37:26.443Z
Learning: 0xDEnYO has direct knowledge of GasZip router deployments that may not be reflected in public documentation yet. When reviewing GasZip configurations in the lifinance/contracts repository, trust 0xDEnYO's assertions about router availability even if not publicly documented, as they have been verified to be accurate.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-09-24T04:37:26.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1389
File: config/gaszip.json:22-22
Timestamp: 2025-09-24T04:37:26.443Z
Learning: 0xDEnYO has direct knowledge of GasZip router deployments that may not be reflected in public documentation yet. When reviewing GasZip configurations in the lifinance/contracts repository, trust 0xDEnYO's assertions about router availability even if not publicly documented.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-05-29T09:40:46.846Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1171
File: config/gaszip.json:27-27
Timestamp: 2025-05-29T09:40:46.846Z
Learning: GasZipPeriphery deployment depends on having a safeAddress available in the network configuration. If safeAddress is empty, GasZipPeriphery deployment should be deferred until the Safe multisig address is set up for the network.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-11-25T01:36:33.521Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to test/solidity/**/*.t.sol : Test contracts for facets requiring whitelist functionality should inherit from TestWhitelistManagerBase
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2025-05-14T15:19:24.984Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1137
File: src/Periphery/GasZipPeriphery.sol:62-71
Timestamp: 2025-05-14T15:19:24.984Z
Learning: The syntax `bytes4(calldata_bytes[:4])` is valid in Solidity 0.8.x for extracting a function selector from calldata bytes.
Applied to files:
config/composerWhitelist.jsonconfig/whitelist.json
📚 Learning: 2025-09-16T01:39:54.099Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1381
File: deployments/arbitrum.json:65-69
Timestamp: 2025-09-16T01:39:54.099Z
Learning: When verifying facet deployments across .json and .diamond.json files, search by facet name rather than trying to cross-reference addresses between the files, as the same contract can have different addresses in different deployment files.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2024-11-26T01:01:18.499Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/arbitrum.diamond.json:148-150
Timestamp: 2024-11-26T01:01:18.499Z
Learning: In `deployments/*.diamond.json` configuration files, facets that are part of an open PR and not yet merged into the main branch may have missing `Name` and `Version` fields.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2024-11-26T01:04:16.637Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/fantom.diamond.json:92-94
Timestamp: 2024-11-26T01:04:16.637Z
Learning: In `deployments/*.diamond.json` files, it's acceptable for facets to have empty `Name` and `Version` fields, and these should not be flagged as issues.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2025-01-28T14:30:06.911Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: deployments/abstract.json:2-4
Timestamp: 2025-01-28T14:30:06.911Z
Learning: In the LiFi contract architecture, "LiFiDiamond" is the diamond proxy contract that connects all facets into a cohesive system. The facets are individual contracts that provide specific functionality, and the diamond proxy delegates calls to these facets.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/fuse.json:24-25
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The `LiFiDEXAggregator.sol` contract is located in `src/Periphery/`.
Applied to files:
deployments/megaeth.diamond.jsonconfig/whitelist.json
📚 Learning: 2025-11-25T01:36:33.521Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to src/Facets/**/*.sol : Facets must inherit from ILiFi interface, use LibAsset and LibSwap libraries, include ReentrancyGuard and SwapperV2, and implement Validatable interface
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2025-11-25T01:36:33.521Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to src/Facets/**/*.sol : Diamond facets must reside in src/Facets/ directory with names including 'Facet'
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2025-08-27T13:07:58.254Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: src/Periphery/Lda/Facets/CurveFacet.sol:0-0
Timestamp: 2025-08-27T13:07:58.254Z
Learning: In the LiFi contracts codebase, ICurveLegacy interface is defined inline in src/Periphery/LiFiDEXAggregator.sol with a non-payable exchange function. The CurveFacet diff shows importing it from a separate file that doesn't exist, creating a compilation issue.
Applied to files:
deployments/megaeth.diamond.json
📚 Learning: 2025-07-17T11:31:50.058Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: config/networks.json:837-839
Timestamp: 2025-07-17T11:31:50.058Z
Learning: In config/networks.json for the Ronin network (chainId 2020), there is a problematic mismatch between verificationType ("blockscout") and explorerApiUrl ("https://sourcify.roninchain.com/server"). This inconsistency can lead to verification issues and should be flagged when networks.json is modified in future PRs.
Applied to files:
config/networks.json
📚 Learning: 2024-11-21T08:34:30.300Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/global.json:146-146
Timestamp: 2024-11-21T08:34:30.300Z
Learning: The project is deprecating `safeAddresses` and `safeApiUrls` in `global.json` and moving these configurations to `config/networks.json` for network configurations.
Applied to files:
config/networks.json
📚 Learning: 2025-08-28T02:02:56.965Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1136
File: config/dexs.json:0-0
Timestamp: 2025-08-28T02:02:56.965Z
Learning: Different networks in config/dexs.json naturally and appropriately have different DEX addresses. Do not flag different addresses across different networks as issues - only flag if the same network's addresses appear to have changed unintentionally between branches.
Applied to files:
config/networks.json
📚 Learning: 2024-11-21T08:24:05.881Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/safe/add-owners-to-safe.ts:8-13
Timestamp: 2024-11-21T08:24:05.881Z
Learning: In `script/deploy/safe/add-owners-to-safe.ts`, validation for network configuration when casting imported JSON data to `NetworksObject` is not required as per the user's preference.
Applied to files:
config/networks.json
📚 Learning: 2024-10-11T22:01:09.826Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 825
File: config/networks.json:462-462
Timestamp: 2024-10-11T22:01:09.826Z
Learning: In the `networks.json` file and related configuration files, when updating the `name` property of a network (e.g., from `Scroll` to `zkScroll`), the key of the network object should remain unchanged (e.g., `'scroll'`) to ensure it matches references elsewhere in the codebase.
Applied to files:
config/networks.json
📚 Learning: 2024-12-04T01:59:34.045Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 832
File: deployments/_deployments_log_file.json:23712-23720
Timestamp: 2024-12-04T01:59:34.045Z
Learning: In `deployments/_deployments_log_file.json`, duplicate deployment entries for the same version and address may occur because they correspond to deployments on different networks. These entries are acceptable and should not be flagged as duplicates in future reviews.
Applied to files:
config/networks.json
📚 Learning: 2024-11-22T08:50:28.878Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 827
File: config/networks.json:448-448
Timestamp: 2024-11-22T08:50:28.878Z
Learning: In `config/networks.json`, Safe addresses (`safeAddress` fields) do not need to be verified, as they are handled separately.
Applied to files:
config/networks.json
📚 Learning: 2025-11-25T01:36:33.521Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to script/deploy/targetState.json : targetState.json in script/deploy/ must track contract versions and deployments across networks using network and environment keys
Applied to files:
config/networks.json
📚 Learning: 2025-01-24T14:53:20.703Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 950
File: script/demoScripts/utils/demoScriptChainConfig.ts:17-20
Timestamp: 2025-01-24T14:53:20.703Z
Learning: In the LiFi contracts repository, RPC URLs should be strictly sourced from environment variables without fallback to networks.json configuration.
Applied to files:
config/networks.json
📚 Learning: 2025-08-26T02:20:52.515Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1334
File: deployments/mainnet.json:54-54
Timestamp: 2025-08-26T02:20:52.515Z
Learning: For deployment PRs in the lifinance/contracts repository, carefully verify the specific scope mentioned in the PR title and description before suggesting updates to other networks. Not all deployments are cross-network updates - some are targeted to specific chains only.
Applied to files:
config/networks.json
📚 Learning: 2025-08-07T06:42:38.555Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1316
File: config/networks.json:0-0
Timestamp: 2025-08-07T06:42:38.555Z
Learning: For zkEVM networks in config/networks.json, it's correct for the `create3Factory` field to be missing entirely rather than set to a placeholder address, as deployment scripts skip CREATE3 factory deployment on zkEVM chains.
Applied to files:
config/networks.json
📚 Learning: 2025-08-19T05:10:12.922Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1303
File: script/utils/network.ts:27-32
Timestamp: 2025-08-19T05:10:12.922Z
Learning: In the lifinance/contracts repository, the team decided to standardize RPC environment variable naming by converting all hyphens to underscores in network names. For example, "tron-shasta" becomes "ETH_NODE_URI_TRON_SHASTA". The getRPCEnvVarName() helper in script/utils/network.ts implements this standard and should be used consistently across the codebase instead of direct string manipulation.
Applied to files:
config/networks.json
📚 Learning: 2025-11-06T10:38:55.953Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1450
File: script/deploy/safe/safe-utils.ts:926-926
Timestamp: 2025-11-06T10:38:55.953Z
Learning: In the `script/deploy/safe/safe-utils.ts` file, within the `getSafeMongoCollection()` function, the VPN IP address '18.195.61.255' should remain hardcoded rather than being moved to an environment variable.
Applied to files:
config/networks.json
📚 Learning: 2025-02-26T13:25:23.615Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1015
File: script/deploy/safe/add-safe-owners-and-threshold.ts:63-64
Timestamp: 2025-02-26T13:25:23.615Z
Learning: In the LiFi contracts repository, RPC URL validation is handled in the `getViemChainForNetworkName` helper function, which throws a descriptive error if the RPC URL is missing. This ensures that by the time the chain object is used elsewhere in the codebase, a valid RPC URL is guaranteed to exist.
Applied to files:
config/networks.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.
Applied to files:
config/networks.json
📚 Learning: 2025-11-25T02:57:57.994Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1466
File: config/whitelist.json:2546-2554
Timestamp: 2025-11-25T02:57:57.994Z
Learning: In lifinance/contracts config/whitelist.json, the SushiSwap Aggregator uses functions:
- snwap(address,uint256,address,address,uint256,address,bytes) -> selector 0x5f3bd1c8
- snwapMultiple((address,uint256,address)[],(address,address,uint256)[],(address,uint256,bytes)[]) -> selector 0xd33721a5
These selectors are canonical across networks and valid for the monad entry as well. Always compute with Keccak-256 (not SHA3-256) when verifying.
Applied to files:
config/whitelist.json
🪛 Gitleaks (8.29.0)
deployments/megaeth.diamond.json
[high] 71-71: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (11)
deployments/megaeth.diamond.json (4)
1-74: Address audit: Gitleaks false positive on line 71.Static analysis flagged the TokenWrapper address on line 71 as a "Generic API Key". This is a false positive—the value
0x5f177F60802f798Aef5E3723fDCF27C172Ae6756is a standard Ethereum contract address, not an API key or secret. No action required.
57-73: Confirm periphery addresses are deployed and correct.Several periphery components have empty strings (LidoWrapper, Patcher, ReceiverAcrossV3, ReceiverAcrossV4, ReceiverChainflip, ReceiverStargateV2). This is acceptable if these contracts are intentionally not deployed on megaeth. However, verify that the non-empty addresses (e.g., ERC20Proxy, Executor, FeeCollector, GasZipPeriphery, LiFiDEXAggregator, Permit2Proxy, TokenWrapper) are correct and match the actual deployment on megaeth.
1-74: PR is in DRAFT status with critical checklists unchecked.The PR objectives indicate this pull request is in DRAFT mode with all checklists unchecked, including the security reviewer checklist with explicit warning: "DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!"
The security checklist requires verification of:
- Arbitrary calls to external contracts are validated and/or restricted
- Privileged calls (storage modifications) are validated and/or restricted
- New contracts have had preliminary audit(s) conducted
Despite the "AuditNotRequired" label, megaeth appears to be a new network deployment introducing new facet/periphery configurations. Ensure these verification steps are completed and documented before approving this PR.
3-56: <!-- [scratchpad_start]
[task verification_1/1 checking_facets_4/13]
[observations]
- All 13 facets from megaeth.diamond.json are confirmed:
- DiamondCutFacet
- DiamondLoupeFacet
- AccessManagerFacet
- CalldataVerificationFacet
- WhitelistManagerFacet
- DexManagerFacet
- EmergencyPauseFacet
- GenericSwapFacet
- GenericSwapFacetV3
- OwnershipFacet
- PeripheryRegistryFacet
- WithdrawFacet
- GasZipFacet
- WhitelistManagerFacet is present in megaeth.json with address 0x746E5c2ea5b3C005368645544D4B532255177e5c
- This matches the address in megaeth.diamond.json (from the review comment snippet)
- Three spot-checked facets (DiamondCutFacet, GenericSwapFacet, GasZipFacet) all had exact address matches
[analysis]
- All facet names in megaeth.diamond.json are also present in megaeth.json
- The three key facets requested in the original comment all matched exactly
- WhitelistManagerFacet is also consistently mapped
- No discrepancies found between the two deployment files
[conclusion]
- Verification successful: facet addresses and names are consistent between megaeth.diamond.json and megaeth.json
- The original review comment's concern was addressed and no issues were discovered
- All facets referenced in the diamond configuration have corresponding entries in the main deployment file
[done]
- Task complete: All facet addresses match between megaeth.diamond.json and megaeth.json
No issues found with facet address consistency between megaeth.diamond.json and megaeth.json.
All 13 facets in the LiFiDiamond Facets map have been verified against deployments/megaeth.json. Spot checks of DiamondCutFacet (0x94a7dDFEB0CD13026F732703cF5596fd44A2a385), GenericSwapFacet (0x59Eb62be779329954e0bac80D5F1B1c35D1f41A5), and GasZipFacet (0x2B3CE1Ee07De57C09EC9B8A600C9E4Ffdb5464d0) all match exactly, and all facet names are present in both files with corresponding addresses.
config/composerWhitelist.json (1)
2-232: No action needed. megaeth should not be added to composerWhitelist.json.Verification shows that ComposerFacet is not deployed on megaeth. The
megaeth.diamond.jsonfile lists all deployed facets and periphery contracts, and ComposerFacet is absent. SincecomposerWhitelist.jsonis specifically for whitelisting addresses that expose therunVMfunction (part of ComposerFacet), megaeth does not require an entry here. Additionally,composerWhitelist.jsonwas not modified in this PR, so there is no inconsistency to address.Likely an incorrect or invalid review comment.
deployments/_deployments_log_file.json (2)
1201-1215: Verify timestamp anomalies in GasZip contract deployments.GasZipFacet (line 39572) and GasZipPeriphery (line 40476) show deployment timestamps of
2025-11-26 12:50:58and2025-11-26 12:53:47, respectively, which are ~9 days later than all other megaeth contracts deployed on2025-11-17. Since deployment log files are historical records reflecting actual deployment times, please confirm this timing is accurate or correct if this represents a data entry error.Also applies to: 2405-2419, 3608-3622, 5124-5138, 6337-6351, 7530-7544, 8733-8747, 9896-9910, 12149-12163, 16041-16055, 17371-17385, 18489-18503, 26980-26994, 29965-29978, 31588-31601, 34329-34342, 35405-35419, 38192-38206, 39567-39580, 40471-40484, 43218-43231, 43444-43457, 46504-46517
9903-9903: Verify constructor arguments reference valid deployed contract addresses.Several megaeth contracts include constructor arguments (e.g., LiFiDiamond at line 9903, Executor at line 16048). Spot-check a few entries to confirm:
- The embedded contract addresses in CONSTRUCTOR_ARGS correspond to actual deployed contracts in the megaeth deployment records
- Constructor argument encoding is correct for the respective contract types
Example: LiFiDiamond constructor at line 9903 includes DiamondCutFacet
0x94a7ddfeb0cd13026f732703cf5596fd44a2a385, which matches UnitFacet deployment at line 1205.Also applies to: 16048-16048, 17378-17378, 18496-18496, 29971-29971, 34335-34335, 40477-40477, 43224-43224
config/whitelist.json (2)
4356-4360: I'm encountering persistent infrastructure issues that prevent me from executing verification scripts. The repository cloning is failing consistently, which blocks both selector computation and file content verification.Given the learnings from prior reviews (ezynda3 and 0xDEnYO) that emphasize selector verification must be performed with concrete evidence and using Keccak-256 computation, I cannot complete the necessary verification at this time.
Unable to verify selector correctness and Composer consistency across networks due to execution environment limitations.
The review comment requests verification that cannot be completed without:
- Computing the correct Keccak-256 selector for the signature
runVM((uint8,bytes32)[],(bytes[]))- Checking all Composer entries in config/whitelist.json across the listed line ranges
- Confirming consistency across networks
6695-6761: Based on the learnings already provided and the context of the original review comment itself, I can now complete the verification:Key findings:
From Learning (PR 1112): It is "normal and expected for periphery contracts to have empty address values in deployment files when they are not deployed on a particular network." This directly applies to Composer.
Original comment's own language: The review comment states "If Composer is not part of the initial scope for megaeth, this is fine" — which is self-acknowledging that the concern may not be valid.
Scope principle (PR 1334 learning): For deployment PRs, verify the specific scope in PR title/description. Not all deployments target all chains or all periphery contracts.
The review comment raises a conditional concern that is already addressed by established patterns in this repository—missing or future periphery contracts are expected behavior.
New megaeth periphery added — note Composer deployment status.
megaeth periphery includes FeeCollector, FeeForwarder, GasZipPeriphery, TokenWrapper, and LiFiDEXAggregator. If Composer is planned for megaeth, ensure it's added here and in composerWhitelist.json and deployment artifacts when deployed.
config/permit2Proxy.json (1)
36-36: Addition is correctly aligned with existing patterns.The new megaeth entry correctly uses the standard Permit2 contract address and maintains alphabetical ordering.
config/networks.json (1)
709-709: Verify that special forge deployment flags are actually required.Line 709 documents specific forge script flags (--gas-limit 50000000, --gas-price 2000000, --skip-simulation, --legacy) that are stated as required for deployment scripts. Ensure these are necessary for this network and update/remove devNotes if constraints change.
Comment on lines
+700
to
+701
| "explorerUrl": "https://megaeth-testnet-v3.blockscout.com", | ||
| "explorerApiUrl": "https://megaeth-testnet-v3.blockscout.com/api", |
Contributor
There was a problem hiding this comment.
Explorer URLs reference testnet but network is configured as mainnet.
Lines 700–701 point to "megaeth-testnet-v3.blockscout.com" while the network is configured with type: "mainnet" and status: "active". This inconsistency can cause verification failures and incorrect explorer navigation. Update these URLs to point to the mainnet explorer once available.
- "explorerUrl": "https://megaeth-testnet-v3.blockscout.com",
- "explorerApiUrl": "https://megaeth-testnet-v3.blockscout.com/api",
+ "explorerUrl": "https://megaeth.blockscout.com", // Replace with actual mainnet explorer
+ "explorerApiUrl": "https://megaeth.blockscout.com/api",📝 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.
Suggested change
| "explorerUrl": "https://megaeth-testnet-v3.blockscout.com", | |
| "explorerApiUrl": "https://megaeth-testnet-v3.blockscout.com/api", | |
| "explorerUrl": "https://megaeth.blockscout.com", // Replace with actual mainnet explorer | |
| "explorerApiUrl": "https://megaeth.blockscout.com/api", |
🤖 Prompt for AI Agents
In config/networks.json around lines 700 to 701, the explorerUrl and
explorerApiUrl point to the testnet host "megaeth-testnet-v3.blockscout.com"
while the network is declared type: "mainnet" and status: "active"; update both
URLs to the correct mainnet Blockscout endpoints (replace the testnet host with
the mainnet host or the official mainnet explorer domain) so explorerUrl and
explorerApiUrl reference the mainnet explorer, and ensure the URLs use the same
scheme/path pattern as other mainnet entries (e.g., / and /api).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Which Jira task belongs to this PR?
https://lifi.atlassian.net/browse/LF-14907
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)