-
Notifications
You must be signed in to change notification settings - Fork 86
Deploy NEARIntentsFacet #1555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Deploy NEARIntentsFacet #1555
Conversation
…mpile with 0.8.17)
WalkthroughAdded NEARIntentsFacet entries and ReceiverOIF periphery fields across multiple deployment manifests; adjusted AllBridgeFacet key/version in some diamond manifests; inserted placeholder facets and updated staging facets; and changed Berachain Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Repository UI Review profile: CHILL Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (10)
🚧 Files skipped from review as they are similar to previous changes (7)
🧰 Additional context used🧠 Learnings (22)📓 Common learnings📚 Learning: 2025-04-21T03:17:53.443ZApplied to files:
📚 Learning: 2025-07-04T08:59:08.108ZApplied to files:
📚 Learning: 2025-08-07T10:20:01.383ZApplied to files:
📚 Learning: 2025-04-21T03:17:53.443ZApplied to files:
📚 Learning: 2024-09-27T07:10:15.586ZApplied to files:
📚 Learning: 2024-11-26T01:01:18.499ZApplied to files:
📚 Learning: 2025-09-09T10:39:26.383ZApplied to files:
📚 Learning: 2024-10-24T06:17:25.211ZApplied to files:
📚 Learning: 2024-10-09T03:47:21.269ZApplied to files:
📚 Learning: 2024-11-01T11:53:57.162ZApplied to files:
📚 Learning: 2025-12-17T10:27:21.083ZApplied to files:
📚 Learning: 2025-12-17T10:28:13.904ZApplied to files:
📚 Learning: 2025-10-10T10:56:04.861ZApplied to files:
📚 Learning: 2025-12-17T10:28:13.904ZApplied to files:
📚 Learning: 2024-11-25T09:05:03.917ZApplied to files:
📚 Learning: 2025-09-04T09:26:35.060ZApplied to files:
📚 Learning: 2025-12-17T10:28:13.904ZApplied to files:
📚 Learning: 2025-09-22T00:52:26.172ZApplied to files:
📚 Learning: 2025-09-16T01:39:54.099ZApplied to files:
📚 Learning: 2024-11-26T01:04:16.637ZApplied to files:
📚 Learning: 2024-11-26T01:14:58.163ZApplied to files:
🔇 Additional comments (3)
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (1)
script/playgroundHelpers.sh (1)
129-135: Consider usingmapfilefor safer array assignment.The static analysis tool flagged line 131 for SC2207. While the current pattern works, using
mapfileorread -ais safer for handling command output with special characters.However, based on repository conventions, this pattern appears consistent with existing code in
helperFunctions.sh.🔎 Optional safer alternative using mapfile
# get initial list of networks based on EVM version if [[ -n "$EVM_VERSION" ]]; then # get networks filtered by specific EVM version - NETWORKS=($(getIncludedNetworksByEvmVersionArray "$EVM_VERSION")) + mapfile -t NETWORKS < <(getIncludedNetworksByEvmVersionArray "$EVM_VERSION") else # get all included networks (all EVM versions) - NETWORKS=($(getIncludedNetworksArray)) + mapfile -t NETWORKS < <(getIncludedNetworksArray) fi
Test Coverage ReportLine Coverage: 85.29% (2992 / 3508 lines) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
deployments/mainnet.diamond.json (1)
100-191: AllBridgeFacet version 2.1.2 is missing from deployment records and _targetState.json is not updated.The mainnet.diamond.json shows AllBridgeFacet version 2.1.2, but this creates inconsistencies:
- No version 2.1.2 entry exists in
deployments/_deployments_log_file.json(only versions 2.1.0 and 2.1.1 are recorded)- Address
0xA31E7B9715c1950B669Dbb9084B7e4D89186DA9ffor the 2.1.2 deployment is not in the logsscript/deploy/_targetState.jsonstill shows AllBridgeFacet version 2.1.0 across all networksThe diamond configuration and deployment records are out of sync. Either the version 2.1.2 deployment record needs to be added to the logs, or the diamond file update is premature pending actual deployment.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
deployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.jsondeployments/base.diamond.jsondeployments/mainnet.diamond.jsondeployments/polygon.diamond.json
🚧 Files skipped from review as they are similar to previous changes (1)
- deployments/polygon.diamond.json
🧰 Additional context used
🧠 Learnings (42)
📓 Common learnings
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: 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: 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.
Learnt from: mirooon
Repo: lifinance/contracts PR: 1283
File: deployments/ronin.diamond.json:65-68
Timestamp: 2025-08-07T10:20:01.383Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) and deployment log files have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs updating contract addresses (like RelayFacet on Worldchain), verify the presence of entries in all relevant files (worldchain.json, worldchain.diamond.json, _deployments_log_file.json) before reporting inconsistencies. The RelayFacet entry exists in all required deployment files with the correct address.
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.
Learnt from: mirooon
Repo: lifinance/contracts PR: 945
File: src/Facets/GlacisFacet.sol:1-3
Timestamp: 2025-01-28T11:28:16.225Z
Learning: The GlacisFacet contract audit will be conducted and added to the audit log in later stages of development. This is acceptable during the initial development phase.
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.
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.
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
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: 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.
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : In Solidity facets with `minAmountOut` or similar bridge parameters, update the bridge's minAmountOut in `swapAndStartBridgeTokensVia{FacetName}` to account for positive slippage from swaps after `_depositAndSwap` updates `_bridgeData.minAmount`, adjusting proportionally for decimal differences if applicable
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`.
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/002-architecture.mdc:0-0
Timestamp: 2025-12-17T10:27:21.083Z
Learning: Applies to src/Facets/**/*Bridge*.sol : For non-EVM chains (bridgeData.receiver == NON_EVM_ADDRESS), emit BridgeToNonEVMChainBytes32 with transactionId, destinationChainId, and non-EVM receiver (bytes32)
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: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : In Solidity facets, `receiverAddress` must be the first parameter in `{facetName}Data` and must match `bridgeData.receiver` for EVM chains
Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: docs/LDAPeripheryRegistryFacet.md:14-27
Timestamp: 2025-08-29T14:05:25.335Z
Learning: mirooon prefers interface-level documentation to focus on the API contract and function purposes rather than implementation details like access control restrictions or specific modifiers, keeping documentation clean and consumable at the interface level.
📚 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/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.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/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.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/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2024-09-27T07:10:15.586Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 812
File: deployments/polygon.diamond.json:4-11
Timestamp: 2024-09-27T07:10:15.586Z
Learning: In `deployments/polygon.diamond.json`, it's acceptable for certain facets to have empty names and versions when specified by the developer.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2024-11-26T01:01:18.499Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/arbitrum.diamond.json:148-150
Timestamp: 2024-11-26T01:01:18.499Z
Learning: In `deployments/*.diamond.json` configuration files, facets that are part of an open PR and not yet merged into the main branch may have missing `Name` and `Version` fields.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-01-28T14:30:06.911Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 924
File: deployments/abstract.json:2-4
Timestamp: 2025-01-28T14:30:06.911Z
Learning: In the LiFi contract architecture, "LiFiDiamond" is the diamond proxy contract that connects all facets into a cohesive system. The facets are individual contracts that provide specific functionality, and the diamond proxy delegates calls to these facets.
Applied to files:
deployments/mainnet.diamond.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/mainnet.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.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/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-12-17T10:28:13.904Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : Facets must implement required functions: `_startBridge` (internal), `swapAndStartBridgeTokensVia{FacetName}`, and `startBridgeTokensVia{FacetName}`
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-02-11T10:35:03.536Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 988
File: script/tasks/solidity/AddTokenApprovalsToCBridgeFacetPacked.s.sol:17-21
Timestamp: 2025-02-11T10:35:03.536Z
Learning: The CBridgeFacetPacked and cBridge addresses in AddTokenApprovalsToCBridgeFacetPacked.s.sol must not be zero addresses as they are required for token approvals to function properly.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-12-17T10:27:21.083Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/002-architecture.mdc:0-0
Timestamp: 2025-12-17T10:27:21.083Z
Learning: Applies to src/Facets/**/*.sol : Facets provide modular functionality grouped by concern (bridges, swaps, receivers, admin, etc.)
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-07-16T01:03:08.106Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1275
File: src/Facets/AllBridgeFacet.sol:164-164
Timestamp: 2025-07-16T01:03:08.106Z
Learning: In src/Facets/AllBridgeFacet.sol, the team has decided that explicit validation for address downcasting from `_bridgeData.sendingAssetId` to `bytes32(uint256(uint160(_bridgeData.sendingAssetId)))` is not required, accepting the potential risk of silent overflow from unsafe downcasting.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.json
📚 Learning: 2025-12-17T10:28:13.904Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : In Solidity facets with `minAmountOut` or similar bridge parameters, update the bridge's minAmountOut in `swapAndStartBridgeTokensVia{FacetName}` to account for positive slippage from swaps after `_depositAndSwap` updates `_bridgeData.minAmount`, adjusting proportionally for decimal differences if applicable
Applied to files:
deployments/mainnet.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2025-12-17T10:28:13.904Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : In Solidity facets, validate `targetChainId` against `bridgeData.destinationChain` for EVM-to-EVM bridges
Applied to files:
deployments/mainnet.diamond.json
📚 Learning: 2024-11-25T09:04:55.880Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: script/deploy/_targetState.json:143-143
Timestamp: 2024-11-25T09:04:55.880Z
Learning: Errors about the missing `OpBNBBridgeFacet` contract are expected when it is referenced in the target state but not yet merged into the main branch.
Applied to files:
deployments/mainnet.diamond.json
📚 Learning: 2025-02-12T09:44:12.961Z
Learnt from: mirooon
Repo: lifinance/contracts PR: 985
File: script/deploy/_targetState.json:0-0
Timestamp: 2025-02-12T09:44:12.961Z
Learning: The bsca network intentionally maintains different facet versions between staging and production environments, specifically:
1. CalldataVerificationFacet: v1.1.1 in staging vs v1.1.2 in production
2. EmergencyPauseFacet: present only in production
3. Permit2Proxy: present only in production
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2024-11-22T08:49:35.205Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 827
File: src/Facets/DeBridgeDlnFacet.sol:0-0
Timestamp: 2024-11-22T08:49:35.205Z
Learning: In `DeBridgeDlnFacet.sol`, direct access to the `deBridgeChainId` mapping is acceptable, and using the `getDeBridgeChainId` function is not necessary in these instances.
Applied to files:
deployments/mainnet.diamond.json
📚 Learning: 2025-12-17T10:28:34.379Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/104-receiver-contracts.mdc:0-0
Timestamp: 2025-12-17T10:28:34.379Z
Learning: Applies to src/Periphery/Receiver*.sol : Receiver contracts must implement a bridge-specific external entry point (e.g., `handleV3AcrossMessage`, `lzCompose`, `cfReceive`) protected by authorization modifier that decodes bridge message to extract `bytes32 transactionId`, `LibSwap.SwapData[] memory swapData`, `address receiver`, and calls internal `_swapAndCompleteBridgeTokens()`
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2025-12-17T10:28:34.379Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/104-receiver-contracts.mdc:0-0
Timestamp: 2025-12-17T10:28:34.379Z
Learning: Applies to src/Periphery/Receiver*.sol : Receiver contracts must implement internal `_swapAndCompleteBridgeTokens()` function that handles native vs ERC20 tokens: use `safeApproveWithRetry()` or `safeIncreaseAllowance()` for ERC20 (reset to 0 after), pass `value: amount` for native tokens, call `executor.swapAndCompleteBridgeTokens()` in try-catch block, and on failure send raw tokens to receiver and emit `LiFiTransferRecovered`
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-12-17T10:28:34.379Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/104-receiver-contracts.mdc:0-0
Timestamp: 2025-12-17T10:28:34.379Z
Learning: Applies to src/Periphery/Receiver*.sol : Receiver contracts must implement `receive() external payable {}` to handle native token transfers from bridges
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2025-12-17T10:28:34.379Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/104-receiver-contracts.mdc:0-0
Timestamp: 2025-12-17T10:28:34.379Z
Learning: Applies to src/Periphery/Receiver*.sol : For native tokens with gas checks (e.g., StargateV2), Receiver contracts must check `gasleft()` before executing; if insufficient gas, send tokens directly to receiver and emit `LiFiTransferRecovered`
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.json
📚 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:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2025-12-17T10:28:34.379Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/104-receiver-contracts.mdc:0-0
Timestamp: 2025-12-17T10:28:34.379Z
Learning: Applies to src/Periphery/Receiver*.sol : Receiver contracts must include bridge-specific configuration storage (e.g., `recoverGas` for StargateV2, protocol-specific constants)
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-12-17T10:28:34.379Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/104-receiver-contracts.mdc:0-0
Timestamp: 2025-12-17T10:28:34.379Z
Learning: Applies to src/Periphery/Receiver*.sol : Receiver contracts must only emit `LiFiTransferRecovered` when swaps fail and raw bridged tokens are sent to receiver, with event signature: `LiFiTransferRecovered(bytes32 indexed transactionId, address receivingAssetId, address receiver, uint256 amount, uint256 timestamp)`
Applied to files:
deployments/mainnet.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2025-02-24T06:51:03.551Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: src/Periphery/ReceiverChainflip.sol:162-162
Timestamp: 2025-02-24T06:51:03.551Z
Learning: In periphery contracts like ReceiverChainflip, the receive function can be left open without access control as it's part of the intended design.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 819
File: deployments/boba.diamond.json:68-68
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In the `lifinance/contracts` repository, `ReceiverStargateV2` may not be deployed to all networks, and it's acceptable for its address to remain empty in deployment files when it is not deployed. PRs unrelated to `ReceiverStargateV2` should not raise comments about its absence.
Applied to files:
deployments/mainnet.diamond.jsondeployments/base.diamond.jsondeployments/arbitrum.diamond.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/base.diamond.jsondeployments/arbitrum.diamond.json
📚 Learning: 2024-11-26T01:04:16.637Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/fantom.diamond.json:92-94
Timestamp: 2024-11-26T01:04:16.637Z
Learning: In `deployments/*.diamond.json` files, it's acceptable for facets to have empty `Name` and `Version` fields, and these should not be flagged as issues.
Applied to files:
deployments/base.diamond.jsondeployments/arbitrum.diamond.staging.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:
deployments/base.diamond.jsondeployments/arbitrum.diamond.staging.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/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2025-12-17T10:28:13.904Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : Facets must be located in `src/Facets/` directory with names containing `Facet`
Applied to files:
deployments/arbitrum.diamond.jsondeployments/arbitrum.diamond.staging.json
📚 Learning: 2024-10-09T03:47:21.269Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: deployments/bsc.diamond.staging.json:4-7
Timestamp: 2024-10-09T03:47:21.269Z
Learning: In files with "staging" in their filename, such as `deployments/bsc.diamond.staging.json`, it is acceptable for facets to have empty "Name" and "Version" fields. Do not flag missing facet information in such files during reviews.
Applied to files:
deployments/arbitrum.diamond.staging.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/arbitrum.diamond.staging.json
📚 Learning: 2024-11-21T08:39:29.530Z
Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/dexs.json:748-752
Timestamp: 2024-11-21T08:39:29.530Z
Learning: In the 'worldchain' network, the addresses `0x50D5a8aCFAe13Dceb217E9a071F6c6Bd5bDB4155`, `0x8f023b4193a6b18C227B4a755f8e28B3D30Ef9a1`, and `0x603a538477d44064eA5A5d8C345b4Ff6fca1142a` are used as DEXs and should be included in `config/dexs.json`.
Applied to files:
deployments/arbitrum.diamond.staging.json
📚 Learning: 2025-12-17T10:28:13.904Z
Learnt from: CR
Repo: lifinance/contracts PR: 0
File: .cursor/rules/102-facets.mdc:0-0
Timestamp: 2025-12-17T10:28:13.904Z
Learning: Applies to src/Facets/**/*Facet.sol : Facets must use LibAsset, LibSwap, and LibAllowList utilities along with Validatable and SwapperV2 interfaces; reserve native fees via `_depositAndSwap` variants when needed
Applied to files:
deployments/arbitrum.diamond.staging.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/arbitrum.diamond.staging.json
📚 Learning: 2025-07-15T05:05:28.134Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1140
File: config/permit2Proxy.json:3-3
Timestamp: 2025-07-15T05:05:28.134Z
Learning: In config/permit2Proxy.json, the addresses represent the Permit2 contract addresses on each chain, NOT the Permit2Proxy contract addresses. These Permit2 addresses are used as constructor arguments when deploying the Permit2Proxy contract. The Permit2Proxy acts as a wrapper/proxy that interacts with the underlying Permit2 contract on each network.
Applied to files:
deployments/arbitrum.diamond.staging.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/arbitrum.diamond.staging.json
📚 Learning: 2025-02-11T10:33:52.791Z
Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 988
File: script/deploy/facets/DeployPermit2Proxy.s.sol:33-37
Timestamp: 2025-02-11T10:33:52.791Z
Learning: The Permit2Proxy contract must not be deployed with zero addresses for its critical dependencies (LiFiDiamond, permit2Address, safeAddress). This is enforced by passing `false` to `_getConfigContractAddress` function.
Applied to files:
deployments/arbitrum.diamond.staging.json
🪛 Gitleaks (8.30.0)
deployments/arbitrum.diamond.staging.json
[high] 228-228: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (10)
deployments/arbitrum.diamond.staging.json (4)
88-91: Placeholder entries are acceptable in staging configurations.The empty Name and Version fields for these placeholder facet entries are expected in staging deployment files. This pattern is used for testing or preparatory work.
Based on learnings, staging files like this one can contain facets with empty metadata fields.
Also applies to: 128-131, 152-155, 160-163, 176-179, 200-203
204-211: Verify deployment scope includes AcrossV4SwapFacet.NEARIntentsFacet deployment aligns with the PR title. However, AcrossV4SwapFacet is also being deployed but is not mentioned in the PR description. Please confirm this is intentional or consider whether it should be deployed separately for clearer change tracking.
222-222: Permit2Proxy address updated in staging environment.The Permit2Proxy address has been updated. This appears to be routine staging maintenance, but ensure it's intentional and properly tested.
226-226: No action required. ReceiverOIF is a separate receiver contract for the Open Intent Framework (OIF) protocol and is unrelated to NEARIntentsFacet. The staging address update for ReceiverOIF is a standard deployment change with a different address for the staging environment.Likely an incorrect or invalid review comment.
deployments/base.diamond.json (3)
84-87: AllBridgeFacet v2.1.2 deployment is consistent.The AllBridgeFacet update to v2.1.2 at address 0xA31E7B9715c1950B669Dbb9084B7e4D89186DA9f is consistently deployed across base, mainnet, bsc, arbitrum, and polygon.
206-206: No action needed—ReceiverOIF is properly implemented.ReceiverOIF source code exists and correctly implements all required receiver contract patterns (inherits from ILiFi and WithdrawablePeriphery, validates all constructor parameters with InvalidConfig(), includes immutable EXECUTOR and OUTPUT_SETTLER, and has a receive() fallback). Deployment to mainnet, arbitrum, and base with the same address is appropriate; empty addresses on other networks are expected per standard deployment practices.
188-191: NEARIntentsFacet is properly implemented with required functions and test coverage—no action needed.The NEARIntentsFacet deployment entry at lines 188-191 is correct. The facet source code exists at
src/Facets/NEARIntentsFacet.soland implements all required functions:
startBridgeTokensViaNEARIntentswith proper modifiers (nonReentrant, refundExcessNative, validateBridgeData, doesNotContainSourceSwaps, doesNotContainDestinationCalls)swapAndStartBridgeTokensViaNEARIntentswith proper modifiers (nonReentrant, refundExcessNative, containsSourceSwaps, doesNotContainDestinationCalls, validateBridgeData)_startBridgeinternal implementationComprehensive test coverage exists at
test/solidity/Facets/NEARIntentsFacet.t.sol(1,196 lines). The facet includes EIP-712 signature verification for authorization and replay protection via quote ID consumption tracking.Likely an incorrect or invalid review comment.
deployments/arbitrum.diamond.json (1)
44-47: LGTM - Changes are consistent with mainnet deployment.The changes in this file mirror those in mainnet.diamond.json:
- AllBridgeFacet updated to v2.1.2 at the same address
- NEARIntentsFacet added at the same address (cross-network consistency already flagged in mainnet review)
- ReceiverOIF added with empty address (acceptable per learnings when not deployed on this chain)
All verification points raised in the mainnet.diamond.json review apply here as well.
Also applies to: 200-203, 218-218
deployments/mainnet.diamond.json (2)
100-103: AllBridgeFacet v2.1.2 deployment verified.The source code exists at src/Facets/AllBridgeFacet.sol with version 2.1.2 documented (
@custom:version 2.1.2), matching the deployment entry in mainnet.diamond.json. No issues found.
188-191: NEARIntentsFacet is properly implemented and address consistency across networks is expected for CREATE2 deployments.The facet exists at
src/Facets/NEARIntentsFacet.soland correctly implements all required patterns: bothstartBridgeTokensViaNEARIntentsandswapAndStartBridgeTokensViaNEARIntentsfunctions, the internal_startBridgemethod, and all necessary modifiers (nonReentrant,refundExcessNative,validateBridgeData). The same address (0xf8fA34D58A277060D07bCa7EC24D6B386d86a793) appearing across mainnet, arbitrum, polygon, base, bsc, gnosis, xlayer, and aurora is normal for CREATE2 deployments where identical code and salt produce identical addresses across different networks.
Which Jira task belongs to this PR?
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)