Deploy ReceiverOIF

[mirooon]

Which Jira task belongs to this PR?

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 adds a new ReceiverOIF contract address entry across multiple deployment configuration files for mainnet, arbitrum, and base networks, and introduces the ReceiverOIF dependency (version 1.0.0) in the target state configuration for production environments. Additionally, the deployment log file is extended with new contract deployment records.

Changes

Cohort / File(s)	Summary
Network Deployment Configs deployments/arbitrum.json, deployments/base.json, deployments/mainnet.json	Each file updated to include new top-level ReceiverOIF field with address 0x761B0e8f6e80BBd23F3886663Cc071a554be37A3; preceding entries adjusted with trailing commas for valid JSON syntax
Target State Configuration script/deploy/_targetState.json	Added ReceiverOIF dependency (version 1.0.0) to LiFiDiamond configuration in three production environments: mainnet.production, abstract.production, and arbitrum.production
Deployment Log deployments/_deployments_log_file.json	Extended with numerous new contract deployment records containing deployment metadata, contract addresses, optimizer runs, timestamps, constructor arguments, and verification statuses

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

The changes follow a consistent, repetitive pattern of adding the same ReceiverOIF entry across network configuration files. While the deployment log includes substantial volume, the entries are data additions without logic changes. Configuration syntax adjustments are straightforward JSON modifications.

Possibly related PRs

• symbiosis facet deployed to unichain #1023: Modifies Receiver-related components in deployment/target state JSONs with alternative receiver contract variants
• Redeploy receiver contracts on mainnet with current Executor address #1434: Updates receiver contract addresses and entries across deployment configuration files
• Fix deploy log #1472: Restructures existing entries in the same deployment log file

Suggested labels

AuditNotRequired

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description follows the template structure but lacks critical information: the Jira task reference is empty, implementation rationale is missing, and all reviewer checklists are unchecked—particularly concerning for contract audits and security validations.	Add Jira task reference, explain implementation rationale, complete all checklist items or explicitly document why audit and security checks cannot be completed before deployment.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Deploy ReceiverOIF' clearly and directly describes the main change, matching the deployment of a new contract address across multiple configuration files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch deploy-receiveroif

---

📜 Recent 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 c33a804 and ddb0237.

📒 Files selected for processing (5)

• deployments/_deployments_log_file.json (1 hunks)
• deployments/arbitrum.json (1 hunks)
• deployments/base.json (1 hunks)
• deployments/mainnet.json (1 hunks)
• script/deploy/_targetState.json (3 hunks)

🧰 Additional context used

🧠 Learnings (34)

📓 Common learnings

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

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

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

Learnt from: 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: 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-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/base.json
• script/deploy/_targetState.json
• deployments/mainnet.json
• deployments/arbitrum.json

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

• deployments/base.json
• script/deploy/_targetState.json
• deployments/mainnet.json
• deployments/arbitrum.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/base.json
• script/deploy/_targetState.json
• deployments/mainnet.json
• deployments/arbitrum.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.json
• deployments/mainnet.json
• deployments/arbitrum.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:

• deployments/base.json
• script/deploy/_targetState.json
• deployments/arbitrum.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/base.json
• script/deploy/_targetState.json
• deployments/mainnet.json
• deployments/_deployments_log_file.json
• deployments/arbitrum.json

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

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.

Applied to files:

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

• deployments/base.json

📚 Learning: 2025-12-02T10:08:06.478Z

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-12-02T10:08:06.478Z
Learning: Applies to src/Facets/*.sol : For non-EVM chain support in facets, use bytes (not bytes32) for receiverAddress, validate non-EVM address is not zero, and use NON_EVM_ADDRESS constant from src/Helpers/LiFiData.sol when needed

Applied to files:

• deployments/base.json
• deployments/mainnet.json
• deployments/arbitrum.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/base.json
• deployments/mainnet.json
• deployments/arbitrum.json

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

• deployments/base.json
• deployments/arbitrum.json

📚 Learning: 2025-12-02T10:08:06.478Z

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-12-02T10:08:06.478Z
Learning: Applies to src/Facets/*.sol : Facet contracts must implement _startBridge (internal), swapAndStartBridgeTokensVia{FacetName}, and startBridgeTokensVia{FacetName} functions. Inherit from ILiFi, LibAsset, LibSwap, LibAllowList, ReentrancyGuard, SwapperV2, and Validatable

Applied to files:

• deployments/base.json
• deployments/mainnet.json
• deployments/arbitrum.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/base.json
• deployments/mainnet.json
• deployments/arbitrum.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/base.json
• deployments/arbitrum.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/base.json
• deployments/mainnet.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/mainnet.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/mainnet.json
• deployments/_deployments_log_file.json

📚 Learning: 2025-12-02T10:08:06.478Z

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-12-02T10:08:06.478Z
Learning: Applies to script/deploy/targetState.json : targetState.json tracks expected contract versions per network and environment, ensures version consistency across deployments, and is auto-created from a Google Sheet. Contains network keys (mainnet, arbitrum), environment keys (production, staging), and contract versions for facets, periphery, and core contracts

Applied to files:

• script/deploy/_targetState.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:

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

• script/deploy/_targetState.json

📚 Learning: 2024-10-24T06:17:25.211Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: deployments/bsc.diamond.staging.json:100-101
Timestamp: 2024-10-24T06:17:25.211Z
Learning: In `deployments/bsc.diamond.staging.json`, the trailing comma after the last property in the `Periphery` object is acceptable and should not be flagged as a JSON formatting error.

Applied to files:

• deployments/mainnet.json
• deployments/arbitrum.json

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

• deployments/mainnet.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.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.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/mainnet.json

📚 Learning: 2025-12-02T10:08:06.478Z

Learnt from: CR
Repo: lifinance/contracts PR: 0
File: conventions.md:0-0
Timestamp: 2025-12-02T10:08:06.478Z
Learning: Applies to src/Facets/*.sol : In facet contracts, emit LiFiTransferStarted event at transaction start (before external calls) and never emit LiFiTransferCompleted (only use in Executor) or LiFiTransferRecovered (only use in Receiver contracts)

Applied to files:

• deployments/mainnet.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-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-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-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

⏰ 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: run-unit-tests
• GitHub Check: run-unit-tests

🔇 Additional comments (6)

deployments/arbitrum.json (1)

73-74: Deployment entry added correctly.

The ReceiverOIF contract entry has been added with proper JSON syntax. Address verification is requested in the mainnet.json review.

script/deploy/_targetState.json (3)

58-59: Target state configuration updated correctly for mainnet.

The ReceiverOIF dependency (version 1.0.0) has been properly added to the mainnet production configuration.

---

145-146: Target state configuration updated correctly for arbitrum.

The ReceiverOIF dependency (version 1.0.0) has been properly added to the arbitrum production configuration.

---

299-300: Target state configuration updated correctly for base.

The ReceiverOIF dependency (version 1.0.0) has been properly added to the base production configuration, maintaining consistency with the base.json deployment file.

deployments/base.json (1)

62-63: Deployment entry added correctly with proper configuration consistency.

The ReceiverOIF contract entry has been added with proper JSON syntax and is consistent with the base.production configuration in _targetState.json. Address verification is requested in the mainnet.json review.

deployments/_deployments_log_file.json (1)

48593-48639: LGTM! Deployment log entries are well-structured.

The ReceiverOIF deployment records for base, arbitrum, and mainnet are properly formatted with consistent address 0x761B0e8f6e80BBd23F3886663Cc071a554be37A3 across networks (CREATE2 pattern), network-specific constructor arguments, and verification status confirmed. Based on learnings, deployment log files serve as historical records and these entries correctly document the deployments.

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