Deploy network monad

[0xDEnYO]

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

• I have performed a self-review of my code
• This pull request is as small as possible and only tackles one problem
• I have added tests that cover the functionality / test the bug
• For new facets: I have checked all points from this list: https://www.notion.so/lifi/New-Facet-Contract-Checklist-157f0ff14ac78095a2b8f999d655622e
• I have updated any required documentation

Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)

• I have checked that any arbitrary calls to external contracts are validated and or restricted
• I have checked that any privileged calls (i.e. storage modifications) are validated and or restricted
• I have ensured that any new contracts have had AT A MINIMUM 1 preliminary audit conducted on by <company/auditor>

[coderabbitai]

Walkthrough

This PR introduces comprehensive support for the Monad network (chainId 143) across the codebase, including network configuration, contract deployments, DEX/bridge integrations, and deployment helper script enhancements with gas estimation improvements.

Changes

Cohort / File(s)	Summary
Network Configuration config/networks.json, foundry.toml	Added monad network entry with chain ID 143, RPC endpoints, explorer URLs, and core contract addresses; registered monad RPC and etherscan endpoints in foundry tooling configuration.
Deployment Manifests deployments/monad.json, deployments/monad.diamond.json, script/deploy/_targetState.json	Created monad-specific diamond deployment manifests mapping facet/component names to Ethereum addresses and monad production LiFiDiamond facet-version targets.
Deployment Log File deployments/_deployments_log_file.json	Extended deployment metadata with monad contract deployment records across multiple environments and facets (LedgerFacet, BridgeFacet, CrosschainRecipientsFacet, GasZipFacet, GlacisFacet, and others), systematically adding monad entries with deployment addresses and timestamps.
DEX/Router Configurations config/dexs.json, config/gaszip.json, config/permit2Proxy.json, config/whitelist.json	Added monad contract entries and function selectors for multiple DEX routers (Monorail, Kuru) and gas zip routing contracts.
Bridge Integrations config/across.json, config/relay.json, config/glacis.json, config/mayan.json	Registered monad endpoints for Across, Relay, Glacis, and Mayan bridges with network-specific receiver/depository addresses and configurations.
Function Selectors config/sigs.json	Added two new function selectors (0xce1e7030, 0xf99cae99) for swap-related contract interactions.
Deployment Scripts script/tasks/diamondUpdateFacet.sh, script/tasks/diamondUpdatePeriphery.sh, script/tasks/updateFacetConfig.sh	Propagated GAS_ESTIMATE_MULTIPLIER environment variable through forge/cast invocations; introduced helper function for dynamic gas limit estimation using on-chain gas reports.
Across Token Approvals Script script/tasks/solidity/AddTokenApprovalsToAcrossFacetPackedV4.s.sol	Created new Solidity deployment script to configure token approvals for Across bridge integration by reading network-specific tokensToApprove from configuration.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

• deployments/_deployments_log_file.json — High-volume data additions across 20+ contract types and environments; verify monad deployment addresses, timestamps, and verification statuses are correct and complete.
• script/tasks/diamondUpdatePeriphery.sh — New gas estimation logic with helper function getGasLimitWithMultiplier(); verify shell logic handles estimation failures gracefully and integrates correctly with cast send invocations.
• Configuration consistency — Ensure monad addresses and chain IDs (143, gasZipChainId 511) are consistent across network config, deployment manifests, and bridge integrations.
• New Solidity script (AddTokenApprovalsToAcrossFacetPackedV4.s.sol) — Verify correct interaction with AcrossFacetPackedV4, proper config file parsing, and facet address retrieval via loupe.

Possibly related PRs

• Deploy network hemi #1382 — Adds support for "hemi" network using the identical pattern of config/deployment file modifications across networks.json, dexs.json, gaszip.json, foundry.toml, and _deployments_log_file.json.
• Various script improvements (--skip-simulation and gas-estimate-multiplier flags, plus update core facets) #1442 — Modifies the same deployment helper scripts (diamondUpdateFacet.sh, diamondUpdatePeriphery.sh) to handle GAS_ESTIMATE_MULTIPLIER and gas limit computation logic.
• Deployed GlacisFacet on new chains, updated glacis.json to add airlift configurations for new networks #1130 — Adds airlift network entries to config/glacis.json, extending the same integration pattern used in this PR for monad.

Suggested labels

NewNetwork

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	❓ Inconclusive	The PR description includes the Jira reference and partially completes the template, but 'Why did I implement it this way?' is blank, and several important checklist items remain unchecked, including documentation updates and security review confirmations.	Complete the 'Why did I implement it this way?' section explaining the rationale, address unchecked items, and provide details on audit status and any new contract documentation as required by the template.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Deploy network monad' directly summarizes the main change: adding network support for Monad across multiple configuration files and deployment manifests.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch deploy-network-monad-2

Warning

Review ran into problems

🔥 Problems

Errors were encountered while retrieving linked issues.

Errors (1)

• JIRA integration encountered authorization issues. Please disconnect and reconnect the integration in the CodeRabbit UI.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

foundry.toml (1)

71-71: Add space after monad for 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.

📥 Commits

Reviewing files that changed from the base of the PR and between c010833 and adfd574.

📒 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.json
• deployments/monad.json
• config/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.json
• config/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.json
• config/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.json
• config/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.json
• script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
• deployments/monad.json
• script/deploy/_targetState.json
• script/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.json
• script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
• deployments/monad.json
• script/deploy/_targetState.json
• deployments/_deployments_log_file.json
• script/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.json
• deployments/monad.json
• deployments/_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.json
• deployments/monad.json
• script/deploy/_targetState.json
• deployments/_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.json
• deployments/monad.json
• script/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.json
• script/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.json
• script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
• deployments/monad.json
• deployments/_deployments_log_file.json
• script/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.json
• deployments/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.json
• script/deploy/facets/UpdateDiamondLoupeFacet.s.sol
• deployments/monad.json
• deployments/_deployments_log_file.json
• script/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.json
• deployments/monad.json
• script/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.json
• config/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.json
• deployments/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.json
• deployments/_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.sol
• script/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.sol
• script/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.sol
• script/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.sol
• script/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.json
• config/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.json
• config/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.json
• deployments/_deployments_log_file.json

📚 Learning: 2025-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, 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.json
• deployments/_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.json
• deployments/_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: 0 and devNotes: "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 (via deployCoreFacets), 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 TokenWrapper contract 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.

[coderabbitai]

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.

📥 Commits

Reviewing files that changed from the base of the PR and between adfd574 and 3454735.

📒 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 noBroadcast flag (line 60). If noBroadcast is true (meaning we're building calldata for SAFE transactions rather than executing directly), should the loupe deployment still be broadcast?

Please clarify whether:

1. The DiamondLoupeFacet deployment should always be broadcast regardless of noBroadcast (treating it as a prerequisite), or
2. The noBroadcast check should be moved before line 37 to prevent broadcasting when building calldata

Based 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

[myz1237]

Monorail dex:
whitelist.json update:

  {
    "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

[myz1237]

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:
remove 0x43DCFE9c0a0777Aa652926b674AC91189698b71a
add 0xb3e6778480b2e488385e8205ea05e20060b813cb

Sign.json:
add: 0xce1e7030 (we did not update sign before)

[coderabbitai]

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.

📥 Commits

Reviewing files that changed from the base of the PR and between 7826234 and 563969a.

📒 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

[lifi-action-bot]

Test Coverage Report

Line Coverage: 85.47% (2830 / 3311 lines)
Function Coverage: 89.08% ( 457 / 513 functions)
Branch Coverage: 63.14% ( 442 / 700 branches)
Test coverage (85.47%) is above min threshold (83%). Check passed.

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/Facets/LiFiIntentEscrowFacet.sol (1)

22-22: Bump @custom:version to satisfy the VersionControlAndAuditVerification check

This contract was modified (even if only formatting), but the @custom:version tag is still 1.0.0, which is causing the pipeline failure. Please bump to the next patch version (for example):

-/// @custom:version 1.0.0
+/// @custom:version 1.0.1

🧹 Nitpick comments (2)

script/tasks/diamondUpdatePeriphery.sh (1)

150-153: LGTM! Gas-limit calculation helper with fallback behavior is well-structured.

The initialization of GAS_ESTIMATE_MULTIPLIER (lines 150–153) and debug logging (line 166) align with the counterpart changes in diamondUpdateFacet.sh. The new getGasLimitWithMultiplier() helper correctly multiplies the cast-estimated gas by the multiplier (line 181), and gracefully falls back to auto-estimation if the call fails (lines 182–185). The GAS_LIMIT_ARGS array construction (lines 191–193) and its proper expansion in all cast send invocations (lines 211, 235, 245, 272) follow bash best practices.

The ShellCheck warnings (SC2155) at lines 178 and 190 are acceptable; the pattern of immediately checking $? after the assignment is idiomatic in this codebase.

Consider moving the getGasLimitWithMultiplier() helper function definition (lines 176–186) outside the while loop to avoid redefining it on each iteration. This is a minor efficiency improvement:

  register() {
    local NETWORK="$1"
    local DIAMOND=$2
    local CONTRACT_NAME=$3
    local ADDR=$4
    local RPC_URL=$(getRPCUrl $NETWORK) || checkFailure $? "get rpc url"
    local ENVIRONMENT=$5

    # make sure GAS_ESTIMATE_MULTIPLIER is set
    if [[ -z "$GAS_ESTIMATE_MULTIPLIER" ]]; then
      GAS_ESTIMATE_MULTIPLIER=130 # this is foundry's default value
    fi

+   # helper function to get gas limit with multiplier applied
+   getGasLimitWithMultiplier() {
+     local ESTIMATED_GAS=$(cast estimate "$DIAMOND" 'registerPeripheryContract(string,address)' "$CONTRACT_NAME" "$ADDR" --rpc-url "$RPC_URL" --private-key "$(getPrivateKey "$NETWORK" "$ENVIRONMENT")" 2>/dev/null)
+     if [ $? -eq 0 ] && [ -n "$ESTIMATED_GAS" ]; then
+       # Multiply by multiplier (130 = 1.3x, 200 = 2x, etc.)
+       echo $((ESTIMATED_GAS * GAS_ESTIMATE_MULTIPLIER / 100))
+     else
+       # If estimation fails, return empty (cast send will estimate automatically)
+       echo ""
+     fi
+   }
+
    # register periphery contract
    local ATTEMPTS=1

    # logging for debug purposes
    echoDebug "in function register"
    ...
    
    while [ $ATTEMPTS -le "$MAX_ATTEMPTS_PER_SCRIPT_EXECUTION" ]; do
-     # helper function to get gas limit with multiplier applied
-     getGasLimitWithMultiplier() {
-       local ESTIMATED_GAS=$(cast estimate "$DIAMOND" 'registerPeripheryContract(string,address)' "$CONTRACT_NAME" "$ADDR" --rpc-url "$RPC_URL" --private-key "$(getPrivateKey "$NETWORK" "$ENVIRONMENT")" 2>/dev/null)
-       if [ $? -eq 0 ] && [ -n "$ESTIMATED_GAS" ]; then
-         # Multiply by multiplier (130 = 1.3x, 200 = 2x, etc.)
-         echo $((ESTIMATED_GAS * GAS_ESTIMATE_MULTIPLIER / 100))
-       else
-         # If estimation fails, return empty (cast send will estimate automatically)
-         echo ""
-       fi
-     }

Also applies to: 166-166, 176-186, 189-197, 211-211, 235-235, 245-245, 272-272

config/whitelist.json (1)

2072-2080: Kyberswap/monad: confirm selector set parity

Only 0xe21fd0e9 and 0x8af033fb are whitelisted here. On several other networks, 0x59e50fed (swapGeneric) is also enabled. If Kyberswap supports it on Monad, consider adding it; if not, the current set is fine—please confirm the intended parity.

Optional diff if supported:

         "monad": [
           {
             "address": "0x6131b5fae19ea4f9d964eac0408e4408b66337b5",
             "functions": {
               "0xe21fd0e9": "swap((address,address,bytes,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes))",
+              "0x59e50fed": "swapGeneric((address,address,bytes,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes))",
               "0x8af033fb": "swapSimpleMode(address,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes,bytes)"
             }
           }
         ],

📜 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.

📥 Commits

Reviewing files that changed from the base of the PR and between e705cee and f366553.

📒 Files selected for processing (16)

• config/across.json (1 hunks)
• config/dexs.json (1 hunks)
• config/gaszip.json (1 hunks)
• config/networks.json (1 hunks)
• config/permit2Proxy.json (1 hunks)
• config/relay.json (1 hunks)
• config/sigs.json (1 hunks)
• config/whitelist.json (4 hunks)
• deployments/_deployments_log_file.json (29 hunks)
• deployments/monad.diamond.json (1 hunks)
• deployments/monad.json (1 hunks)
• foundry.toml (2 hunks)
• script/deploy/_targetState.json (1 hunks)
• script/tasks/diamondUpdateFacet.sh (3 hunks)
• script/tasks/diamondUpdatePeriphery.sh (7 hunks)
• src/Facets/LiFiIntentEscrowFacet.sol (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (7)

• deployments/monad.diamond.json
• config/networks.json
• config/dexs.json
• foundry.toml
• config/permit2Proxy.json
• config/gaszip.json
• config/sigs.json

🧰 Additional context used

🧠 Learnings (87)

📓 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: 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: 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: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: 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: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/across.json
• config/whitelist.json

📚 Learning: 2024-11-26T07:14:08.986Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 875
File: config/amarok.json:111-116
Timestamp: 2024-11-26T07:14:08.986Z
Learning: For the Lisk chain (chainId 1135), it's acceptable to have an empty `connextHandler`, `domain`, and `tokensToApprove` in `config/amarok.json` even if `networks.json` marks Lisk as `"status": "active"`.

Applied to files:

• config/across.json

📚 Learning: 2024-11-04T03:47:47.465Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 847
File: script/tasks/fundNewWalletOnAllChains.ts:156-164
Timestamp: 2024-11-04T03:47:47.465Z
Learning: In the `fundNewWalletOnAllChains.ts` script, the gas estimation code involving `publicClient.estimateGas()` is intentionally commented out and should remain that way unless specified otherwise.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 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/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2025-06-05T14:50:40.886Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1124
File: script/demoScripts/demoPatcherDest.ts:0-0
Timestamp: 2025-06-05T14:50:40.886Z
Learning: Demo scripts in this codebase can use hardcoded gas limits and other simplified values, as they prioritize demonstration clarity over production robustness.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2024-10-22T03:17:36.803Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: src/Periphery/GasZipPeriphery.sol:77-77
Timestamp: 2024-10-22T03:17:36.803Z
Learning: In `GasZipPeriphery.sol`, prefer to avoid making more expensive function calls like calling the contract's own functions with `msg.value` after a swap, in order to save gas.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2024-10-14T00:49:45.265Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/polygon.json:53-55
Timestamp: 2024-10-14T00:49:45.265Z
Learning: Use 'cast code ADDRESS --rpc-url <RPC-URL>' from the Foundry framework to check if a contract has bytecode deployed, to avoid false negatives.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2025-06-13T08:30:28.665Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1207
File: script/deploy/facets/DeployPioneerFacet.s.sol:17-27
Timestamp: 2025-06-13T08:30:28.665Z
Learning: Deployment scripts rely on external automation (pre-script checks) to validate constructor arguments such as non-zero addresses, so adding explicit `require` guards inside the Foundry deployment scripts is generally unnecessary.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2024-11-26T01:18:52.125Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: script/deploy/deploySingleContract.sh:231-231
Timestamp: 2024-11-26T01:18:52.125Z
Learning: In the `deploySingleContract.sh` script, environment variable assignments preceding the `forge script` command (e.g., `DEPLOYSALT=$DEPLOYSALT ... forge script ...`) are acceptable and function correctly, even when variable expansions like `$DIAMOND_TYPE` and `$NETWORK` are used later in the same command.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 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/tasks/diamondUpdatePeriphery.sh
• deployments/monad.json

📚 Learning: 2025-01-20T04:21:41.973Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 931
File: script/deploy/facets/DeployCBridgeFacetPacked.s.sol:27-29
Timestamp: 2025-01-20T04:21:41.973Z
Learning: In deployment scripts, validation of deployerAddress is not needed as it's guaranteed to be available through the deploy script's context.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2025-02-11T10:33:52.791Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 988
File: script/deploy/facets/DeployPermit2Proxy.s.sol:33-37
Timestamp: 2025-02-11T10:33:52.791Z
Learning: The Permit2Proxy contract must not be deployed with zero addresses for its critical dependencies (LiFiDiamond, permit2Address, safeAddress). This is enforced by passing `false` to `_getConfigContractAddress` function.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2025-06-24T08:13:01.516Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1234
File: script/deploy/facets/DeployRelayFacet.s.sol:31-34
Timestamp: 2025-06-24T08:13:01.516Z
Learning: In the lifinance/contracts repository, parameter validation (like checking for address(0) or missing configuration values) should not be suggested in Foundry deploy scripts (files in script/deploy/) because the deployment process includes pre-validation through deployRequirements.json that checks these parameters before the Foundry scripts are executed. The deploy scripts can safely assume parameters are valid.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 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/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2025-04-23T05:21:29.214Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1102
File: script/tasks/diamondSyncSigs_FAST.sh:20-23
Timestamp: 2025-04-23T05:21:29.214Z
Learning: In the lifinance/contracts repository, MAX_ATTEMPTS_PER_SCRIPT_EXECUTION is defined in script/config.sh and made available to other scripts through the sourcing chain.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2024-10-11T22:01:09.826Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 715
File: script/utils/diamondEMERGENCYPauseGitHub.sh:105-105
Timestamp: 2024-10-11T22:01:09.826Z
Learning: In `script/utils/diamondEMERGENCYPauseGitHub.sh`, assigning the variable `OWNER` using `OWNER=$(cast call "$DIAMOND_ADDRESS" "owner() external returns (address)" --rpc-url "$RPC_URL")` is intentional to check if the diamond contract responds or is paused. Saving the result in a variable and executing it in a subshell allows the script to continue running without stopping, even if the variable is not used thereafter.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2025-02-13T03:07:05.721Z

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.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 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:

• script/tasks/diamondUpdatePeriphery.sh
• deployments/monad.json

📚 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/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2024-10-09T03:47:21.269Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: src/Periphery/Permit2Proxy.sol:75-108
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `Permit2Proxy` contract (`src/Periphery/Permit2Proxy.sol`), reentrancy protection is not necessary for functions like `callDiamondWithEIP2612Signature` when calling our own trusted diamond contract (`LIFI_DIAMOND`).

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2024-11-26T01:03:43.597Z

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.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2025-04-21T03:15:12.236Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.diamond.json:84-85
Timestamp: 2025-04-21T03:15:12.236Z
Learning: In deployment JSON files that contain "diamond" in their filename (located in the deployments folder), periphery contracts may have empty string values for their addresses. This indicates that the contract is not deployed on that particular chain and should not be flagged as an issue during code reviews.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• deployments/monad.json

📚 Learning: 2025-06-06T16:09:58.692Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1193
File: script/tasks/diamondSyncWhitelistedAddresses.sh:128-128
Timestamp: 2025-06-06T16:09:58.692Z
Learning: In script/tasks/diamondSyncWhitelistedAddresses.sh at line 128, there is an unquoted command substitution `$(getPrivateKey "$NETWORK" "$ENVIRONMENT")` that should be quoted as `"$(getPrivateKey "$NETWORK" "$ENVIRONMENT")"` to prevent word splitting issues. The user mirooon wants to be reminded about this issue in future PRs when this file is touched.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh

📚 Learning: 2025-04-23T05:20:45.831Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1102
File: script/tasks/diamondSyncSigs_FAST.sh:14-18
Timestamp: 2025-04-23T05:20:45.831Z
Learning: In the lifinance/contracts repository, the `diamondSyncSigs_FAST` function in script/tasks/diamondSyncSigs_FAST.sh doesn't need explicit parameter validation (like for the ENVIRONMENT parameter) because it's called from a master script that ensures these parameters are available.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2024-11-26T01:50:51.809Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 874
File: script/tasks/diamondSyncSigs.sh:88-88
Timestamp: 2024-11-26T01:50:51.809Z
Learning: In the 'lifinance/contracts' repository, scripts like 'script/tasks/diamondSyncSigs.sh' are executed only on local machines where private keys are securely managed, so additional private key security improvements are not required.

Applied to files:

• script/tasks/diamondUpdatePeriphery.sh
• script/tasks/diamondUpdateFacet.sh

📚 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/tasks/diamondUpdateFacet.sh

📚 Learning: 2025-08-27T08:45:59.606Z

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.

Applied to files:

• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2025-02-21T09:05:22.118Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: test/solidity/Facets/ChainflipFacet.t.sol:269-269
Timestamp: 2025-02-21T09:05:22.118Z
Learning: Fixed gas amounts in test files (e.g., ChainflipFacet.t.sol) don't require extensive documentation or configuration as they are only used for testing purposes.

Applied to files:

• script/tasks/diamondUpdateFacet.sh

📚 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/tasks/diamondUpdateFacet.sh
• script/deploy/_targetState.json
• deployments/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 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/tasks/diamondUpdateFacet.sh
• script/deploy/_targetState.json
• deployments/monad.json

📚 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/tasks/diamondUpdateFacet.sh

📚 Learning: 2025-06-24T01:27:58.260Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1231
File: script/helperFunctions.sh:3641-3646
Timestamp: 2025-06-24T01:27:58.260Z
Learning: In the script/helperFunctions.sh codebase, the scripts have existing validation mechanisms that ensure the ENVIRONMENT parameter is always either "production" or "staging" before reaching functions like updateDiamondLogs, making additional validation within individual functions redundant.

Applied to files:

• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2024-10-04T08:53:12.628Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: script/tasks/diamondUpdatePeriphery.sh:194-194
Timestamp: 2024-10-04T08:53:12.628Z
Learning: In `script/tasks/diamondUpdatePeriphery.sh`, the team prefers to use `echo` statements without escaping inner quotes, even if Shellcheck warns about SC2027 regarding unintentional unquoting.

Applied to files:

• script/tasks/diamondUpdateFacet.sh

📚 Learning: 2024-10-31T09:13:14.615Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 843
File: config/relay.json:1-46
Timestamp: 2024-10-31T09:13:14.615Z
Learning: In the `config/relay.json` file, additional network-specific configuration options such as gas limits, timeouts, and feature flags are not needed.

Applied to files:

• config/relay.json

📚 Learning: 2025-05-28T17:33:33.959Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28060-28072
Timestamp: 2025-05-28T17:33:33.959Z
Learning: Deployment log files like `deployments/_deployments_log_file.json` are historical records that document the actual versions deployed at specific times. They should not be updated to match current contract versions - they must accurately reflect what was deployed when the deployment occurred.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-09-30T03:52:27.281Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/_deployments_log_file.json:1914-1927
Timestamp: 2024-09-30T03:52:27.281Z
Learning: Duplicate entries in `deployments/_deployments_log_file.json` that are outdated do not require changes.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-09-15T12:33:51.069Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1377
File: deployments/_deployments_log_file.json:5607-5619
Timestamp: 2025-09-15T12:33:51.069Z
Learning: The deployments/_deployments_log_file.json is structured as network → environment → version → array of deployment records. Always understand the file hierarchy before attempting validation, and target specific paths rather than trying to validate all objects in the JSON.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:10.529Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28706-28717
Timestamp: 2025-05-28T17:33:10.529Z
Learning: Deployment log files (like `_deployments_log_file.json`) are historical records that should not be updated to match current contract versions. They should accurately reflect the versions that were actually deployed at specific timestamps.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-01-09T04:17:46.190Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 914
File: deployments/_deployments_log_file.json:26902-26916
Timestamp: 2025-01-09T04:17:46.190Z
Learning: Updates to _deployments_log_file.json can represent backfilling of historical deployment data, not just new deployments. Such updates don't require new audits.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-09-23T02:05:35.264Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: script/deploy/resources/deployRequirements.json:466-474
Timestamp: 2024-09-23T02:05:35.264Z
Learning: In the `deployRequirements.json` file, do not report issues suggesting adding `config/` prefix to `configFileName` entries, as all entries are designed this way.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-11-22T07:19:51.143Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: deployments/_deployments_log_file.json:22488-22488
Timestamp: 2024-11-22T07:19:51.143Z
Learning: In `deployments/_deployments_log_file.json`, deployment timestamps may appear to be set in the future and should not be flagged as invalid.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-12-04T01:59:34.045Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 832
File: deployments/_deployments_log_file.json:23712-23720
Timestamp: 2024-12-04T01:59:34.045Z
Learning: In `deployments/_deployments_log_file.json`, duplicate deployment entries for the same version and address may occur because they correspond to deployments on different networks. These entries are acceptable and should not be flagged as duplicates in future reviews.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-04-28T10:33:48.525Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1123
File: deployments/polygon.diamond.json:124-127
Timestamp: 2025-04-28T10:33:48.525Z
Learning: In the lifinance/contracts repository, deployment environments are distinguished by filename patterns. Production deployments use standard names like "polygon.diamond.json", while staging deployments use names with "staging" suffix like "polygon.diamond.staging.json". When checking deployment logs for consistency, ensure to look in the correct environment section (production/staging) based on the filename pattern.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-11-26T01:16:27.721Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:40-43
Timestamp: 2024-11-26T01:16:27.721Z
Learning: Version inconsistencies of 'GenericSwapFacetV3' across deployment configurations are acceptable if they are only due to differences in Solidity pragma directives.

Applied to files:

• deployments/_deployments_log_file.json
• deployments/monad.json

📚 Learning: 2024-11-01T11:53:57.162Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 846
File: deployments/cronos.diamond.json:28-31
Timestamp: 2024-11-01T11:53:57.162Z
Learning: In `deployments/cronos.diamond.json`, both `GenericSwapFacet` and `GenericSwapFacetV3` are distinct facets that should be included together, as they serve different purposes.

Applied to files:

• deployments/_deployments_log_file.json
• deployments/monad.json

📚 Learning: 2025-08-29T10:02:09.041Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1299
File: src/Facets/AcrossFacetPackedV4.sol:118-136
Timestamp: 2025-08-29T10:02:09.041Z
Learning: In AcrossFacetPackedV4.sol, the team explicitly chooses to omit calldata length validation in gas-optimized packed functions like startBridgeTokensViaAcrossV4NativePacked to save gas, accepting the trade-off of potential out-of-bounds reverts for better gas efficiency.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-07-16T01:04:55.857Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1275
File: src/Facets/AllBridgeFacet.sol:186-188
Timestamp: 2025-07-16T01:04:55.857Z
Learning: In LiFi facet contracts, when public entry point functions have `nonReentrant` modifier protection, internal functions like `_startBridge` that they call benefit from this reentrancy protection, making event emission order after external calls acceptable from a security perspective.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-09-25T07:48:53.243Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1324
File: src/Facets/EcoFacet.sol:280-303
Timestamp: 2025-09-25T07:48:53.243Z
Learning: In src/Facets/EcoFacet.sol, the team prefers to allow natural Solidity reverts (array bounds, insufficient data) in route validation rather than adding explicit guards with custom errors, as the reverts achieve the same security outcome while keeping code simpler.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-10-02T18:10:09.934Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1406
File: src/Facets/UnitFacet.sol:75-81
Timestamp: 2025-10-02T18:10:09.934Z
Learning: In UnitFacet.sol and similar facet contracts in src/Facets/, the LiFiTransferStarted event emission should ALWAYS be at the end of the _startBridge internal function, after all validations and asset transfers have been completed successfully.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-10-13T11:13:48.847Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1413
File: src/Facets/EverclearV2Facet.sol:75-96
Timestamp: 2025-10-13T11:13:48.847Z
Learning: In EverclearV2Facet (and all LiFi facets), the team standard is to use msg.sender as the refund address with the refundExcessNative modifier, not requiring an explicit refund address parameter.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 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:

• src/Facets/LiFiIntentEscrowFacet.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:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 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:

• src/Facets/LiFiIntentEscrowFacet.sol
• deployments/monad.json

📚 Learning: 2024-12-04T02:05:41.355Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 832
File: src/Periphery/LiFiDEXAggregator.sol:578-697
Timestamp: 2024-12-04T02:05:41.355Z
Learning: Unit tests are not required for newly added swap callback functions in `LiFiDEXAggregator.sol`.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-01-09T04:34:00.778Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 909
File: script/deploy/zksync/DeployTokenWrapper.s.sol:43-49
Timestamp: 2025-01-09T04:34:00.778Z
Learning: In deployment scripts for LiFi contracts, validation for refundWallet address is not required as it's handled elsewhere or through configuration validation.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-02-24T09:35:34.908Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: src/Periphery/ReceiverChainflip.sol:48-62
Timestamp: 2025-02-24T09:35:34.908Z
Learning: Contract address validations for periphery contracts like ReceiverChainflip are handled in deployment scripts rather than in the constructor.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-08-23T11:07:02.778Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1322
File: src/Facets/MayanFacet.sol:259-272
Timestamp: 2025-08-23T11:07:02.778Z
Learning: In src/Facets/MayanFacet.sol, the offset 0xe4 for parsing receiver addresses from HCDepositInitiator::deposit calldata is correct. The mload operation reads 32-byte words and the address extraction via address(uint160(uint256(receiver))) properly handles ABI padding, so theoretical byte-level offset calculations can be misleading when the actual implementation works correctly with real-world data.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-02-21T09:00:28.226Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: src/Facets/ChainflipFacet.sol:127-146
Timestamp: 2025-02-21T09:00:28.226Z
Learning: The `validateBridgeData` modifier in `Validatable.sol` already validates that the receiver address is not zero, making additional zero-address checks redundant in functions using this modifier.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-01-21T11:07:36.236Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 937
File: script/deploy/facets/DeployLiFiDEXAggregator.s.sol:33-35
Timestamp: 2025-01-21T11:07:36.236Z
Learning: In the LiFiDEXAggregator contract deployment (DeployLiFiDEXAggregator.s.sol), the refundWallet address from global.json is used as the owner parameter in the contract's constructor, which is then passed to the WithdrawablePeriphery base contract.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-08-29T11:53:38.549Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: test/solidity/Periphery/LDA/BaseCoreRouteTest.t.sol:379-388
Timestamp: 2025-08-29T11:53:38.549Z
Learning: In test/solidity/Periphery/LDA/BaseCoreRouteTest.t.sol, for the revert-testing helper function _executeAndVerifySwap, only the aggregator branch (CommandType.DistributeSelfERC20) should use amountIn-1 to underfund and trigger insufficient balance errors, while user-funded branches should use the full amountIn to test other error conditions.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-02-21T09:00:28.226Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: src/Facets/ChainflipFacet.sol:127-146
Timestamp: 2025-02-21T09:00:28.226Z
Learning: The `validateBridgeData` modifier in `Validatable.sol` validates that the receiver address is not zero using `LibUtil.isZeroAddress`, making additional zero-address checks redundant in functions using this modifier.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2025-04-28T07:46:24.084Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1116
File: src/Libraries/LibAsset.sol:102-108
Timestamp: 2025-04-28T07:46:24.084Z
Learning: In the LiFi contracts, the `LibAsset.transferFromERC20` function is intentionally designed to accept arbitrary `from` parameters, with security ensured through a whitelist mechanism that controls which contracts can call this function.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 Learning: 2024-10-04T09:10:17.997Z

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.

Applied to files:

• src/Facets/LiFiIntentEscrowFacet.sol

📚 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.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.json

📚 Learning: 2025-08-01T05:35:21.121Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1290
File: script/deploy/_targetState.json:20-31
Timestamp: 2025-08-01T05:35:21.121Z
Learning: 0xDEnYO has confirmed that the target state file (script/deploy/_targetState.json) is not important for verification and should not be reviewed in deployment PRs.

Applied to files:

• script/deploy/_targetState.json

📚 Learning: 2025-06-24T07:35:58.970Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1232
File: script/deploy/_targetState.json:1680-1703
Timestamp: 2025-06-24T07:35:58.970Z
Learning: The user (0xDEnYO) has instructed to never review the target state file (script/deploy/_targetState.json). This file should be excluded from code review analysis.

Applied to files:

• script/deploy/_targetState.json

📚 Learning: 2025-05-27T12:36:26.987Z

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.

Applied to files:

• script/deploy/_targetState.json

📚 Learning: 2025-09-01T09:35:29.886Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1299
File: deployments/arbitrum.staging.json:59-61
Timestamp: 2025-09-01T09:35:29.886Z
Learning: 0xDEnYO has repeatedly emphasized that the target state file (script/deploy/_targetState.json) should NEVER be reviewed, verified, or mentioned in deployment PRs. This instruction has been given multiple times and must be strictly followed without exception.

Applied to files:

• script/deploy/_targetState.json

📚 Learning: 2024-11-21T08:24:53.059Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/_targetState.json:1453-1483
Timestamp: 2024-11-21T08:24:53.059Z
Learning: In `script/deploy/_targetState.json`, for the `abstract` network configuration, `ReceiverStargateV2` is correctly set to version `1.0.1`.

Applied to files:

• script/deploy/_targetState.json

📚 Learning: 2025-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, 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.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/whitelist.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/whitelist.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-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: 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 src/Periphery/Lda/Facets/CurveFacet.sol, the ICurveLegacy interface has a non-payable exchange function, so legacy Curve pools cannot accept native ETH as input. Only modern pools (ICurve) support native assets through their payable exchange function.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-11-14T12:58:18.040Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1463
File: config/whitelist.json:24-26
Timestamp: 2025-11-14T12:58:18.040Z
Learning: In lifinance/contracts reviews, selectors must be verified by code or concrete on-chain evidence (ABI/tx) rather than assumed; provide a reproducible script or reference when proposing selector mappings.

Applied to files:

• config/whitelist.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.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.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.json

📚 Learning: 2025-08-28T02:21:50.428Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1340
File: config/mayan.json:18-20
Timestamp: 2025-08-28T02:21:50.428Z
Learning: In the lifinance/contracts repository, config/*.json files (like config/mayan.json) contain configuration data such as external service addresses (e.g., bridge router addresses) that are used as constructor parameters. The deployments/_deployments_log_file.json file stores information about contracts that LI.FI deployed themselves. These two types of addresses serve different purposes and will never match - config files contain external addresses while deployment logs contain LI.FI's own deployed contract addresses.

Applied to files:

• deployments/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: 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-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

🧬 Code graph analysis (1)

script/tasks/diamondUpdateFacet.sh (2)

script/helperFunctions.sh (2)

• echoDebug (3083-3091)
• getPrivateKey (3732-3763)

script/deploy/safe/safe-utils.ts (1)

• getPrivateKey (1095-1109)

🪛 GitHub Actions: VersionControlAndAuditVerification

src/Facets/LiFiIntentEscrowFacet.sol

[error] 1-1: The following contract(s) have been modified but their version tags were not updated: src/Facets/LiFiIntentEscrowFacet.sol. Please update the custom:version tag in the file to reflect changes.

🪛 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)

🪛 Shellcheck (0.11.0)

script/tasks/diamondUpdatePeriphery.sh

[warning] 178-178: Declare and assign separately to avoid masking return values.

(SC2155)

---

[warning] 190-190: Declare and assign separately to avoid masking return values.

(SC2155)

script/tasks/diamondUpdateFacet.sh

[warning] 135-135: This assignment is only seen by the forked process.

(SC2097)

---

[warning] 135-135: This expansion will not see the mentioned assignment.

(SC2098)

---

[warning] 138-138: This assignment is only seen by the forked process.

(SC2097)

---

[warning] 138-138: This expansion will not see the mentioned assignment.

(SC2098)

---

[warning] 176-176: This assignment is only seen by the forked process.

(SC2097)

---

[warning] 176-176: This expansion will not see the mentioned assignment.

(SC2098)

---

[warning] 176-176: Quote this to prevent word splitting.

(SC2046)

⏰ 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). (2)

• GitHub Check: enforce-min-test-coverage
• GitHub Check: run-unit-tests

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

foundry.toml (1)

72-72: Minor formatting inconsistency: Add space after monad.

Line 72 lacks whitespace before the = operator, unlike other entries in this section.

-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.

📥 Commits

Reviewing files that changed from the base of the PR and between f366553 and a43e797.

📒 Files selected for processing (3)

• config/networks.json (1 hunks)
• deployments/_deployments_log_file.json (29 hunks)
• foundry.toml (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• config/networks.json

🧰 Additional context used

🧠 Learnings (17)

📓 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: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: 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/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: 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.

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-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-07-04T08:59:08.108Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-09-09T10:39:26.383Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.

Applied to files:

• deployments/_deployments_log_file.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: 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/_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-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:33.959Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28060-28072
Timestamp: 2025-05-28T17:33:33.959Z
Learning: Deployment log files like `deployments/_deployments_log_file.json` are historical records that document the actual versions deployed at specific times. They should not be updated to match current contract versions - they must accurately reflect what was deployed when the deployment occurred.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:10.529Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28706-28717
Timestamp: 2025-05-28T17:33:10.529Z
Learning: Deployment log files (like `_deployments_log_file.json`) are historical records that should not be updated to match current contract versions. They should accurately reflect the versions that were actually deployed at specific timestamps.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-09-30T03:52:27.281Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/_deployments_log_file.json:1914-1927
Timestamp: 2024-09-30T03:52:27.281Z
Learning: Duplicate entries in `deployments/_deployments_log_file.json` that are outdated do not require changes.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-11-26T01:16:27.721Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:40-43
Timestamp: 2024-11-26T01:16:27.721Z
Learning: Version inconsistencies of 'GenericSwapFacetV3' across deployment configurations are acceptable if they are only due to differences in Solidity pragma directives.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 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/_deployments_log_file.json

📚 Learning: 2025-08-29T10:02:09.041Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1299
File: src/Facets/AcrossFacetPackedV4.sol:118-136
Timestamp: 2025-08-29T10:02:09.041Z
Learning: In AcrossFacetPackedV4.sol, the team explicitly chooses to omit calldata length validation in gas-optimized packed functions like startBridgeTokensViaAcrossV4NativePacked to save gas, accepting the trade-off of potential out-of-bounds reverts for better gas efficiency.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-08-19T05:10:12.922Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1303
File: script/utils/network.ts:27-32
Timestamp: 2025-08-19T05:10:12.922Z
Learning: In the lifinance/contracts repository, the team decided to standardize RPC environment variable naming by converting all hyphens to underscores in network names. For example, "tron-shasta" becomes "ETH_NODE_URI_TRON_SHASTA". The getRPCEnvVarName() helper in script/utils/network.ts implements this standard and should be used consistently across the codebase instead of direct string manipulation.

Applied to files:

• 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-01-22T07:30:01.787Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 944
File: foundry.toml:77-109
Timestamp: 2025-01-22T07:30:01.787Z
Learning: Etherscan V2 API (api.etherscan.io/v2/api) supports contract verification across 30+ networks using the chainId parameter in the URL. Network-specific API endpoints are not required when using V2 API.

Applied to files:

• foundry.toml

🔇 Additional comments (2)

foundry.toml (1)

146-146: Verify custom verifier configuration completeness.

The custom verifier in Foundry requires a custom verification provider compatible with the Etherscan API. The current configuration specifies verifier = "custom" but typically custom verifiers require a verifier_url field to specify the verification endpoint. Verify if this custom verifier is properly configured or if it should fall back to the default Etherscan verifier.

Consider clarifying the intent:

• If using standard Etherscan V2 API verification (which is already configured with the URL), you may not need verifier = "custom"—omit it to use the default.
• If verifier = "custom" is needed, ensure a verifier_url field is provided to specify the custom verification endpoint.

- monad = { key = "${MAINNET_ETHERSCAN_API_KEY}", url = "https://api.etherscan.io/v2/api?chainid=143", verifier = "custom", chain = "143" }
+ monad = { key = "${MAINNET_ETHERSCAN_API_KEY}", url = "https://api.etherscan.io/v2/api?chainid=143", chain = "143" }

deployments/_deployments_log_file.json (1)

1186-1200: Deployment log entries for Monad network properly structured and consistent.

All 29 monad deployment entries follow the established JSON pattern used for other networks (botanix, etc.). The entries correctly capture contract addresses, optimizer runs, deployment timestamps, constructor arguments, and verification status. The VERIFIED field appropriately marks the main LiFiDiamond as "true" while other contracts are "false" (typical for new testnet deployments). Timestamps and addresses conform to expected formats.

Verify that the deployed addresses and constructor arguments in these log entries match the addresses defined in deployments/monad.json and deployments/monad.diamond.json to ensure consistency across deployment manifests.

Also applies to: 2390-2404, 3593-3607, 5109-5123, 6322-6336, 7515-7529, 8718-8732, 9881-9895, 12134-12148, 16026-16040, 17356-17370, 18474-18488, 26965-26979, 29964-29978, 30445-30459, 31587-31601, 34328-34342, 35405-35419, 38192-38206, 39566-39580, 40470-40484, 41125-41139, 42223-42237, 43247-43261, 43473-43487, 43920-43934, 44248-44262, 45206-45220, 46593-46607

[coderabbitai]

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.

📥 Commits

Reviewing files that changed from the base of the PR and between e5e6f19 and 30f11f0.

📒 Files selected for processing (2)

• config/dexs.json (1 hunks)
• config/whitelist.json (6 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• config/dexs.json

🧰 Additional context used

🧠 Learnings (8)

📓 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-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 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: 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: 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/boba.diamond.json:68-68
Timestamp: 2024-10-04T09:10:17.997Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: mirooon
Repo: lifinance/contracts PR: 985
File: deployments/bsca.json:0-0
Timestamp: 2025-02-12T09:44:10.963Z
Learning: When setting up new network deployments, it's expected that contract addresses in the deployment JSON files (e.g., bsca.json, bscb.json) may not have deployed code initially, as these files serve as target configurations for future deployments.

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-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/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.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/whitelist.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-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: 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 src/Periphery/Lda/Facets/CurveFacet.sol, the ICurveLegacy interface has a non-payable exchange function, so legacy Curve pools cannot accept native ETH as input. Only modern pools (ICurve) support native assets through their payable exchange function.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-11-14T12:58:18.040Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1463
File: config/whitelist.json:24-26
Timestamp: 2025-11-14T12:58:18.040Z
Learning: In lifinance/contracts reviews, selectors must be verified by code or concrete on-chain evidence (ABI/tx) rather than assumed; provide a reproducible script or reference when proposing selector mappings.

Applied to files:

• config/whitelist.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: run-unit-tests

🔇 Additional comments (6)

config/whitelist.json (6)

4041-4047: Ooga Booga Meta: monad mapping mirrors hyperevm; LGTM.

---

4124-4132: Fly monad mapping verified; no duplicates under monad.

The address 0x956df8424b556f0076e8abf5481605f5a791cc7f appears on multiple chains (unichain, monad, hyperevm, abstract), which is expected for cross-chain contracts. Under monad specifically, it appears only once at line 4126. Functions and address/ABI alignment with existing chains are correct.

---

6767-6834: Addresses and signatures verified; code changes align with deployment configuration and existing patterns.

All five Monad periphery and aggregator addresses are confirmed present in deployments/monad.json and deployments/monad.diamond.json. Function signatures match source implementations:

• FeeCollector: collectNativeFees(uint256,uint256,address), collectTokenFees(address,uint256,uint256,address)
• FeeForwarder: forwardNativeFees((address,uint256)[]), forwardERC20Fees(address,(address,uint256)[])
• GasZipPeriphery: depositToGasZipERC20, depositToGasZipNative with correct struct tuple encoding
• TokenWrapper: withdraw(), deposit()
• LiFiDEXAggregator: processRoute(address,uint256,address,uint256,address,bytes)

Selectors are properly formatted and correspond to the function signatures in the codebase.

---

4295-4310: Selector mismatch: 0xf99cae99 is incorrect for the provided function signature.

The keccak256 hash of aggregate(address,address,uint256,uint256,address,uint256,uint64,uint64,(uint256,uint32,uint8,address,address,address,bytes)[]) computes to selector 0xc2d5542f, not 0xf99cae99.

Additionally:

• The address 0xa68a7f0601effdc65c64d9c47ca1b18d96b4352c exists in dexs.json:851 under the "monad" network but is not labeled with a "monorail" key
• "monorail" does not yet exist in dexs.json as a DEX entry
• config/sign.json does not exist

Verify the correct selector against on-chain ABI or transaction data before proceeding.

⛔ Skipped due to learnings

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1463
File: config/whitelist.json:24-26
Timestamp: 2025-11-14T12:58:18.040Z
Learning: In lifinance/contracts reviews, selectors must be verified by code or concrete on-chain evidence (ABI/tx) rather than assumed; provide a reproducible script or reference when proposing selector mappings.

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`.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1322
File: src/Facets/MayanFacet.sol:259-272
Timestamp: 2025-08-23T11:07:02.778Z
Learning: In src/Facets/MayanFacet.sol, the offset 0xe4 for parsing receiver addresses from HCDepositInitiator::deposit calldata is correct. The mload operation reads 32-byte words and the address extraction via address(uint160(uint256(receiver))) properly handles ABI padding, so theoretical byte-level offset calculations can be misleading when the actual implementation works correctly with real-world data.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/bsc.json:48-48
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The `LiFiDEXAggregator` contract does not include a `swapAndCompare` function.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/bsc.json:48-48
Timestamp: 2024-10-04T09:00:06.744Z
Learning: The `LiFiDEXAggregator` contract does not include a `swapAndCompare` function.

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to src/Facets/**/*.sol : For non-EVM chains, use bytes (not bytes32) for receiverAddress and validate it is not zero

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.

---

4312-4326: All required entries are present; file reference correction needed.

Verification confirms:

• Address 0xb3e6778480b2e488385e8205ea05e20060b813cb is in config/dexs.json under the monad network ✓
• Selector 0xce1e7030 is listed in config/sigs.json ✓
• Whitelist.json entry is complete with address, functions, and signature ✓

Note: The file is sigs.json, not sign.json (which doesn't exist in the repository). The dexs.json structure uses flat address arrays per network rather than named DEX objects; the address-only format is intentional and correct. No further action required.

---

1689-1696: Monad network integration is properly wired; function selectors require manual verification.

Verification confirms that "monad" is fully configured in config/networks.json (chainId 143, RPC URL, explorer) and all DEX addresses referenced in whitelist.json monad entries are present in config/dexs.json. The network integration is complete.

However, the function selectors for Monorail (0xf99cae99) and Kuru (0xce1e7030) could not be verified due to sandbox tool limitations. Please manually confirm these selectors match the actual contract ABIs on Monad or test against the deployed contracts to ensure correctness.

[coderabbitai]

Actionable comments posted: 1

♻️ Duplicate comments (1)

config/whitelist.json (1)

2080-2088: KyberSwap on Monad: add swapGeneric for parity.

swapGeneric (0x59e50fed) is present on other networks; add it here for parity with the same MetaAggregationRouterV2.

         "monad": [
           {
             "address": "0x6131b5fae19ea4f9d964eac0408e4408b66337b5",
             "functions": {
               "0xe21fd0e9": "swap((address,address,bytes,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes))",
+              "0x59e50fed": "swapGeneric((address,address,bytes,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes))",
               "0x8af033fb": "swapSimpleMode(address,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes,bytes)"
             }
           }
         ],

If unsure, confirm via ABI on the deployed router for 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.

📥 Commits

Reviewing files that changed from the base of the PR and between 077f2ba and 78ae369.

📒 Files selected for processing (2)

• config/dexs.json (1 hunks)
• config/whitelist.json (7 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• config/dexs.json

🧰 Additional context used

🧠 Learnings (11)

📓 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-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: 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: 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: ezynda3
Repo: lifinance/contracts PR: 861
File: script/deploy/_targetState.json:1364-1390
Timestamp: 2024-11-21T08:25:26.214Z
Learning: For the Cronos network configuration in `script/deploy/_targetState.json`, the absence of bridge facets such as `StargateFacet`, `AcrossFacet`, `HopFacet`, and `SymbiosisFacet` is acceptable and expected.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1196
File: script/helperFunctions.sh:1447-1462
Timestamp: 2025-06-19T06:23:47.848Z
Learning: 0xDEnYO prefers to keep eval usage in local bash scripts when the security risk is acceptable in their controlled environment, prioritizing simplicity over security hardening for local tooling.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1266
File: script/deploy/safe/execute-pending-timelock-tx.ts:627-628
Timestamp: 2025-07-17T04:21:26.825Z
Learning: In the lifinance/contracts repository, 0xDEnYO prefers to keep '0x0' as a fallback address in gas estimation calls rather than throwing errors when the wallet account address is not available, prioritizing code simplicity over strict validation.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1325
File: script/tasks/diamondSyncDEXs.sh:116-116
Timestamp: 2025-08-27T08:45:59.606Z
Learning: In script/tasks/diamondSyncDEXs.sh, user 0xDEnYO has chosen to selectively apply ShellCheck fixes, keeping array assignments using $() construct and other patterns as-is in their controlled deployment environment, prioritizing functionality over strict ShellCheck compliance.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1212
File: .github/workflows/convertForkedPRsToInternal.yml:81-106
Timestamp: 2025-07-16T06:18:02.682Z
Learning: 0xDEnYO prefers to use printf "%q" for shell escaping in GitHub workflows to increase security and protection from potential injections, even when it might cause formatting issues, prioritizing security over convenience.

📚 Learning: 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.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/whitelist.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/whitelist.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-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-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:

• config/whitelist.json

📚 Learning: 2024-10-09T03:47:21.269Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/bsc.json:48-48
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The `LiFiDEXAggregator` contract does not include a `swapAndCompare` function.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-08-29T11:53:38.549Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: test/solidity/Periphery/LDA/BaseCoreRouteTest.t.sol:379-388
Timestamp: 2025-08-29T11:53:38.549Z
Learning: In test/solidity/Periphery/LDA/BaseCoreRouteTest.t.sol, for the revert-testing helper function _executeAndVerifySwap, only the aggregator branch (CommandType.DistributeSelfERC20) should use amountIn-1 to underfund and trigger insufficient balance errors, while user-funded branches should use the full amountIn to test other error conditions.

Applied to files:

• config/whitelist.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 src/Periphery/Lda/Facets/CurveFacet.sol, the ICurveLegacy interface has a non-payable exchange function, so legacy Curve pools cannot accept native ETH as input. Only modern pools (ICurve) support native assets through their payable exchange function.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-11-14T12:58:18.040Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1463
File: config/whitelist.json:24-26
Timestamp: 2025-11-14T12:58:18.040Z
Learning: In lifinance/contracts reviews, selectors must be verified by code or concrete on-chain evidence (ABI/tx) rather than assumed; provide a reproducible script or reference when proposing selector mappings.

Applied to files:

• config/whitelist.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: run-unit-tests

🔇 Additional comments (6)

config/whitelist.json (6)

4049-4057: Selector 0xd46cadbc already exists in config/sigs.json.

Verification confirms the selector is present in config/sigs.json. No action required.

---

4133-4141: Verification confirmed: both selectors present in sigs.json.

Selectors 0x73fc4457 and 0x25e651ed are confirmed in config/sigs.json (lines 181–182). The Monad Fly entry at address 0x956df8424b556f0076e8abf5481605f5a791cc7f correctly maps these selectors to their function signatures.

---

6776-6843: No issues found—periphery addresses for Monad are correctly configured and consistent.

Verification confirms all PERIPHERY addresses for Monad in config/whitelist.json match the corresponding entries in deployments/monad.json:

• LiFiDEXAggregator: 0x588c00159AED9A9ab258850b33DEDfAC1c794fA1 ✓
• FeeCollector, FeeForwarder, GasZipPeriphery, TokenWrapper: all verified ✓

---

1689-1696: Selector 0x90411a32 verified: consistent across all chains and approved in sigs.json.

The OpenOcean Monad entry is correct. Address 0x6352a56caadc4f1e25cd6c75970fa768a3304e64 with selector 0x90411a32 is consistently mapped across mainnet, optimism, flare, cronos, rootstock, bsc, gnosis, polygon, monad, and sonic, and the selector is already listed in config/sigs.json as an approved selector.

---

4304-4319: Monorail DEX configuration verified—all entries present and correct.

• Selector 0xf99cae99 correctly maps to the aggregate function signature (verified via keccak256)
• Signature already present in config/sigs.json
• Address 0xa68a7f0601effdc65c64d9c47ca1b18d96b4352c already present in config/dexs.json under monad

---

4321-4335: All config file updates verified; confirm selector against Kuru contract on Monad.

Cross-file updates are complete and correct:

• ✅ Kuru address (0xb3e6778480b2e488385e8205ea05e20060b813cb) present in dexs.json
• ✅ Old address (0x43DCFE9c0a0777Aa652926b674AC91189698b71a) removed from dexs.json
• ✅ Selector 0xce1e7030 present in sigs.json
• ✅ Whitelist entry complete with address and function signature

However, the selector 0xce1e7030 for executeSwap cannot be verified against public documentation. Per prior learnings, selectors should be backed by concrete on-chain ABI/tx evidence. Verify the selector against Kuru's contract ABI on Monad explorer or provide transaction evidence confirming this function signature.

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

config/whitelist.json (1)

2080-2088: Kyberswap/monad missing swapGeneric selector (parity).

Other networks list 0x59e50fed swapGeneric; monad block doesn’t. Add for parity unless intentionally unsupported.

         "monad": [
           {
             "address": "0x6131b5fae19ea4f9d964eac0408e4408b66337b5",
             "functions": {
               "0xe21fd0e9": "swap((address,address,bytes,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes))",
+              "0x59e50fed": "swapGeneric((address,address,bytes,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes))",
               "0x8af033fb": "swapSimpleMode(address,(address,address,address[],uint256[],address[],uint256[],address,uint256,uint256,uint256,bytes),bytes,bytes)"
             }
           }
         ],

🧹 Nitpick comments (2)

foundry.toml (1)

72-72: Fix spacing in RPC endpoint definition.

Line 72 uses inconsistent formatting (monad=) compared to all other RPC endpoint entries. Follow the standard format with spaces around the equals sign: monad = "${ETH_NODE_URI_MONAD}".

config/whitelist.json (1)

4050-4057: Add signature for 0xd46cadbc (optional clarity).

The function hash is listed without a signature. If available, add the human‑readable signature for consistency and faster audits.

If you want, share the ABI or confirm the exact signature so I can compute and propose it.

📜 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.

📥 Commits

Reviewing files that changed from the base of the PR and between 78ae369 and 227c8fb.

📒 Files selected for processing (5)

• config/dexs.json (1 hunks)
• config/networks.json (1 hunks)
• config/whitelist.json (28 hunks)
• deployments/_deployments_log_file.json (31 hunks)
• foundry.toml (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• config/networks.json

🧰 Additional context used

🧠 Learnings (43)

📓 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-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/avalanche.diamond.json:105-105
Timestamp: 2024-10-04T09:17:19.275Z
Learning: In the `lifinance/contracts` repository, contracts may have different addresses across networks. Do not check if contracts have the same addresses across all networks in future reviews.

Learnt from: 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: 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: 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: 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-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-01-22T07:30:01.787Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 944
File: foundry.toml:77-109
Timestamp: 2025-01-22T07:30:01.787Z
Learning: Etherscan V2 API (api.etherscan.io/v2/api) supports contract verification across 30+ networks using the chainId parameter in the URL. Network-specific API endpoints are not required when using V2 API.

Applied to files:

• foundry.toml

📚 Learning: 2025-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Applied to files:

• deployments/_deployments_log_file.json
• config/whitelist.json

📚 Learning: 2025-07-04T08:59:08.108Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Applied to files:

• deployments/_deployments_log_file.json
• config/whitelist.json

📚 Learning: 2025-09-09T10:39:26.383Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.

Applied to files:

• deployments/_deployments_log_file.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: 2025-08-07T10:20:01.383Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, understand that _targetState.json tracks contract version numbers (not addresses) and _deployments_log_file.json contains deployment records with addresses that may not be organized in obvious network sections. Always verify the actual file structure before flagging missing entries.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:33.959Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28060-28072
Timestamp: 2025-05-28T17:33:33.959Z
Learning: Deployment log files like `deployments/_deployments_log_file.json` are historical records that document the actual versions deployed at specific times. They should not be updated to match current contract versions - they must accurately reflect what was deployed when the deployment occurred.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-05-28T17:33:10.529Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1170
File: deployments/_deployments_log_file.json:28706-28717
Timestamp: 2025-05-28T17:33:10.529Z
Learning: Deployment log files (like `_deployments_log_file.json`) are historical records that should not be updated to match current contract versions. They should accurately reflect the versions that were actually deployed at specific timestamps.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-01-09T04:17:46.190Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 914
File: deployments/_deployments_log_file.json:26902-26916
Timestamp: 2025-01-09T04:17:46.190Z
Learning: Updates to _deployments_log_file.json can represent backfilling of historical deployment data, not just new deployments. Such updates don't require new audits.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-04-21T03:15:12.236Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.diamond.json:84-85
Timestamp: 2025-04-21T03:15:12.236Z
Learning: In deployment JSON files that contain "diamond" in their filename (located in the deployments folder), periphery contracts may have empty string values for their addresses. This indicates that the contract is not deployed on that particular chain and should not be flagged as an issue during code reviews.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-09-30T03:52:27.281Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/_deployments_log_file.json:1914-1927
Timestamp: 2024-09-30T03:52:27.281Z
Learning: Duplicate entries in `deployments/_deployments_log_file.json` that are outdated do not require changes.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-11-26T01:16:27.721Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:40-43
Timestamp: 2024-11-26T01:16:27.721Z
Learning: Version inconsistencies of 'GenericSwapFacetV3' across deployment configurations are acceptable if they are only due to differences in Solidity pragma directives.

Applied to files:

• deployments/_deployments_log_file.json
• config/whitelist.json

📚 Learning: 2024-11-01T11:53:57.162Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 846
File: deployments/cronos.diamond.json:28-31
Timestamp: 2024-11-01T11:53:57.162Z
Learning: In `deployments/cronos.diamond.json`, both `GenericSwapFacet` and `GenericSwapFacetV3` are distinct facets that should be included together, as they serve different purposes.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-11-25T01:36:33.521Z

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to src/Facets/**/*.sol : Facets must use nonReentrant, refundExcessNative, validateBridgeData, and swapContainment modifiers

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-11-25T01:36:33.521Z

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-11-25T01:36:33.521Z
Learning: Applies to src/Facets/**/*.sol : Facets must inherit from ILiFi interface, use LibAsset and LibSwap libraries, include ReentrancyGuard and SwapperV2, and implement Validatable interface

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-08-29T10:02:09.041Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1299
File: src/Facets/AcrossFacetPackedV4.sol:118-136
Timestamp: 2025-08-29T10:02:09.041Z
Learning: In AcrossFacetPackedV4.sol, the team explicitly chooses to omit calldata length validation in gas-optimized packed functions like startBridgeTokensViaAcrossV4NativePacked to save gas, accepting the trade-off of potential out-of-bounds reverts for better gas efficiency.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-04-21T03:17:53.443Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.

Applied to files:

• deployments/_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: 2025-08-28T02:41:07.505Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1321
File: docs/RelayDepositoryFacet.md:9-10
Timestamp: 2025-08-28T02:41:07.505Z
Learning: Unit tests for RelayDepositoryFacet cannot verify fund forwarding behavior after deposits because the facet delegates to external IRelayDepository contracts. The forwarding logic is implemented in the Relay Protocol V2 Depository contracts, not in the facet itself.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-02-12T09:44:12.961Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 985
File: script/deploy/_targetState.json:0-0
Timestamp: 2025-02-12T09:44:12.961Z
Learning: The bsca network intentionally maintains different facet versions between staging and production environments, specifically:
1. CalldataVerificationFacet: v1.1.1 in staging vs v1.1.2 in production
2. EmergencyPauseFacet: present only in production
3. Permit2Proxy: present only in production

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-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/dexs.json
• config/whitelist.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/dexs.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/dexs.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/dexs.json
• config/whitelist.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-11-25T02:57:57.994Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1466
File: config/whitelist.json:2546-2554
Timestamp: 2025-11-25T02:57:57.994Z
Learning: In lifinance/contracts config/whitelist.json, the SushiSwap Aggregator uses functions:
- snwap(address,uint256,address,address,uint256,address,bytes) -> selector 0x5f3bd1c8
- snwapMultiple((address,uint256,address)[],(address,address,uint256)[],(address,uint256,bytes)[]) -> selector 0xd33721a5
These selectors are canonical across networks and valid for the monad entry as well. Always compute with Keccak-256 (not SHA3-256) when verifying.

Applied to files:

• config/whitelist.json

📚 Learning: 2024-10-09T03:47:21.269Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/bsc.json:48-48
Timestamp: 2024-10-09T03:47:21.269Z
Learning: The `LiFiDEXAggregator` contract does not include a `swapAndCompare` function.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-08-29T11:53:38.549Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: test/solidity/Periphery/LDA/BaseCoreRouteTest.t.sol:379-388
Timestamp: 2025-08-29T11:53:38.549Z
Learning: In test/solidity/Periphery/LDA/BaseCoreRouteTest.t.sol, for the revert-testing helper function _executeAndVerifySwap, only the aggregator branch (CommandType.DistributeSelfERC20) should use amountIn-1 to underfund and trigger insufficient balance errors, while user-funded branches should use the full amountIn to test other error conditions.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-11-14T12:58:18.040Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1463
File: config/whitelist.json:24-26
Timestamp: 2025-11-14T12:58:18.040Z
Learning: In lifinance/contracts reviews, selectors must be verified by code or concrete on-chain evidence (ABI/tx) rather than assumed; provide a reproducible script or reference when proposing selector mappings.

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/whitelist.json

📚 Learning: 2024-10-09T03:47:21.269Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.

Applied to files:

• config/whitelist.json

📚 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:

• config/whitelist.json

📚 Learning: 2024-10-09T03:47:21.269Z

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.

Applied to files:

• config/whitelist.json

📚 Learning: 2024-11-26T01:03:43.597Z

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.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-08-26T02:20:52.515Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1334
File: deployments/mainnet.json:54-54
Timestamp: 2025-08-26T02:20:52.515Z
Learning: For deployment PRs in the lifinance/contracts repository, carefully verify the specific scope mentioned in the PR title and description before suggesting updates to other networks. Not all deployments are cross-network updates - some are targeted to specific chains only.

Applied to files:

• config/whitelist.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:

• config/whitelist.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-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: 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 src/Periphery/Lda/Facets/CurveFacet.sol, the ICurveLegacy interface has a non-payable exchange function, so legacy Curve pools cannot accept native ETH as input. Only modern pools (ICurve) support native assets through their payable exchange function.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-05-14T15:19:24.984Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1137
File: src/Periphery/GasZipPeriphery.sol:62-71
Timestamp: 2025-05-14T15:19:24.984Z
Learning: The syntax `bytes4(calldata_bytes[:4])` is valid in Solidity 0.8.x for extracting a function selector from calldata bytes.

Applied to files:

• config/whitelist.json

⏰ 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 (11)

config/dexs.json (1)

844-857: Monad network configuration added correctly to dexs.json.

The new monad entry is properly positioned in alphabetical order and includes the required DEX addresses (Kuru and Monorail) per the PR comments. Format and address casing align with the existing configuration patterns.

foundry.toml (1)

146-146: Verify the "verifier = custom" setting for Monad.

The etherscan configuration uses verifier = "custom", which differs from the standard pattern for Etherscan V2 API entries (e.g., mainnet, arbitrum, base don't specify a verifier field). Other custom verifiers in the file use known types like "blockscout", "oklink", or "sourcify". Please confirm whether:

1. "custom" is a valid verifier option in your foundry configuration
2. This is intentional for Monad's verification setup, or if it should be removed to follow the standard V2 API pattern

config/whitelist.json (7)

1689-1696: OpenOcean on monad: OK

Address and swap selector mirror existing networks; no issues.

---

2546-2554: Sushi aggregator on monad: selectors validated.

snwap (0x5f3bd1c8) and snwapMultiple (0xd33721a5) are canonical here. Looks good.

Based on learnings, ...

---

4133-4141: Fly on monad: OK

Address/selector pair matches pattern used across networks.

---

7130-7197: PERIPHERY/monad additions: OK

New monad FeeCollector, FeeForwarder, GasZipPeriphery, TokenWrapper, LiFiDEXAggregator entries look consistent with other networks.

---

4656-4658: I'll verify the selector-signature consistency for runVM and the other flagged instances. Let me start by finding the Composer contract and examining the actual function signatures.
<function_calls>

find . -type f -name "*.sol" | xargs grep -l "function runVM" | head -20

</function_calls>

Wait, let me reconsider my approach. I need to check if the codebase is available first.
<function_calls>

ls -la | head -20

</function_calls>

Let me search for the Composer contract definition to find the runVM function signature:
<function_calls>

rg -n "function runVM" --type sol -A 5

</function_calls>

Let me also check the whitelist.json file to see the context around the flagged lines and understand the data structure:
<function_calls>

sed -n '4654,4660p' config/whitelist.json

</function_calls>

Now let me verify the selector by computing the keccak256 hash of the signature. I'll create a script to calculate what the selector should be:
<function_calls>

python3 << 'EOF'
from web3 import Web3

Test both signature formats

signatures = [
"runVM((uint8,bytes32)[],bytes[])", # Without extra parentheses
"runVM((uint8,bytes32)[],(bytes[]))" # With extra parentheses
]

for sig in signatures:
# Compute the full function selector (first 4 bytes of keccak256)
hash_obj = Web3.keccak(text=sig)
selector = "0x" + hash_obj.hex()[:8]
print(f"Signature: {sig}")
print(f"Selector: {selector}\n")
EOF


</function_calls>

Let me also search for any references to this selector or function in the codebase:
<function_calls>

rg "0x00a32e6c" -A 3 -B 3

</function_calls>

Let me check the structure around the flagged lines to understand context better:
<function_calls>

sed -n '4653,4673p' config/whitelist.json

</function_calls>

Now let me check one more of the flagged line ranges to see if there's a pattern:
<function_calls>

sed -n '4868,4874p' config/whitelist.json

</function_calls>

Let me also look for the Composer contract in the codebase to find the actual function definition:
<function_calls>

rg -n "contract Composer" --type sol -A 20

</function_calls>

---

4545-4559: I'm encountering persistent infrastructure issues that prevent me from accessing the lifinance/contracts repository. The clone operation is failing consistently with an internal server error (RST_STREAM code 2). This blocks all three verification steps:

1. Selector computation – Cannot verify if 0xce1e7030 is the correct Keccak-256 hash of the executeSwap function signature
2. sign.json verification – Cannot confirm the selector is included in the signature file
3. dexs.json updates – Cannot verify the address addition/removal per PR comments

Kuru/monad: selector and cross-file updates require manual verification.

• Verify that 0xce1e7030 is the correct Keccak-256 hash of executeSwap((address,uint256,address,uint256),(address,uint256,address,uint256,bool),bytes) using web3.js or equivalent tooling
• Confirm config/sign.json includes 0xce1e7030
• Ensure config/dexs.json reflects address updates (add 0xb3e6778480b2e488385e8205ea05e20060b813cb, remove 0x43DCFE9c0a0777Aa652926b674AC91189698b71a if applicable per PR)

---

4529-4543: Selector 0xf99cae99 is confirmed active on Monad for Monorail, but exact signature mapping cannot be verified.

The selector 0xf99cae99 is confirmed in on-chain transactions to the Monorail aggregator contract on Monad. However, without access to a verified contract ABI or the ability to compute Keccak-256 to validate the proposed signature aggregate(address,address,uint256,uint256,address,uint256,uint64,uint64,(uint256,uint32,uint8,address,address,address,bytes)[]), the mapping cannot be conclusively verified. Per prior guidance, selectors should be validated against source code or concrete on-chain evidence rather than assumed. Recommend confirming the function signature via the Monad block explorer's contract verification page or the Monorail team's official documentation.

deployments/_deployments_log_file.json (2)

1186-1200: Well-structured Monad network deployment log entries with consistent formatting.

The deployment log entries follow the established format with valid Ethereum addresses, reasonable timestamps (October 2025 deployments with November backfills), and consistent metadata structure. All entries are properly formatted with OPTIMIZER_RUNS, timestamps, and constructor arguments aligned with the deployment pattern.

Also applies to: 2390-2404, 3593-3607, 5109-5123, 6322-6336, 7515-7529, 8718-8732, 9881-9895, 12134-12148, 16026-16040, 17356-17370, 18474-18488, 26965-26979, 29964-29978, 30445-30459, 31587-31601, 34328-34342, 35405-35419, 38192-38206, 39566-39580, 40470-40484, 41125-41139, 42223-42237, 43247-43261, 43813-43827, 44710-44724, 45038-45052, 45366-45380, 46011-46025, 46318-46332, 47454-47468

---

5109-5123: Verify the single unverified deployment entry.

Line 5118 marks DexManagerFacet v1.0.2 (address 0x20f6A4cAa10f46e237273d0b3996C882e18E936A) with "VERIFIED": "false". Confirm this is intentional (contract pending verification on block explorer) rather than an oversight.