redeployed UnitFacet to plasma (backend signer address)

[0xDEnYO]

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 updates deployment metadata across three JSON files. The primary change involves modifying contract addresses, timestamps, verification statuses, and constructor arguments in the deployment log. Additionally, UnitFacet addresses are updated across staging deployment manifests.

Changes

Cohort / File(s)	Summary
Deployment Log deployments/_deployments_log_file.json	Multiple contract deployment records updated with new addresses, timestamps, verification statuses, and ZK_SOLC_VERSION attributes; structure unchanged
Staging Manifests deployments/plasma.diamond.staging.json, deployments/plasma.staging.json	UnitFacet address updated from 0x14a60Af2bE3e85efCF43575344868b15b6ef2eA5 to 0xa65B95Ed19E6de0A020dC164C1f3cDD8B603f189; new UnitFacet entry added to diamond manifest

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• JSON data files with homogeneous address and timestamp replacements
• New UnitFacet entry addition in plasma.diamond.staging.json requires verification of correctness
• Verify UnitFacet address alignment across both staging manifests

Possibly related PRs

• Fix deploy log #1472: Both PRs modify UnitFacet deployment entries in the same deployment log
• redeployed UnitFacet to plasma (new signer address) #1474: Both PRs update UnitFacet addresses in plasma staging deployment manifests
• Redeploy facets for lido #1217: Both PRs update deployment metadata and facet addresses

Suggested labels

AuditNotRequired

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description lacks critical information: no Jira task is referenced, no explanation of implementation rationale is provided, and all review checklists remain unchecked without substantive details.	Fill in the Jira task reference, provide a brief explanation for the redeployment (e.g., reason for new signer address), and document which checklist items have been completed with relevant details.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: redeploying the UnitFacet contract to plasma staging with a new backend signer address, which is reflected in the address updates across the three modified JSON 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 redeploy-unit-staging-2

---

📜 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 3cdad67 and a7213c5.

📒 Files selected for processing (3)

• deployments/_deployments_log_file.json (1 hunks)
• deployments/plasma.diamond.staging.json (1 hunks)
• deployments/plasma.staging.json (1 hunks)

🧰 Additional context used

🧠 Learnings (33)

📓 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: 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: 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: 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: 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: 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: 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: mirooon
Repo: lifinance/contracts PR: 1193
File: deployments/base.staging.json:6-6
Timestamp: 2025-08-01T22:11:04.478Z
Learning: The user mirooon prefers to maintain both DexManagerFacet and WhitelistManagerFacet entries in staging deployment configurations during migration periods, even when the DexManagerFacet contract no longer exists in the codebase. This approach allows for backward compatibility testing and rollback capabilities in the staging environment.

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.

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

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

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

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

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

📚 Learning: 2025-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/plasma.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/plasma.diamond.staging.json
• deployments/plasma.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/plasma.diamond.staging.json
• deployments/plasma.staging.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:

• deployments/plasma.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/plasma.diamond.staging.json
• deployments/plasma.staging.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/plasma.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/plasma.diamond.staging.json
• deployments/plasma.staging.json
• deployments/_deployments_log_file.json

📚 Learning: 2024-11-26T01:14:58.163Z

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 782
File: deployments/worldchain.diamond.json:5-63
Timestamp: 2024-11-26T01:14:58.163Z
Learning: When facet versions are set to empty strings in `deployments/*.diamond.json` files, do not report this issue, as it is already known and will be addressed separately.

Applied to files:

• deployments/plasma.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/plasma.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/plasma.diamond.staging.json
• deployments/plasma.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/plasma.staging.json
• deployments/_deployments_log_file.json

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

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

Applied to files:

• deployments/plasma.staging.json
• deployments/_deployments_log_file.json

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

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

Applied to files:

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

📚 Learning: 2025-08-27T13:47:28.646Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1328
File: src/Periphery/Lda/Facets/UniV2StyleFacet.sol:0-0
Timestamp: 2025-08-27T13:47:28.646Z
Learning: In src/Periphery/Lda/Facets/UniV2StyleFacet.sol and similar LDA facets, mirooon prefers to rely on backend validation for pool addresses rather than adding contract code-size checks in the smart contract, as pool validation occurs during payload generation and transactions would fail anyway if sent to invalid addresses.

Applied to files:

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

Applied to files:

• deployments/plasma.staging.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/plasma.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 implementation is fundamentally broken: ICurveLegacy interface doesn't exist in the codebase but is imported and used, and the code attempts to send ETH to non-payable exchange functions. The entire native asset handling logic needs to be redesigned.

Applied to files:

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

📚 Learning: 2025-10-02T18:14:51.385Z

Learnt from: mirooon
Repo: lifinance/contracts PR: 1406
File: src/Facets/UnitFacet.sol:1-2
Timestamp: 2025-10-02T18:14:51.385Z
Learning: For facet contracts in src/Facets/, the SPDX license identifier should be immediately followed by the pragma statement without a blank line in between, as confirmed by mirooon for src/Facets/UnitFacet.sol.

Applied to files:

• deployments/plasma.staging.json

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

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

Applied to files:

• deployments/_deployments_log_file.json

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

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

Applied to files:

• deployments/_deployments_log_file.json

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

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

Applied to files:

• deployments/_deployments_log_file.json

📚 Learning: 2024-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: 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/_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

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

deployments/plasma.staging.json (1)

15-15: Address update is consistent across deployment configurations.

The UnitFacet address update on Line 15 is correctly aligned with the corresponding entry in deployments/plasma.diamond.staging.json. Both files now reference the new backend signer address 0xa65B95Ed19E6de0A020dC164C1f3cDD8B603f189.

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

64-67: Deployment entry verified—no issues identified.

The new UnitFacet entry at 0xa65B95Ed19E6de0A020dC164C1f3cDD8B603f189 is properly structured and confirmed to exist in deployments/_deployments_log_file.json (line 44723). The configuration is consistent with staging deployment standards and requires no changes.

deployments/_deployments_log_file.json (2)

44726-44726: Validate constructor argument represents the backend signer address.

The PR title specifies "(backend signer address)" but the constructor arg is a padded 0x00-prefixed address. Confirm that 0x2b2c52b1b63c4bfc7f1a310a1734641d8e34de62 is the intended backend signer and that this value aligns with the LiFi backend configuration for plasma staging.

---

44720-44730: Staging deployment is properly recorded with consistent addresses—original review does not apply to staging environment.

This is a staging deployment, not mainnet. The address 0xa65B95Ed19E6de0A020dC164C1f3cDD8B603f189 is consistently recorded across all plasma staging files (plasma.staging.json, plasma.diamond.staging.json, and _deployments_log_file.json).

Per repository learnings, staging deployments have different requirements than production. Audit completion during the development phase is acceptable and added in later stages. The VERIFIED: false status and unchecked checklist items are standard for staging environment entries. The PR does not require the mainnet-level validation mentioned in the original review.

Likely an incorrect or invalid review comment.

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