Deploy network monad #1466
Open
Deploy network monad #1466
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 "monad" network and related addresses across configuration files (networks, dexs, periphery/whitelist, permit2, gaszip, glacis, mayan, sigs), new deployment manifests and logs, RPC endpoints in foundry.toml, and a production target state entry for Monad. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes
Possibly related PRs
Suggested labels
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (3)
🧰 Additional context used🧠 Learnings (26)📓 Common learnings📚 Learning: 2025-09-09T10:39:26.383ZApplied to files:
📚 Learning: 2025-04-21T03:17:53.443ZApplied to files:
📚 Learning: 2025-09-22T00:52:26.172ZApplied to files:
📚 Learning: 2025-09-16T01:39:54.099ZApplied to files:
📚 Learning: 2025-04-21T03:17:53.443ZApplied to files:
📚 Learning: 2024-09-27T07:10:15.586ZApplied to files:
📚 Learning: 2025-04-21T03:15:12.236ZApplied to files:
📚 Learning: 2024-11-25T09:05:43.045ZApplied to files:
📚 Learning: 2024-11-26T01:01:18.499ZApplied to files:
📚 Learning: 2025-08-28T02:21:50.428ZApplied to files:
📚 Learning: 2025-10-10T10:56:04.861ZApplied to files:
📚 Learning: 2025-06-13T08:30:26.220ZApplied to files:
📚 Learning: 2024-11-01T11:53:57.162ZApplied to files:
📚 Learning: 2025-09-25T07:47:30.735ZApplied to files:
📚 Learning: 2024-11-26T01:16:27.721ZApplied to files:
📚 Learning: 2025-08-27T13:07:58.254ZApplied to files:
📚 Learning: 2025-08-27T13:47:28.646ZApplied to files:
📚 Learning: 2025-02-12T09:44:12.961ZApplied to files:
📚 Learning: 2024-10-09T03:47:21.269ZApplied to files:
📚 Learning: 2024-11-26T01:04:16.637ZApplied to files:
📚 Learning: 2025-01-28T14:30:06.911ZApplied to files:
📚 Learning: 2024-10-09T03:47:21.269ZApplied to files:
📚 Learning: 2024-10-09T03:47:21.269ZApplied to files:
📚 Learning: 2025-08-27T13:07:58.254ZApplied to files:
📚 Learning: 2024-10-09T03:47:21.269ZApplied to files:
🪛 Gitleaks (8.29.0)deployments/monad.json[high] 2-2: Detected a Generic API Key, potentially exposing access to various services and sensitive operations. (generic-api-key) [high] 19-19: Detected a Generic API Key, potentially exposing access to various services and sensitive operations. (generic-api-key) deployments/monad.diamond.json[high] 79-79: 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)
🔇 Additional comments (3)
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)
foundry.toml (1)
71-71: Add space aftermonadfor consistency.Line 71 is missing a space after the key name, inconsistent with the surrounding RPC endpoint entries.
-monad= "${ETH_NODE_URI_MONAD}" +monad = "${ETH_NODE_URI_MONAD}"
📜 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 (13)
config/dexs.json(1 hunks)config/gaszip.json(1 hunks)config/glacis.json(1 hunks)config/networks.json(1 hunks)config/permit2Proxy.json(1 hunks)config/whitelist.json(1 hunks)deployments/_deployments_log_file.json(24 hunks)deployments/monad.diamond.json(1 hunks)deployments/monad.json(1 hunks)foundry.toml(2 hunks)script/deploy/_targetState.json(1 hunks)script/deploy/facets/UpdateCoreFacets.s.sol(2 hunks)script/deploy/facets/UpdateDiamondLoupeFacet.s.sol(1 hunks)
🧰 Additional context used
🧠 Learnings (75)
📓 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: 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/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: 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: 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: 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/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: 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: 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: 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-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: 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/monad.jsonconfig/whitelist.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: config/global.json:137-137
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The "opbnb" network entry in `config/global.json` is properly utilized elsewhere in the codebase and doesn't require additional updates.
Applied to files:
config/permit2Proxy.jsonconfig/networks.json
📚 Learning: 2024-10-21T01:27:47.808Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 836
File: config/dexs.json:396-397
Timestamp: 2024-10-21T01:27:47.808Z
Learning: In `config/dexs.json`, it's acceptable for a whitelisted DEX address to be the same across multiple networks.
Applied to files:
config/permit2Proxy.jsonconfig/dexs.json
📚 Learning: 2024-11-04T02:25:07.478Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 846
File: config/dexs.json:296-300
Timestamp: 2024-11-04T02:25:07.478Z
Learning: In `config/dexs.json`, it's expected that some addresses appear multiple times across different networks.
Applied to files:
config/permit2Proxy.jsonconfig/dexs.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:
config/gaszip.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:
config/gaszip.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/monad.diamond.jsonscript/deploy/facets/UpdateDiamondLoupeFacet.s.soldeployments/monad.jsonscript/deploy/_targetState.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.diamond.jsonscript/deploy/facets/UpdateDiamondLoupeFacet.s.soldeployments/monad.jsonscript/deploy/_targetState.jsondeployments/_deployments_log_file.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.diamond.jsondeployments/monad.jsondeployments/_deployments_log_file.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/monad.diamond.jsondeployments/monad.jsonscript/deploy/_targetState.jsondeployments/_deployments_log_file.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/monad.diamond.jsondeployments/monad.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.diamond.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.diamond.jsonscript/deploy/facets/UpdateDiamondLoupeFacet.s.soldeployments/monad.jsondeployments/_deployments_log_file.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.diamond.jsondeployments/monad.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/monad.diamond.jsonscript/deploy/facets/UpdateDiamondLoupeFacet.s.soldeployments/monad.jsondeployments/_deployments_log_file.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.diamond.jsondeployments/monad.jsonscript/deploy/facets/UpdateCoreFacets.s.sol
📚 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/monad.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/monad.diamond.jsonconfig/whitelist.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/monad.diamond.jsondeployments/monad.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/monad.diamond.jsondeployments/_deployments_log_file.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/monad.diamond.json
📚 Learning: 2025-08-29T11:13:11.137Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: src/Periphery/LDA/Facets/UniV3StyleFacet.sol:4-12
Timestamp: 2025-08-29T11:13:11.137Z
Learning: The correct directory structure for LDA imports in the LiFi contracts codebase is "src/Periphery/LDA/" (uppercase). Import paths should use "lifi/Periphery/LDA/..." to match the actual filesystem structure. The files exist at paths like src/Periphery/LDA/PoolCallbackAuthenticated.sol, src/Periphery/LDA/Errors/Errors.sol, and src/Periphery/LDA/BaseRouteConstants.sol.
Applied to files:
deployments/monad.diamond.json
📚 Learning: 2025-08-26T15:19:07.800Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: script/deploy/facets/LDA/DeployAlgebraFacet.s.sol:4-4
Timestamp: 2025-08-26T15:19:07.800Z
Learning: DeployScriptBase.sol is located at script/deploy/facets/utils/DeployScriptBase.sol, not script/deploy/utils/DeployScriptBase.sol. Import paths from script/deploy/facets/LDA/ should use "../utils/DeployScriptBase.sol" to reference it correctly.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.solscript/deploy/facets/UpdateCoreFacets.s.sol
📚 Learning: 2025-01-28T14:29:00.823Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: script/deploy/zksync/utils/UpdateScriptBase.sol:112-178
Timestamp: 2025-01-28T14:29:00.823Z
Learning: The suggestion to modify `buildDiamondCut` function in `UpdateScriptBase.sol` to handle selectors from multiple old facets differently was deemed unnecessary by the maintainer.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.solscript/deploy/facets/UpdateCoreFacets.s.sol
📚 Learning: 2025-10-02T18:14:45.047Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1406
File: script/deploy/facets/UpdateUnitFacet.s.sol:1-3
Timestamp: 2025-10-02T18:14:45.047Z
Learning: For update scripts in script/deploy/facets/, the SPDX license identifier should be immediately followed by the pragma statement without a blank line in between, as confirmed by mirooon for script/deploy/facets/UpdateUnitFacet.s.sol.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.solscript/deploy/facets/UpdateCoreFacets.s.sol
📚 Learning: 2024-09-23T01:42:03.075Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: script/deploy/facets/DeployGasZipFacet.s.sol:22-35
Timestamp: 2024-09-23T01:42:03.075Z
Learning: In deployment scripts like `DeployGasZipFacet.s.sol`, do not report issues suggesting adding error handling for missing configuration files or unexpected JSON structures, as the script will fail if the file is missing.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.solscript/deploy/facets/UpdateCoreFacets.s.sol
📚 Learning: 2025-01-28T14:27:50.689Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: script/deploy/zksync/DeployReceiverStargateV2.s.sol:19-21
Timestamp: 2025-01-28T14:27:50.689Z
Learning: In LiFi's deployment scripts, the `deploy` method in `DeployScriptBase` handles the concatenation of constructor arguments with the contract's creation code, so child contracts don't need to concatenate the arguments explicitly.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-08-29T14:05:37.002Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: script/deploy/facets/LDA/DeployLDAOwnershipFacet.s.sol:1-3
Timestamp: 2025-08-29T14:05:37.002Z
Learning: For deployment script files in script/deploy/facets/LDA/, the SPDX license identifier should be immediately followed by the pragma statement without a blank line in between, as confirmed by mirooon for script/deploy/facets/LDA/DeployLDAOwnershipFacet.s.sol.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-09-25T00:04:16.437Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1395
File: script/deploy/zksync/DeployFeeForwarder.zksync.s.sol:4-4
Timestamp: 2025-09-25T00:04:16.437Z
Learning: ZkSync deployment scripts have their own DeployScriptBase.sol located at script/deploy/zksync/utils/DeployScriptBase.sol, and all ZkSync deployment scripts use the relative import path "./utils/DeployScriptBase.sol" to reference it, not "../facets/utils/DeployScriptBase.sol".
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-06-05T10:00:01.583Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1145
File: script/tasks/diamondSyncWhitelistedAddresses.sh:208-209
Timestamp: 2025-06-05T10:00:01.583Z
Learning: Task scripts in script/tasks/ directory (like diamondSyncWhitelistedAddresses.sh) define functions that are sourced by deployAllContracts.sh and called from there, rather than executing directly. They don't need to call their own functions at the end of the file.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-11-13T09:20:21.608Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1461
File: script/deploy/facets/UpdateWhitelistManagerFacet.s.sol:21-24
Timestamp: 2025-11-13T09:20:21.608Z
Learning: In deployment scripts that use the NO_BROADCAST flag (noBroadcast), the flag is specifically for building calldata for SAFE transactions (the diamondCut itself), not for helper contract deployments. Helper contracts like MigrateWhitelistManager need to be deployed regardless of the NO_BROADCAST flag setting, as they are prerequisites for the main diamondCut operation.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-08-07T06:34:07.709Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1316
File: script/deploy/deployAllContracts.sh:346-350
Timestamp: 2025-08-07T06:34:07.709Z
Learning: In script/deploy/deployAllContracts.sh, 0xDEnYO prefers not to add automated retry mechanisms for cast send commands in deployment scripts, preferring manual re-execution if network issues occur. This prioritizes simplicity over automated error handling.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2024-11-25T13:49:40.464Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: script/deploy/zksync/DeployPermit2Proxy.s.sol:22-61
Timestamp: 2024-11-25T13:49:40.464Z
Learning: In the deploy scripts (e.g., `script/deploy/zksync/DeployPermit2Proxy.s.sol`), complex error handling and address validation are not necessary. The team prefers to keep deploy scripts simple without extensive error handling.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 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:
foundry.toml
📚 Learning: 2025-01-21T11:06:12.173Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 937
File: foundry.toml:77-77
Timestamp: 2025-01-21T11:06:12.173Z
Learning: APECHAIN_ETHERSCAN_API_KEY is not required for deployments to ApeChain in this project.
Applied to files:
foundry.toml
📚 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/monad.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/monad.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/monad.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/monad.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/monad.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: The CurveFacet in src/Periphery/Lda/Facets/CurveFacet.sol has fundamental issues: it imports a non-existent ICurveLegacy interface, and attempts to send ETH to non-payable exchange functions in both ICurve and ICurveV2 interfaces. All current Curve interfaces are non-payable and cannot accept native ETH.
Applied to files:
deployments/monad.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/monad.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/dexs.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:
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: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: 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.jsonconfig/dexs.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: 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-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-06-11T08:55:44.396Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1201
File: config/dexs.json:536-537
Timestamp: 2025-06-11T08:55:44.396Z
Learning: In lifinance/contracts, the addresses stored in config/dexs.json are handled case-insensitively, so they do not need to be written in EIP-55 checksummed format.
Applied to files:
config/dexs.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:
script/deploy/_targetState.jsondeployments/_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, 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: 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: 2024-11-21T08:25:26.214Z
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.
Applied to files:
script/deploy/_targetState.json
📚 Learning: 2025-02-13T03:04:19.306Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 992
File: script/deploy/_targetState.json:25-32
Timestamp: 2025-02-13T03:04:19.306Z
Learning: Duplicate contract names (e.g., ERC20Proxy, Executor, etc.) in _targetState.json are expected when they appear across different network configurations, as they represent the same contract type deployed on multiple networks.
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, 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:
script/deploy/_targetState.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-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.json
📚 Learning: 2024-11-22T08:50:48.798Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 827
File: deployments/_deployments_log_file.json:0-0
Timestamp: 2024-11-22T08:50:48.798Z
Learning: Duplicate deployment entries for the same contract address in deployment logs are acceptable in this project.
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-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-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-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: 2024-11-25T09:05:03.917Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: script/deploy/_targetState.json:49-49
Timestamp: 2024-11-25T09:05:03.917Z
Learning: The `RelayFacet` contract, when missing from the source code but referenced in deployment configurations, should be treated the same way as `OpBNBBridgeFacet` and can be ignored in code reviews.
Applied to files:
deployments/_deployments_log_file.json
📚 Learning: 2024-11-26T01:14:58.163Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:5-63
Timestamp: 2024-11-26T01:14:58.163Z
Learning: When facet versions are set to empty strings in `deployments/*.diamond.json` files, do not report this issue, as it is already known and will be addressed separately.
Applied to files:
script/deploy/facets/UpdateCoreFacets.s.sol
📚 Learning: 2024-10-31T09:07:36.301Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 843
File: script/deploy/facets/DeployRelayFacet.s.sol:0-0
Timestamp: 2024-10-31T09:07:36.301Z
Learning: In `script/deploy/facets/DeployRelayFacet.s.sol`, additional validation for the configuration file existence and address validity is unnecessary because the code will already fail appropriately if the configuration file is missing or the addresses are invalid.
Applied to files:
script/deploy/facets/UpdateCoreFacets.s.sol
🪛 Gitleaks (8.29.0)
deployments/monad.diamond.json
[high] 75-75: 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 (21)
config/permit2Proxy.json (1)
37-37: Approve monad entry in permit2Proxy.json.The addition follows the established pattern and uses a standard Permit2 contract address consistent with other networks in the configuration.
config/gaszip.json (1)
39-39: Approve monad entry in gaszip.json.The GasZip router address is properly configured and consistent with the pattern used by other networks (flow, katana, plasma, vana).
config/glacis.json (1)
68-70: Approve monad entry in glacis.json.The Glacis airlift address is consistent with deployments on other networks (bob, corn, katana, plasma, vana, etc.).
foundry.toml (1)
144-144: Approve monad entry in etherscan/verifier section.The Sourcify configuration is properly aligned with the network definition (chain ID 143, verificationType: "sourcify" in networks.json).
config/dexs.json (1)
827-835: Approve monad entry in dexs.json.The DEX addresses follow the established pattern, with some addresses shared across networks (flow, plasma) as expected. The configuration is properly formatted and positioned alphabetically.
config/networks.json (1)
710-730: Approve monad network configuration.The network entry is complete and properly structured. All critical fields are populated consistently with other configuration files (chain ID 143, Sourcify verification, correct API URLs). The
gasZipChainId: 0anddevNotes: "Verification not yet working"appropriately reflect the early deployment status of this network.config/whitelist.json (1)
6780-6847: Monad PERIPHERY block verified—no issues found.All verification checks passed:
- ✓ "monad" network referenced across all config files (networks.json, dexs.json, gaszip.json, glacis.json, permit2Proxy.json)
- ✓ All 5 periphery addresses present in deployments/monad.json and monad.diamond.json
- ✓ All addresses use valid EIP-55 checksummed format
- ✓ All 9 function selectors consistent with existing codebase patterns and cross-network references
The block is ready to merge.
deployments/monad.json (1)
1-26: LGTM! Monad deployment addresses are properly configured.The deployment file structure is correct and all contract addresses are valid. The configuration includes all necessary core facets, periphery contracts, and supporting infrastructure for the Monad network deployment.
script/deploy/facets/UpdateCoreFacets.s.sol (3)
12-12: Error definition added for missing DiamondLoupeFacet.The new custom error provides clear feedback when the DiamondLoupeFacet is not found, which improves the developer experience during deployment troubleshooting.
47-59: Comment accurately reflects the refactored logic.The updated comment correctly indicates that DiamondCutFacet and DiamondLoupeFacet are handled separately, which aligns with the new script architecture.
33-41: Code change is valid—deployment order concern is unfounded.The review comment assumes UpdateDiamondLoupeFacet.s.sol must be executed before UpdateCoreFacets.s.sol, but this is a misunderstanding of the deployment workflow. DiamondLoupeFacet is a core facet deployed in STAGE 2 of
deployAllContracts.sh(viadeployCoreFacets), before UpdateCoreFacets runs in STAGE 3. The new try/catch check correctly assumes DiamondLoupeFacet is already deployed. UpdateDiamondLoupeFacet.s.sol appears to be an optional manual update script, not part of the automated deployment pipeline, and is never called in the workflow.script/deploy/facets/UpdateDiamondLoupeFacet.s.sol (3)
1-2: LGTM! Correct file header formatting.The SPDX identifier is immediately followed by the pragma statement without a blank line, which aligns with the project's style guidelines.
23-45: LGTM! DiamondLoupeFacet deployment logic is correct.The script properly:
- Retrieves the loupe address from configuration
- Builds the initial diamond cut with loupe selectors
- Broadcasts the deployment transaction
- Resets the cut variable to avoid carrying loupe data forward
60-71: Return values correctly handle loupe existence.The script appropriately returns:
- Early with prepared cutData if noBroadcast is enabled
- Facet addresses when loupe exists (can query the diamond)
- Empty array when loupe doesn't exist yet (can't query until after deployment)
deployments/monad.diamond.json (2)
1-60: LGTM! Diamond facet configuration is properly structured.The facet mappings are correctly formatted with each address pointing to a Name/Version object. All version numbers are consistent with the deployment pattern and facet addresses match those in
deployments/monad.json.
61-77: Periphery configuration is correct.The periphery contract addresses are properly configured. Empty string values for
LidoWrapper,Patcher, and receiver contracts (ReceiverAcrossV3,ReceiverAcrossV4,ReceiverChainflip,ReceiverStargateV2) are acceptable and indicate these contracts are not deployed on the Monad network. Based on learnings.Note: The static analysis warning on line 75 about a "Generic API Key" is a false positive—it's flagging the
TokenWrappercontract address, which is a legitimate Ethereum address, not an API key.deployments/_deployments_log_file.json (5)
1186-1200: Entries are well-structured and internally consistent; cross-references verified.The entries follow the standard deployment log pattern with proper address formats and consistent structure across all 24 hunks. Constructor arguments correctly reference other deployed contracts (e.g., Hunk 8's LiFiDiamond properly references the DiamondCutFacet address from Hunk 1, Hunk 11 references Hunk 10's contract). All optimizer runs, salt, and field values are consistent.
Also applies to: 2375-2389, 3563-3577, 5064-5078, 6262-6276, 7440-7454, 8628-8642, 9776-9790, 12014-12028
1192-1192: Verify timestamp discrepancy across entries.Most entries have timestamps from 2025-10-03 to 2025-10-04, but three entries (RelayFacet at line 41859, WhitelistManagerFacet at line 43064, and Patcher at line 46077) have timestamps from 2025-11-14—today's date. Confirm whether this represents staggered deployments, redeployments, or corrections to earlier deployments, and ensure all timestamps accurately reflect when contracts were actually deployed on Monad.
Also applies to: 2381-2381, 3569-3569, 5070-5070, 6268-6268, 7446-7446, 8634-8634, 9782-9782, 12020-12020, 15897-15897, 17212-17212, 18315-18315, 31369-31369, 34065-34065, 35127-35127, 37899-37899, 39247-39247, 40136-40136, 41859-41859, 42883-42883, 43064-43064, 46077-46077
1182-1200: Verify completeness against monad.json and _targetState.json.Per the AI summary, related configuration files (config/networks.json, deployments/monad.json, script/deploy/_targetState.json) introduce Monad network support. Confirm that all contracts present in deployments/monad.json have corresponding entries in this log file, and that the addresses and versions match across files.
1195-1195: Operational concern: All entries marked VERIFIED: "false".All 24 Monad deployment entries have
VERIFIED: "false". While this is normal for newly deployed contracts awaiting verification on block explorers, confirm that this is the expected state for production Monad deployments and that there is no requirement to verify contracts before production release.Also applies to: 2384-2384, 3572-3572, 5073-5073, 6271-6271, 7449-7449, 8637-8637, 9785-9785, 12023-12023, 15900-15900, 17215-17215, 18318-18318, 31372-31372, 34068-34068, 35131-35131, 37902-37902, 39251-39251, 40139-40139, 41862-41862, 42886-42886, 43067-43067, 46080-46080
1186-46086: Note: PR checklists incomplete.The PR has not completed any of the self-review or reviewer checklists, including the critical security validation checklist marked "DO NOT DEPLOY ... BEFORE CHECKING THIS!!!". The checklist items include:
- Validation of arbitrary external contract calls
- Verification of privileged call restrictions
- Audit status confirmation for new contracts
Ensure these checks are completed before deployment.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol (1)
19-19: Consider removing redundant log message.Lines 19 and 25 emit essentially the same information. When the loupe doesn't exist, both messages will be logged in sequence, which is redundant.
Consider removing line 25 since line 19 already communicates that the loupe does not exist:
} catch { emit log("Loupe does not exist"); // No need to do anything, just making sure that the flow continues in both cases with try/catch } // Handle DiamondLoupeFacet separately as it needs special treatment if (!loupeExists) { - emit log("Loupe does not exist on diamond yet"); address diamondLoupeAddress = _getConfigContractAddress(Also applies to: 25-25
📜 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 (2)
config/networks.json(1 hunks)script/deploy/facets/UpdateDiamondLoupeFacet.s.sol(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- config/networks.json
🧰 Additional context used
🧠 Learnings (20)
📓 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: 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: 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/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: 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: 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: 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: 1169
File: script/deploy/zksync/DeployFeeCollector.zksync.s.sol:32-37
Timestamp: 2025-05-27T12:00:43.940Z
Learning: The lifinance/contracts repository has deployment scripts that perform validation checks (including zero-address validation) before executing individual deploy scripts, making runtime validation checks in the deploy scripts themselves redundant.
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: 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: 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: 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-08-26T15:19:07.800Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: script/deploy/facets/LDA/DeployAlgebraFacet.s.sol:4-4
Timestamp: 2025-08-26T15:19:07.800Z
Learning: DeployScriptBase.sol is located at script/deploy/facets/utils/DeployScriptBase.sol, not script/deploy/utils/DeployScriptBase.sol. Import paths from script/deploy/facets/LDA/ should use "../utils/DeployScriptBase.sol" to reference it correctly.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-01-28T14:29:00.823Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: script/deploy/zksync/utils/UpdateScriptBase.sol:112-178
Timestamp: 2025-01-28T14:29:00.823Z
Learning: The suggestion to modify `buildDiamondCut` function in `UpdateScriptBase.sol` to handle selectors from multiple old facets differently was deemed unnecessary by the maintainer.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-10-02T18:14:45.047Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1406
File: script/deploy/facets/UpdateUnitFacet.s.sol:1-3
Timestamp: 2025-10-02T18:14:45.047Z
Learning: For update scripts in script/deploy/facets/, the SPDX license identifier should be immediately followed by the pragma statement without a blank line in between, as confirmed by mirooon for script/deploy/facets/UpdateUnitFacet.s.sol.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2024-09-23T01:42:03.075Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: script/deploy/facets/DeployGasZipFacet.s.sol:22-35
Timestamp: 2024-09-23T01:42:03.075Z
Learning: In deployment scripts like `DeployGasZipFacet.s.sol`, do not report issues suggesting adding error handling for missing configuration files or unexpected JSON structures, as the script will fail if the file is missing.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 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/facets/UpdateDiamondLoupeFacet.s.sol
📚 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/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-01-28T14:27:50.689Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: script/deploy/zksync/DeployReceiverStargateV2.s.sol:19-21
Timestamp: 2025-01-28T14:27:50.689Z
Learning: In LiFi's deployment scripts, the `deploy` method in `DeployScriptBase` handles the concatenation of constructor arguments with the contract's creation code, so child contracts don't need to concatenate the arguments explicitly.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-08-29T14:05:37.002Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: script/deploy/facets/LDA/DeployLDAOwnershipFacet.s.sol:1-3
Timestamp: 2025-08-29T14:05:37.002Z
Learning: For deployment script files in script/deploy/facets/LDA/, the SPDX license identifier should be immediately followed by the pragma statement without a blank line in between, as confirmed by mirooon for script/deploy/facets/LDA/DeployLDAOwnershipFacet.s.sol.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 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:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 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:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 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:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 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:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2024-10-31T09:07:36.301Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 843
File: script/deploy/facets/DeployRelayFacet.s.sol:0-0
Timestamp: 2024-10-31T09:07:36.301Z
Learning: In `script/deploy/facets/DeployRelayFacet.s.sol`, additional validation for the configuration file existence and address validity is unnecessary because the code will already fail appropriately if the configuration file is missing or the addresses are invalid.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-03-05T14:41:05.791Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 953
File: script/deploy/zksync/utils/UpdateScriptBase.sol:32-50
Timestamp: 2025-03-05T14:41:05.791Z
Learning: In the LiFi contracts repository, explicit error handling for file operations and address validation in deployment scripts like UpdateScriptBase.sol is not considered necessary by the maintainer.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-09-25T00:04:16.437Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1395
File: script/deploy/zksync/DeployFeeForwarder.zksync.s.sol:4-4
Timestamp: 2025-09-25T00:04:16.437Z
Learning: ZkSync deployment scripts have their own DeployScriptBase.sol located at script/deploy/zksync/utils/DeployScriptBase.sol, and all ZkSync deployment scripts use the relative import path "./utils/DeployScriptBase.sol" to reference it, not "../facets/utils/DeployScriptBase.sol".
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-06-05T10:00:01.583Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 1145
File: script/tasks/diamondSyncWhitelistedAddresses.sh:208-209
Timestamp: 2025-06-05T10:00:01.583Z
Learning: Task scripts in script/tasks/ directory (like diamondSyncWhitelistedAddresses.sh) define functions that are sourced by deployAllContracts.sh and called from there, rather than executing directly. They don't need to call their own functions at the end of the file.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-11-13T09:20:21.608Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 1461
File: script/deploy/facets/UpdateWhitelistManagerFacet.s.sol:21-24
Timestamp: 2025-11-13T09:20:21.608Z
Learning: In deployment scripts that use the NO_BROADCAST flag (noBroadcast), the flag is specifically for building calldata for SAFE transactions (the diamondCut itself), not for helper contract deployments. Helper contracts like MigrateWhitelistManager need to be deployed regardless of the NO_BROADCAST flag setting, as they are prerequisites for the main diamondCut operation.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2025-08-07T06:34:07.709Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1316
File: script/deploy/deployAllContracts.sh:346-350
Timestamp: 2025-08-07T06:34:07.709Z
Learning: In script/deploy/deployAllContracts.sh, 0xDEnYO prefers not to add automated retry mechanisms for cast send commands in deployment scripts, preferring manual re-execution if network issues occur. This prioritizes simplicity over automated error handling.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
📚 Learning: 2024-11-25T13:49:40.464Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: script/deploy/zksync/DeployPermit2Proxy.s.sol:22-61
Timestamp: 2024-11-25T13:49:40.464Z
Learning: In the deploy scripts (e.g., `script/deploy/zksync/DeployPermit2Proxy.s.sol`), complex error handling and address validation are not necessary. The team prefers to keep deploy scripts simple without extensive error handling.
Applied to files:
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
⏰ 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 (2)
script/deploy/facets/UpdateDiamondLoupeFacet.s.sol (2)
13-21: Log message has been corrected.The catch block now correctly logs "Loupe does not exist" (line 19), which accurately reflects the execution path when the loupe facet is not present on the diamond. This addresses the issue flagged in the previous review.
37-41: Verify noBroadcast flag behavior with loupe deployment.The script broadcasts the DiamondLoupeFacet deployment (lines 37-41) before checking the
noBroadcastflag (line 60). IfnoBroadcastis true (meaning we're building calldata for SAFE transactions rather than executing directly), should the loupe deployment still be broadcast?Please clarify whether:
- The DiamondLoupeFacet deployment should always be broadcast regardless of
noBroadcast(treating it as a prerequisite), or- The
noBroadcastcheck should be moved before line 37 to prevent broadcasting when building calldataBased on learnings, helper contract deployments should happen regardless of the flag, but the loupe is being added via
diamondCut(not deployed as a standalone contract), so it's unclear if the same rule applies.Consider wrapping the broadcast in a conditional check:
buildInitialCut(loupeSelectors, diamondLoupeAddress); if (!noBroadcast) { vm.startBroadcast(deployerPrivateKey); if (cut.length > 0) { cutter.diamondCut(cut, address(0), ""); } vm.stopBroadcast(); }Also applies to: 60-62
…ts into deploy-network-monad-2
ezynda3
previously approved these changes
Nov 14, 2025
Contributor
|
Monorail dex: {
"name": "Monorail",
"key": "monorail",
"logoURI": "https://raw.githubusercontent.com/lifinance/types/main/src/assets/icons/exchanges/monorail.svg",
"webUrl": "https://testnet-preview.monorail.xyz/",
"contracts": {
"monad": [
{
"address": "0xa68a7f0601effdc65c64d9c47ca1b18d96b4352c",
"functions": {
"0xf99cae99": "aggregate(address,address,uint256,uint256,address,uint256,uint64,uint64,(uint256,uint32,uint8,address,address,address,bytes)[])"
}
}
]
}
}signs and dexs.json have been updated already |
Contributor
|
Kuru update: [
{
"name": "Kuru",
"key": "kuru",
"logoURI": "https://raw.githubusercontent.com/lifinance/types/main/src/assets/icons/exchanges/kuru.svg",
"webUrl": "https://www.kuru.io/",
"contracts": {
"monad": [
{
"address": "0xb3e6778480b2e488385e8205ea05e20060b813cb",
"functions": {
"0xce1e7030": "executeSwap((address,uint256,address,uint256),(address,uint256,address,uint256,bool),bytes)"
}
}
]
}
}
]Dexs.json: Sign.json: |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 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 (1)
config/networks.json(1 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 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: 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: 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: 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: 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: 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: 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: 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/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: 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: 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: 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: 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: 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.
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: 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: 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-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-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-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: 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-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: config/global.json:137-137
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The "opbnb" network entry in `config/global.json` is properly utilized elsewhere in the codebase and doesn't require additional updates.
Applied to files:
config/networks.json
📚 Learning: 2024-11-04T02:25:07.478Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 846
File: config/dexs.json:296-300
Timestamp: 2024-11-04T02:25:07.478Z
Learning: In `config/dexs.json`, it's expected that some addresses appear multiple times across different networks.
Applied to files:
config/networks.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/networks.json
Comment on lines
+710
to
+730
| "monad": { | ||
| "name": "monad", | ||
| "chainId": 143, | ||
| "nativeAddress": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", | ||
| "nativeCurrency": "MON", | ||
| "wrappedNativeAddress": "0x3bd359C1119dA7Da1D913D1C4D2B7c461115433A", | ||
| "status": "active", | ||
| "type": "mainnet", | ||
| "rpcUrl": "<redacted>", | ||
| "verificationType": "sourcify", | ||
| "explorerUrl": "https://monvision.io", | ||
| "explorerApiUrl": "https://sourcify-api-monad.blockvision.org", | ||
| "multicallAddress": "0xca11bde05977b3631167028862be2a173976ca11", | ||
| "safeAddress": "0x94288DB96fBe7EB6847965120BE91eaB81f3A6d0", | ||
| "gasZipChainId": 511, | ||
| "isZkEVM": false, | ||
| "deployedWithEvmVersion": "cancun", | ||
| "deployedWithSolcVersion": "0.8.29", | ||
| "create3Factory": "0xeBbbaC35500713C4AD49929e1bE4225c7efF6510", | ||
| "devNotes": "Verification not yet working, also UpdateScripts often fail with weird errors while deployments work fine. Workaround is to copy the calldata and send/propose it directly" | ||
| }, |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
Verify the Monad network configuration values before deployment.
The new Monad network entry appears structurally complete and properly positioned alphabetically. However, several values require verification:
- Chain ID (line 712): Confirm that chain ID
143is correct for the Monad network. - Addresses (lines 713, 715, 722-724, 728): Verify that all contract addresses (native address, wrapped native, multicall, safe, create3Factory) are accurate and not placeholders.
- Explorer URLs (lines 720-721): Confirm that the Monad Vision explorer and Sourcify API endpoints are correct and accessible.
- RPC URL (line 718): Note that the RPC URL is currently redacted and should be populated with the actual endpoint before production deployment.
Additionally, the devNotes (line 729) document known limitations with verification and update scripts on this network. Ensure these workarounds are documented in deployment runbooks.
🏁 Script executed:
#!/bin/bash
# Description: Verify explorer URLs are accessible for Monad network
# Test Monad Vision explorer
curl -s -o /dev/null -w "Monad Vision explorer HTTP %{http_code}\n" "https://monvision.io"
# Test Sourcify API
curl -s -o /dev/null -w "Sourcify API HTTP %{http_code}\n" "https://sourcify-api-monad.blockvision.org"Length of output: 52
🌐 Web query:
What is the chain ID for the Monad network?
💡 Result:
Monad Mainnet chain ID is 143. [1]
(For reference: Monad Testnet is 10143 and Devnet is 20143.) [2][3]
Sources:
[1] Monad Developer Docs — Network Information (Mainnet).
[2] Monad Developer Docs — Testnets (Testnet chain ID).
[3] Monad Devnet / chain listings (Devnet chain ID).
Fix the broken Sourcify API endpoint for Monad network configuration.
Chain ID 143 is verified as correct for Monad Mainnet. However, the explorerApiUrl at line 721 returns HTTP 404 and is unreachable. This creates a critical mismatch: the verificationType is set to "sourcify" but the endpoint https://sourcify-api-monad.blockvision.org does not exist or is not yet available.
Required action: Verify and correct the explorerApiUrl endpoint for Monad's Sourcify verification. The current endpoint will cause contract verification failures during deployments, bypassing the workaround mentioned in devNotes.
🤖 Prompt for AI Agents
In config/networks.json around lines 710 to 730, the explorerApiUrl for Monad is
pointing to a non-existent Sourcify endpoint which breaks verification; verify
the correct Sourcify API URL for Monad (or the correct verification provider
endpoint) and replace "https://sourcify-api-monad.blockvision.org" with the
working URL; if no Sourcify endpoint exists, change verificationType to an
appropriate value (e.g., "none" or the actual provider) and update
explorerApiUrl accordingly, then validate the URL returns 200 and run the
project's contract verification workflow to confirm fixes.
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-14908
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)