Deploy PolymerCCTP for arbitrum staging

[mirooon]

Which Jira task belongs to this PR?

Why did I implement it this way?

Lack of PolymerCCTP for arbitrum staging

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

The PR updates deployment configurations across multiple blockchain networks by adding new version 2.0.0 entries to the deployments log, updating CelerCircleBridgeFacet addresses across multiple networks, and introducing PolymerCCTPFacet entries in Arbitrum staging deployments.

Changes

Cohort / File(s)	Change Summary
Deployments Log deployments/_deployments_log_file.json	Added version 2.0.0 entries for multiple contracts across mainnet, staging, and production networks with deployment details, contract addresses, optimizer configurations, and timestamps
CelerCircleBridgeFacet Address Updates deployments/arbitrum.json, deployments/avalanche.json, deployments/base.json, deployments/optimism.json, deployments/polygon.json	Updated CelerCircleBridgeFacet address to 0xB815B47ad429436892Fc3C6ed1D401F515C7F763 across multiple network deployment files
PolymerCCTPFacet Additions deployments/arbitrum.diamond.staging.json, deployments/arbitrum.staging.json	Added PolymerCCTPFacet facet entry (0xc547F046174A880d08A251aF10FA659c339d30Ff) to Arbitrum staging diamond deployment and updated existing staging address
Plume Network Deployment deployments/plume.json	Added new CelerCircleBridgeFacet entry to the Plume network deployment mapping

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

The changes consist primarily of homogeneous address updates and version entries across deployment configuration files, which are straightforward to verify. Focus areas for review:

• Verify CelerCircleBridgeFacet address consistency across all updated network files
• Confirm PolymerCCTPFacet address alignment between diamond and staging deployments
• Validate version 2.0.0 entries in the deployments log have correct contract details and network associations

Possibly related PRs

• Redeploy facets for lido #1217: Modifies deployment manifests and updates redeployed facet addresses across multiple networks
• deployed GnosisBridgeFacet to mainnet #1197: Adds version 2.0.0 deployment entries to the log file and updates facet addresses in deployment JSONs
• deployed PolymerCCTP to arb, opt, base staging #1512: Modifies PolymerCCTPFacet entries in Arbitrum staging diamond deployments

Suggested labels

AuditNotRequired

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description follows the template structure but is largely incomplete. While it includes the basic sections, critical fields are missing or unchecked: Jira task is blank, several required checklists are unchecked, and the reviewer checklist audit requirements are incomplete.	Complete the Jira task reference, check remaining checklist items if applicable, and provide audit information (date, company/auditor) if new contracts are included in the deployment.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is partially related to the changeset. It mentions PolymerCCTP for arbitrum staging, but the PR also updates CelerCircleBridgeFacet addresses across multiple networks and adds entries to the deployment log file.
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-polymer-arbitrum-staging

---

📜 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 2bd6bd8 and 7c18aec.

📒 Files selected for processing (9)

• deployments/_deployments_log_file.json (7 hunks)
• deployments/arbitrum.diamond.staging.json (1 hunks)
• deployments/arbitrum.json (1 hunks)
• deployments/arbitrum.staging.json (1 hunks)
• deployments/avalanche.json (1 hunks)
• deployments/base.json (1 hunks)
• deployments/optimism.json (1 hunks)
• deployments/plume.json (1 hunks)
• deployments/polygon.json (1 hunks)

🧰 Additional context used

🧠 Learnings (51)

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

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

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

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.

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

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

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 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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/arbitrum.diamond.staging.json
• deployments/plume.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/plume.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/arbitrum.diamond.staging.json
• deployments/_deployments_log_file.json
• deployments/plume.json

📚 Learning: 2025-04-04T07:21:52.878Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1086
File: test/solidity/utils/TestBase.sol:195-205
Timestamp: 2025-04-04T07:21:52.878Z
Learning: In the TestBase.sol file, the Optimism network constants are set correctly with:
- ADDRESS_UNISWAP_OPTIMISM: 0x4A7b5Da61326A6379179b40d00F57E5bbDC962c2 (Uniswap V2 Router)
- ADDRESS_USDC_OPTIMISM: 0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85 (Native USDC)
- USDC.e (bridged USDC from Ethereum) on Optimism has address 0x7f5c764cbc14f9669b88837ca1490cca17c31607

Applied to files:

• deployments/optimism.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/avalanche.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/optimism.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.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:

• deployments/optimism.json
• deployments/polygon.json
• deployments/_deployments_log_file.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/arbitrum.diamond.staging.json
• deployments/plume.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/arbitrum.diamond.staging.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/arbitrum.staging.json

📚 Learning: 2024-10-31T09:09:38.568Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 843
File: src/Facets/RelayFacet.sol:165-170
Timestamp: 2024-10-31T09:09:38.568Z
Learning: In the `RelayFacet` contract (`src/Facets/RelayFacet.sol`), within the `_startBridge` function, low-level `call` is intentionally used to transfer tokens so that extra bytes can be added to the calldata, as required for integrating with Relay Protocol.

Applied to files:

• deployments/optimism.json
• deployments/arbitrum.json
• deployments/polygon.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/arbitrum.diamond.staging.json
• deployments/plume.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/plume.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/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/polygon.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 : Use nonReentrant, refundExcessNative, validateBridgeData, and appropriate source/destination call modifiers (doesNotContainSourceSwaps/doesContainSourceSwaps, doesNotContainDestinationCalls/doesContainDestinationCalls) on facet functions

Applied to files:

• deployments/optimism.json
• deployments/arbitrum.json
• deployments/polygon.json

📚 Learning: 2025-12-12T11:16:09.236Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1530
File: src/Interfaces/ICircleBridgeProxy.sol:20-29
Timestamp: 2025-12-12T11:16:09.236Z
Learning: In src/Interfaces/ICircleBridgeProxy.sol, the ICircleBridgeProxy interface represents Celer's CircleBridgeProxy contract (not Circle's native TokenMessenger). The correct depositForBurn signature uses uint64 _dstChid (chain ID) rather than uint32 destinationDomain, and does not include a bytes32 destinationCaller parameter. The signature is: depositForBurn(uint256 _amount, uint64 _dstChid, bytes32 _mintRecipient, address _burnToken, uint256 _maxFee, uint32 _minFinalityThreshold) external.

Applied to files:

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

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

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1275
File: src/Facets/AllBridgeFacet.sol:175-175
Timestamp: 2025-07-16T01:04:11.083Z
Learning: In AllBridgeFacet.sol, zero fee validation is not required at the contract level because the backend system ensures that calldata and msg.value are properly aligned before transactions reach the contract.

Applied to files:

• deployments/optimism.json
• deployments/base.json
• deployments/polygon.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/optimism.json
• deployments/arbitrum.json
• deployments/arbitrum.staging.json
• deployments/plume.json

📚 Learning: 2025-11-13T00:53:43.774Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1456
File: src/Facets/PolymerCCTPFacet.sol:220-224
Timestamp: 2025-11-13T00:53:43.774Z
Learning: In src/Facets/PolymerCCTPFacet.sol, the PolymerCCTPFeeSent event intentionally emits _bridgeData.minAmount (the pre-fee total) as its first parameter rather than the net bridged amount (bridgeAmount after fee deduction), because off-chain logic requires this pre-fee value to pick up deposits.

Applied to files:

• deployments/optimism.json
• deployments/arbitrum.json
• deployments/base.json
• deployments/arbitrum.staging.json
• deployments/arbitrum.diamond.staging.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/arbitrum.json
• deployments/arbitrum.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/arbitrum.json
• deployments/base.json
• deployments/polygon.json
• deployments/avalanche.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: 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/base.json
• deployments/polygon.json
• deployments/arbitrum.staging.json
• deployments/arbitrum.diamond.staging.json
• deployments/plume.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/base.json
• deployments/polygon.json
• deployments/avalanche.json
• deployments/_deployments_log_file.json
• deployments/plume.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/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/plume.json

📚 Learning: 2025-02-13T08:57:00.095Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 984
File: docs/ChainflipFacet.md:0-0
Timestamp: 2025-02-13T08:57:00.095Z
Learning: The ChainflipData struct in ChainflipFacet has three fields:
1. uint32 dstToken - The destination token identifier in Chainflip
2. bytes32 nonEvmAddress - The non-EVM destination address
3. bytes cfParameters - Additional parameters for Chainflip protocol

Applied to files:

• deployments/base.json
• deployments/avalanche.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/polygon.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 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/polygon.json
• deployments/arbitrum.staging.json
• deployments/avalanche.json
• deployments/plume.json

📚 Learning: 2025-11-13T00:53:25.372Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1456
File: test/solidity/Facets/PolymerCCTPFacet.t.sol:325-333
Timestamp: 2025-11-13T00:53:25.372Z
Learning: In src/Facets/PolymerCCTPFacet.sol, the PolymerCCTPFeeSent event must emit the original bridgeData.minAmount (before polymer fee deduction) as the first parameter, not the net bridge amount, because off-chain logic requires this value to properly pick up and process the deposit.

Applied to files:

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

📚 Learning: 2024-12-03T11:01:57.084Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 807
File: script/deploy/_targetState.json:164-164
Timestamp: 2024-12-03T11:01:57.084Z
Learning: Version differences in `CalldataVerificationFacet` between staging and production are acceptable and not an issue.

Applied to files:

• deployments/arbitrum.staging.json
• deployments/_deployments_log_file.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/avalanche.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/avalanche.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/avalanche.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/arbitrum.diamond.staging.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/arbitrum.diamond.staging.json
• deployments/plume.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/arbitrum.diamond.staging.json
• deployments/plume.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: 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/arbitrum.diamond.staging.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:

• deployments/arbitrum.diamond.staging.json
• deployments/plume.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-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-10-09T03:47:21.269Z

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

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 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-11-07T14:57:59.929Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1452
File: deployments/_deployments_log_file.json:42713-42727
Timestamp: 2025-11-07T14:57:59.929Z
Learning: In the `deployments/_deployments_log_file.json` file, the `ZK_SOLC_VERSION` field is required for all deployment entries but should be set to an empty string `""` for non-zkEVM chains.

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2025-08-13T10:50:58.869Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1322
File: deployments/base.staging.json:18-18
Timestamp: 2025-08-13T10:50:58.869Z
Learning: Staging contracts should not be added to script/deploy/_targetState.json. Only production contracts are tracked in the target state file.

Applied to files:

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

• deployments/plume.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/plume.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 (7)

deployments/optimism.json (1)

37-37: Verify scope: cross-network CelerCircleBridgeFacet update in staging-focused PR.

The PR title focuses on "Deploy PolymerCCTP for arbitrum staging," but this change (along with similar changes in polygon.json, avalanche.json, and arbitrum.json) updates CelerCircleBridgeFacet across multiple production networks. Confirm this cross-network facet address update is intentional and within the PR scope.

Based on learnings, deployment PRs should clearly indicate scope. Not all deployments are cross-network updates—some target specific chains only.

deployments/arbitrum.diamond.staging.json (1)

212-215: Facet entry structure is correct; audit requirement applies.

The PolymerCCTPFacet entry is properly formatted and consistent with its corresponding address in arbitrum.staging.json. However, the critical audit documentation issue flagged in arbitrum.staging.json (lines 65) applies to this facet as well.

Pending resolution of the audit requirement before this can be merged.

deployments/arbitrum.staging.json (1)

65-65: Remove this comment. The audit documentation is present.

The PolymerCCTPFacet audit report exists at audit/reports/2025.12.01_PolymerCCTPFacet(v1.0.0).pdf (dated 2025.12.01), tests are comprehensive (533 lines in test file), and the facet correctly implements all required functions (_startBridge, swapAndStartBridgeTokensViaPolymerCCTP, startBridgeTokensViaPolymerCCTP) with proper inheritance and event emissions.

Likely an incorrect or invalid review comment.

deployments/_deployments_log_file.json (3)

21543-21543: Verify address uniqueness and SALT values for CelerCircleBridgeFacet v2.0.0 entries.

CelerCircleBridgeFacet v2.0.0 entries across Arbitrum, Avalanche, Base, Polygon, and Optimism all share the same address (0xB815B47ad429436892Fc3C6ed1D401F515C7F763) and identical SALT value ("12345675"). This is unusual, as contract deployments on different networks typically result in different addresses. Additionally, the SALT value appears to be a placeholder rather than a legitimate deployment salt.

Please confirm:

1. Whether the identical address across all networks is intentional (e.g., a cross-chain bridge contract with the same address) or indicates a deployment/logging error
2. Whether "12345675" is the correct deployment SALT or a placeholder value that should be updated with actual deployment parameters

Also applies to: 21634-21634, 21682-21682, 21719-21719, 21756-21756

---

21784-21784: Clarify scope: OmniBridgeFacet production entry in staging-focused PR.

This PR is titled "Deploy PolymerCCTP for arbitrum staging," but includes an OmniBridgeFacet v2.0.0 production deployment entry (lines 21784–21789). Additionally, the SALT value ("12345675") is identical to all other v2.0.0 entries, which raises concerns about whether these are actual deployment values or placeholders.

Please clarify:

1. Whether the OmniBridgeFacet production entry belongs in this PR or should be in a separate change
2. Whether "12345675" SALT values are correct or placeholders that need updating with actual deployment parameters

Based on learnings, ensure that scope aligns with PR title and that no unrelated network updates are included.

Also applies to: 21789-21789

---

48603-48603: Critical: PolymerCCTPFacet deployed with VERIFIED: "false" and unchecked audit checklist.

The PolymerCCTPFacet is being deployed to Arbitrum staging with an unverified contract (VERIFIED: "false"), yet the PR checklist shows critical items unchecked:

• "New facets checklist reviewed: not checked"
• "New contracts have at minimum one preliminary audit: unchecked"

Deploying unverified new facet code without audit coverage poses a security risk, even to staging.

Before deploying, you must:

1. Ensure the PolymerCCTPFacet contract source is verified on the blockchain explorer
2. Complete the new facets checklist
3. Document or provide evidence of a preliminary audit (date, auditor, scope)
4. Update VERIFIED to "true" once on-chain verification is confirmed

Also applies to: 48608-48608

⛔ Skipped due to learnings

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.

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: 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: 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: 1109
File: deployments/worldchain.json:28-28
Timestamp: 2025-04-21T03:17:53.443Z
Learning: For deployment PRs involving address updates like the RelayFacet to Worldchain, verify the actual presence of entries in files before reporting issues. The RelayFacet exists in the diamond log file and the PR diff already contains the necessary address change.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 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: 1377
File: deployments/mainnet.json:7-7
Timestamp: 2025-09-12T11:48:46.333Z
Learning: When running verification scripts for contract deployments, ensure the scripts are syntactically correct and thoroughly tested before making claims about contract validity. False negatives from faulty scripts can incorrectly flag valid deployments as problematic.

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: 0xDEnYO
Repo: lifinance/contracts PR: 807
File: deployments/bsc.staging.json:28-28
Timestamp: 2024-10-09T03:47:21.269Z
Learning: For staging files in deployments, avoid making comments regarding incomplete contract deployments or missing bytecode, as these comments are not necessary.

Learnt from: mirooon
Repo: lifinance/contracts PR: 1165
File: src/Facets/GnosisBridgeFacet.sol:22-22
Timestamp: 2025-05-27T16:19:16.726Z
Learning: The correct USDS token address on Ethereum mainnet is 0xdC035D45d973E3EC169d2276DDab16f1e407384F, not 0xA4Bdb11dc0a2bEC88d24A3aa1E6Bb17201112eBe.

deployments/plume.json (1)

28-29: Confirm if plume.json CelerCircleBridgeFacet address is intentional.

The trailing comma on line 28 is acceptable. However, the CelerCircleBridgeFacet address in plume.json (0xeD877C930CB332e2E92789f9535181dC62C1A0D7) is different from base.json. If this is intentional per-network configuration, note it clearly; otherwise, they should match.

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