Skip to content

Conversation

@ezynda3
Copy link
Contributor

@ezynda3 ezynda3 commented Oct 14, 2025

Which Jira task belongs to this PR?

Why did I implement it this way?

Checklist before requesting a review

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

  • 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
Copy link
Contributor

coderabbitai bot commented Oct 14, 2025

Walkthrough

Adds EcoFacet entries and diamond facet registrations across many networks, updates config/eco.json with a new worldchain key and Tron portal format, appends extensive deployment log records, adds a Tron deploy-and-register EcoFacet script, and refactors Tron facet-registration logic to use normalized hex comparisons and zero-address handling.

Changes

Cohort / File(s) Summary of changes
Config update
config/eco.json
Added top-level worldchain key (using previous tron portal value) and updated tron.portal to a Tron-format address.
Global deployment logs
deployments/_deployments_log_file.json
Appended many new deployment records across environments/chains with addresses, metadata (TIMESTAMP, OPTIMIZER_RUNS, CONSTRUCTOR_ARGS, SALT, ZK_SOLC_VERSION), and verification info.
Network deployments: EcoFacet entries
deployments/arbitrum.json, deployments/base.json, deployments/celo.json, deployments/ink.json, deployments/mainnet.json, deployments/optimism.json, deployments/polygon.json, deployments/sonic.json, deployments/worldchain.json
Added EcoFacet address entries and adjusted trailing commas on preceding lines where needed; no other value changes.
Tron deployments (data + diamond)
deployments/tron.json, deployments/tron.diamond.json
Added EcoFacet entry and new LiFiDiamond facet record for Tron (facet key → Name: "EcoFacet", Version: "1.0.0"); fixed JSON punctuation to accommodate new keys.
Diamond facet additions
deployments/*.diamond.json (arbitrum, base, celo, ink, mainnet, optimism, polygon, sonic, unichain, worldchain)
Added new LiFiDiamond Facets entries for EcoFacet (addresses vary by network) with Version "1.0.0" alongside existing facets.
Tron deploy script
script/deploy/tron/deploy-and-register-eco-facet.ts
New script: reads config, initializes TronWeb/deployer, validates balance, resolves portal, reuses or deploys EcoFacet, computes selectors and registers facet to LiFiDiamond; supports --dryRun.
Tron deploy scripts: minor arg change
script/deploy/tron/deploy-and-register-allbridge-facet.ts, script/deploy/tron/deploy-and-register-symbiosis-facet.ts
Replaced third argument to displayNetworkInfo from network to rpcUrl.
Tron utils update
script/deploy/tron/utils.ts
Refactored registerFacetToDiamond: fetches facet address as raw value, normalizes Tron hexs, treats Tron zero-address form as zero, compares hex-equivalence to decide ADD vs REPLACE per-selector, and improved error handling/fallbacks.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

Suggested labels

AuditRequired

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)
Check name Status Explanation Resolution
Description Check ⚠️ Warning The description follows the repository template structure but leaves critical sections blank and lists many unchecked items, including the Jira task ID, implementation rationale, tests, facet checklist, and documentation updates. Without substantive content in these sections and completion of the required checklist items, the description does not provide sufficient context or assurances for reviewers. Please populate the Jira task reference and rationale sections with appropriate details, add the required tests and update documentation, and ensure the new-facet and documentation checklist items are all completed. Confirm that every item in the reviewer checklist is addressed, including validation of external calls and review of preliminary audits. Once these sections are fully filled in and all checklist boxes are checked, the description will meet the repository standards.
Docstring Coverage ⚠️ Warning Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (1 passed)
Check name Status Explanation
Title Check ✅ Passed The title “Deploy EcoFacet to production” directly reflects the core intent of the changeset, which centers on adding and configuring the EcoFacet for production deployments. It is concise and free of extraneous details or noise, allowing a reviewer to immediately grasp the main update. The phrasing is clear and specific, making it suitable for project history.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch deploy-eco-facet

📜 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 9252820 and c08362a.

📒 Files selected for processing (13)
  • deployments/arbitrum.diamond.json (1 hunks)
  • deployments/base.diamond.json (1 hunks)
  • deployments/celo.diamond.json (1 hunks)
  • deployments/ink.diamond.json (1 hunks)
  • deployments/mainnet.diamond.json (1 hunks)
  • deployments/optimism.diamond.json (1 hunks)
  • deployments/polygon.diamond.json (1 hunks)
  • deployments/sonic.diamond.json (1 hunks)
  • deployments/unichain.diamond.json (1 hunks)
  • deployments/worldchain.diamond.json (2 hunks)
  • script/deploy/tron/deploy-and-register-allbridge-facet.ts (1 hunks)
  • script/deploy/tron/deploy-and-register-eco-facet.ts (1 hunks)
  • script/deploy/tron/deploy-and-register-symbiosis-facet.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • script/deploy/tron/deploy-and-register-eco-facet.ts
🧰 Additional context used
📓 Path-based instructions (1)
script/**/*.ts

📄 CodeRabbit inference engine (conventions.md)

script/**/*.ts: All TypeScript scripts must follow .eslintrc.cjs, use async/await, try/catch error handling, proper logging, environment variables, correct typings, use citty for CLI parsing, consola for logging, validate env vars via getEnvVar(), and exit with appropriate codes
Prefer existing helper functions over reimplementation (e.g., getDeployments, getProvider, getWalletFromPrivateKeyInDotEnv, sendTransaction, ensureBalanceAndAllowanceToDiamond, getUniswapData*)
Always use proper TypeChain types (e.g., ILiFi.BridgeDataStruct) and never use any for bridge data or contract structures
Before/after changes: verify imports and types exist, ensure typechain is generated, keep changes comprehensive and consistent, run TS compilation, remove unused imports, and ensure function signatures match usage
Scripts must execute with bunx tsx

Files:

  • script/deploy/tron/deploy-and-register-allbridge-facet.ts
  • script/deploy/tron/deploy-and-register-symbiosis-facet.ts
🧠 Learnings (11)
📓 Common learnings
Learnt from: 0xDEnYO
PR: lifinance/contracts#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
PR: lifinance/contracts#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
PR: lifinance/contracts#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.
📚 Learning: 2025-09-22T00:52:26.172Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/base.diamond.json
  • deployments/worldchain.diamond.json
  • deployments/unichain.diamond.json
  • deployments/polygon.diamond.json
  • deployments/sonic.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/arbitrum.diamond.json
  • deployments/ink.diamond.json
  • deployments/optimism.diamond.json
  • deployments/celo.diamond.json
📚 Learning: 2025-09-09T10:39:26.383Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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.diamond.json
  • deployments/worldchain.diamond.json
  • deployments/polygon.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/arbitrum.diamond.json
  • deployments/optimism.diamond.json
📚 Learning: 2024-11-01T11:53:57.162Z
Learnt from: ezynda3
PR: lifinance/contracts#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/base.diamond.json
  • deployments/worldchain.diamond.json
  • deployments/unichain.diamond.json
  • deployments/polygon.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/ink.diamond.json
📚 Learning: 2025-09-16T01:39:54.099Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/base.diamond.json
  • deployments/worldchain.diamond.json
  • deployments/polygon.diamond.json
  • deployments/sonic.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/arbitrum.diamond.json
  • deployments/optimism.diamond.json
📚 Learning: 2024-11-26T01:01:18.499Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/base.diamond.json
  • deployments/unichain.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/arbitrum.diamond.json
  • deployments/ink.diamond.json
📚 Learning: 2024-09-27T07:10:15.586Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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.diamond.json
  • deployments/worldchain.diamond.json
  • deployments/unichain.diamond.json
  • deployments/polygon.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/arbitrum.diamond.json
📚 Learning: 2024-11-26T01:04:16.637Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#782
File: deployments/fantom.diamond.json:92-94
Timestamp: 2024-11-26T01:04:16.637Z
Learning: In `deployments/*.diamond.json` files, it's acceptable for facets to have empty `Name` and `Version` fields, and these should not be flagged as issues.

Applied to files:

  • deployments/base.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/ink.diamond.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/worldchain.diamond.json
  • deployments/mainnet.diamond.json
  • deployments/optimism.diamond.json
  • deployments/celo.diamond.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/worldchain.diamond.json
📚 Learning: 2024-11-26T01:14:58.163Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/ink.diamond.json
🧬 Code graph analysis (2)
script/deploy/tron/deploy-and-register-allbridge-facet.ts (1)
script/deploy/tron/utils.ts (1)
  • displayNetworkInfo (1233-1258)
script/deploy/tron/deploy-and-register-symbiosis-facet.ts (1)
script/deploy/tron/utils.ts (1)
  • displayNetworkInfo (1233-1258)
🔇 Additional comments (12)
deployments/unichain.diamond.json (1)

99-103: LGTM! EcoFacet addition follows standard pattern.

The EcoFacet entry is properly structured with Name and Version fields. The different contract address compared to other networks (e.g., sonic uses 0x499E4A6585df0638508CA45A6Bb41B9BD385030C) is expected for multi-chain deployments where each network has its own deployed instance.

deployments/sonic.diamond.json (1)

87-91: LGTM! EcoFacet registration is consistent with other networks.

The facet entry is properly formatted and positioned after the existing GlacisFacet v1.1.0 entry. As noted in learnings, having multiple versions of the same facet (like GlacisFacet v1.0.0 and v1.1.0) is acceptable for gradual migration purposes.

script/deploy/tron/deploy-and-register-symbiosis-facet.ts (1)

98-98: Correct parameter alignment with updated utility function.

The change from network to rpcUrl matches the displayNetworkInfo signature in utils.ts (lines 1232-1257), which expects rpcUrl as the third parameter. This refactor ensures consistent network information display.

script/deploy/tron/deploy-and-register-allbridge-facet.ts (1)

97-97: LGTM! Parameter updated to match utility function signature.

Consistent with the change in deploy-and-register-symbiosis-facet.ts, this update aligns the function call with the displayNetworkInfo signature that expects rpcUrl as the third parameter.

deployments/worldchain.diamond.json (1)

87-91: LGTM! EcoFacet entry properly added.

The EcoFacet registration is correctly positioned and shares the same contract address (0x499E4A6585df0638508CA45A6Bb41B9BD385030C) with several other networks (sonic, base, optimism), which may indicate these networks are part of the same deployment group or share similar infrastructure.

deployments/ink.diamond.json (1)

87-91: LGTM! Facet addition follows standard pattern.

The EcoFacet entry is properly structured. Note that this network shares the same EcoFacet address with unichain (0xad8fEeFf8BC2d19495A0D5B1E1e287bAA67cA0Db), which differs from the address used on sonic/worldchain/base/optimism (0x499E4A6585df0638508CA45A6Bb41B9BD385030C). This is acceptable as different deployment groups can use different contract instances.

deployments/optimism.diamond.json (1)

139-143: Address incomplete PR checklist items before merging.

While the EcoFacet entry is properly structured, the PR checklist shows several incomplete items for a production deployment:

  1. ✗ Tests added (unchecked)
  2. ✗ New-facet Notion checklist (unchecked)
  3. ✗ Documentation updated (unchecked)

Additionally, the PR description contains critical warnings about:

  • Verifying validation/restriction of arbitrary calls to external contracts
  • Verifying validation/restriction of privileged/storage-modifying calls
  • Ensuring preliminary audit with documented date and auditor

Since Optimism is a major production network, these items should be completed before deployment. Please:

  1. Add or reference tests covering EcoFacet functionality
  2. Complete the new-facet Notion checklist
  3. Update documentation (e.g., deployment logs, API docs)
  4. Confirm audit completion and findings resolution

Do you want me to help generate test templates or documentation updates for the EcoFacet deployment?

deployments/base.diamond.json (1)

167-171: Missing preliminary audit for EcoFacet

No audit report found and Notion checklist remains unchecked. Before deploying to Base:

  • Attach a preliminary audit report for EcoFacet (include date and auditor/company)
  • Update the Notion checklist to reflect the audit
  • Address any critical findings from the audit
deployments/celo.diamond.json (1)

88-91: Consistent EcoFacet addition; validate chain-specific address and gating.

  • Confirm the same address is intended on Celo (e.g., via CREATE2) and matches v1.0.0 bytecode.
  • Ensure selectors were added via DiamondCut and AccessManager restrictions align with security checklist.
  • If logs/TargetState updates are tracked separately, note the follow‑up PR.

Based on learnings

deployments/polygon.diamond.json (1)

180-183: EcoFacet registered in Polygon diamond — approve; please confirm operational readiness.

  • Verify deployment at 0x499E4A6… on Polygon and codehash = EcoFacet v1.0.0.
  • Ensure no selector collisions and facet is enabled post‑cut.
  • Confirm AccessManager policies and calldata validation are in place per reviewer warnings.

Based on learnings

deployments/arbitrum.diamond.json (1)

180-183: Arbitrum EcoFacet entry OK; double‑check security and deployment artifacts.

  • Validate the address/bytecode on Arbitrum and selector registration.
  • Check AccessManager gating for privileged/storage‑modifying paths and restrictions on external calls.
  • Acknowledge if deployment logs are to be updated in a separate PR.

Based on learnings

deployments/mainnet.diamond.json (1)

159-163: Confirm EcoFacet v1.0.0 on mainnet

  • Verified 0x499E4A6585df0638508CA45A6Bb41B9BD385030C as EcoFacet v1.0.0 in deployments/mainnet.diamond.json
  • On-chain: ensure diamondCut includes EcoFacet selectors (no collisions) and facet is active
  • Security: validate AccessManager/role gates for any privileged or external calls in EcoFacet
  • Deployment logs: confirm target-state update and registration transaction in logs

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

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

@lifi-action-bot lifi-action-bot marked this pull request as draft October 14, 2025 10:45
@ezynda3 ezynda3 marked this pull request as ready for review October 14, 2025 10:45
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (4)
script/deploy/tron/utils.ts (1)

963-968: Verify ADD fallback behavior on selector check errors.

The fallback to ADD behavior when facetAddress(selector) fails is reasonable for handling unregistered selectors, but may mask legitimate errors (e.g., network issues, contract call failures).

Consider logging the error details for debugging:

 } catch (error) {
+  consola.warn(
+    `Failed to check selector ${selector}: ${error instanceof Error ? error.message : String(error)}`
+  )
   consola.debug(
     `Could not check selector ${selector}, assuming ADD needed`
   )
   selectorsToAdd.push(selector)
 }
script/deploy/tron/deploy-and-register-eco-facet.ts (3)

86-89: Consider reusing the TronWeb instance from deployer.

A TronWeb instance is already created inside TronContractDeployer (line 79). Creating another instance here is redundant and uses extra memory. If the deployer exposed its tronWeb property publicly, you could reuse it.

If refactoring the deployer is not feasible right now, this duplication is acceptable but consider exposing deployer.tronWeb as a public getter in TronContractDeployer for future optimization.


93-108: Add validation for eco.json and portal address.

Two improvements:

  1. The code loads config/eco.json without checking if the file exists, which could throw an unclear error.
  2. The portal address is converted to hex (line 104) without validating it's a properly formatted Tron address.

Apply this diff to add validation:

+    // Validate eco.json exists
+    const ecoConfigFile = Bun.file('config/eco.json')
+    if (!(await ecoConfigFile.exists())) {
+      throw new Error('config/eco.json not found')
+    }
+
-    const ecoConfig = await Bun.file('config/eco.json').json()
+    const ecoConfig = await ecoConfigFile.json()
     const tronEcoConfig = ecoConfig.tron
 
     if (!tronEcoConfig)
       throw new Error('Tron configuration not found in config/eco.json')
 
     const portalTron = tronEcoConfig.portal
 
     if (!portalTron)
       throw new Error('Eco portal not found for tron in config/eco.json')
 
+    // Validate portal is a valid Tron address
+    if (!portalTron.startsWith('T') || portalTron.length !== 34) {
+      throw new Error(`Invalid Tron portal address: ${portalTron}`)
+    }
+
     const portal = tronAddressToHex(portalTron, tronWeb)

125-134: Consider verifying constructor args when reusing existing deployment.

When reusing an existing EcoFacet deployment, the script doesn't verify that the deployed contract was initialized with the same portal address. If the portal address in config/eco.json changed since the last deployment, reusing the old deployment could cause issues.

Consider adding a verification step or at minimum a warning:

if (exists && !shouldRedeploy && address) {
  consola.warn(`Reusing existing EcoFacet at ${address}`)
  consola.warn(`Ensure the existing deployment was initialized with portal: ${portalTron}`)
  const shouldVerify = await consola.prompt('Continue with existing deployment?', {
    type: 'confirm',
    initial: true,
  })
  if (!shouldVerify) {
    process.exit(0)
  }
  facetAddress = address
  // ... rest of the code
}
📜 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 2d38d75 and 9252820.

📒 Files selected for processing (16)
  • config/eco.json (1 hunks)
  • deployments/_deployments_log_file.json (1 hunks)
  • deployments/arbitrum.json (1 hunks)
  • deployments/base.json (1 hunks)
  • deployments/celo.json (1 hunks)
  • deployments/ink.json (1 hunks)
  • deployments/mainnet.json (1 hunks)
  • deployments/optimism.json (1 hunks)
  • deployments/polygon.json (1 hunks)
  • deployments/sonic.json (1 hunks)
  • deployments/tron.diamond.json (1 hunks)
  • deployments/tron.json (1 hunks)
  • deployments/unichain.json (1 hunks)
  • deployments/worldchain.json (1 hunks)
  • script/deploy/tron/deploy-and-register-eco-facet.ts (1 hunks)
  • script/deploy/tron/utils.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
script/**/*.ts

📄 CodeRabbit inference engine (conventions.md)

script/**/*.ts: All TypeScript scripts must follow .eslintrc.cjs, use async/await, try/catch error handling, proper logging, environment variables, correct typings, use citty for CLI parsing, consola for logging, validate env vars via getEnvVar(), and exit with appropriate codes
Prefer existing helper functions over reimplementation (e.g., getDeployments, getProvider, getWalletFromPrivateKeyInDotEnv, sendTransaction, ensureBalanceAndAllowanceToDiamond, getUniswapData*)
Always use proper TypeChain types (e.g., ILiFi.BridgeDataStruct) and never use any for bridge data or contract structures
Before/after changes: verify imports and types exist, ensure typechain is generated, keep changes comprehensive and consistent, run TS compilation, remove unused imports, and ensure function signatures match usage
Scripts must execute with bunx tsx

Files:

  • script/deploy/tron/utils.ts
  • script/deploy/tron/deploy-and-register-eco-facet.ts
🧠 Learnings (19)
📓 Common learnings
Learnt from: 0xDEnYO
PR: lifinance/contracts#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.
📚 Learning: 2025-09-12T10:17:51.686Z
Learnt from: CR
PR: lifinance/contracts#0
File: conventions.md:0-0
Timestamp: 2025-09-12T10:17:51.686Z
Learning: Applies to src/Facets/**/*Facet.sol : In {facetName}Data, receiverAddress must be the first field and be validated against bridgeData.receiver; verify targetChainId equals bridgeData.destinationChain for EVM-to-EVM

Applied to files:

  • deployments/unichain.json
  • deployments/base.json
  • deployments/arbitrum.json
  • deployments/mainnet.json
  • deployments/polygon.json
  • deployments/worldchain.json
  • deployments/optimism.json
📚 Learning: 2025-09-25T07:47:30.735Z
Learnt from: ezynda3
PR: lifinance/contracts#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/unichain.json
  • deployments/base.json
  • deployments/ink.json
  • deployments/arbitrum.json
  • deployments/mainnet.json
  • deployments/polygon.json
  • deployments/worldchain.json
  • deployments/optimism.json
📚 Learning: 2025-09-12T10:17:51.686Z
Learnt from: CR
PR: lifinance/contracts#0
File: conventions.md:0-0
Timestamp: 2025-09-12T10:17:51.686Z
Learning: Applies to src/Facets/**/*Facet.sol : Facet contracts must implement: internal _startBridge, swapAndStartBridgeTokensVia{FacetName}, and startBridgeTokensVia{FacetName}

Applied to files:

  • deployments/unichain.json
  • deployments/sonic.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/arbitrum.json
  • deployments/mainnet.json
  • deployments/sonic.json
  • deployments/worldchain.json
📚 Learning: 2025-09-16T01:39:54.099Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#1381
File: deployments/arbitrum.json:65-69
Timestamp: 2025-09-16T01:39:54.099Z
Learning: When verifying facet deployments across .json and .diamond.json files, search by facet name rather than trying to cross-reference addresses between the files, as the same contract can have different addresses in different deployment files.

Applied to files:

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

Applied to files:

  • script/deploy/tron/utils.ts
  • deployments/sonic.json
  • deployments/worldchain.json
  • deployments/celo.json
📚 Learning: 2025-01-28T14:29:00.823Z
Learnt from: ezynda3
PR: lifinance/contracts#924
File: script/deploy/zksync/utils/UpdateScriptBase.sol:112-178
Timestamp: 2025-01-28T14:29:00.823Z
Learning: The suggestion to modify `buildDiamondCut` function in `UpdateScriptBase.sol` to handle selectors from multiple old facets differently was deemed unnecessary by the maintainer.

Applied to files:

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

Applied to files:

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

Applied to files:

  • deployments/_deployments_log_file.json
📚 Learning: 2025-01-09T04:17:46.190Z
Learnt from: ezynda3
PR: lifinance/contracts#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
PR: lifinance/contracts#812
File: deployments/_deployments_log_file.json:1914-1927
Timestamp: 2024-09-30T03:52:27.281Z
Learning: Duplicate entries in `deployments/_deployments_log_file.json` that are outdated do not require changes.

Applied to files:

  • deployments/_deployments_log_file.json
📚 Learning: 2024-12-04T01:59:34.045Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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
PR: lifinance/contracts#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-09-09T10:39:26.383Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.

Applied to files:

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

Applied to files:

  • deployments/_deployments_log_file.json
📚 Learning: 2024-09-27T07:10:15.586Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/polygon.json
📚 Learning: 2025-09-22T00:52:26.172Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/tron.diamond.json
🧬 Code graph analysis (2)
script/deploy/tron/utils.ts (1)
script/deploy/tron/constants.ts (1)
  • ZERO_ADDRESS (45-45)
script/deploy/tron/deploy-and-register-eco-facet.ts (4)
script/deploy/tron/utils.ts (12)
  • getEnvironment (131-138)
  • displayNetworkInfo (1233-1258)
  • tronAddressToHex (1120-1122)
  • confirmDeployment (1147-1185)
  • checkExistingDeployment (665-695)
  • getContractVersion (289-310)
  • deployContractWithLogging (699-753)
  • printDeploymentSummary (1190-1228)
  • getContractAddress (221-240)
  • getFacetSelectors (610-660)
  • displayRegistrationInfo (1263-1283)
  • registerFacetToDiamond (880-1052)
script/demoScripts/utils/demoScriptHelpers.ts (2)
  • getEnvVar (590-596)
  • getPrivateKeyForEnvironment (917-923)
script/deploy/tron/types.ts (2)
  • ITronDeploymentConfig (1-12)
  • IDeploymentResult (66-73)
script/deploy/tron/TronContractDeployer.ts (1)
  • TronContractDeployer (18-529)
⏰ 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 (20)
script/deploy/tron/utils.ts (3)

934-937: Improved address handling with raw value reading.

The change to read currentFacetAddressRaw and explicitly convert to String provides better control over address format handling, which is appropriate for cross-chain deployment utilities.


950-962: LGTM: Robust address normalization for comparison.

The normalized hex comparison using tronWeb.address.toHex() and toLowerCase() ensures consistent address matching regardless of input format (base58 vs hex). The logic correctly identifies when selectors are already registered to the target facet versus needing replacement.


944-945: TRON_ZERO_ADDRESS matches Tron’s standard hex zero address (“41” + 40 zeros).

deployments/unichain.json (1)

38-39: LGTM: EcoFacet deployment entry added.

The EcoFacet entry has been correctly added with proper JSON formatting (trailing comma on the previous entry).

deployments/sonic.json (1)

33-34: LGTM: EcoFacet deployment entry added.

The EcoFacet entry has been correctly added with proper JSON formatting.

deployments/polygon.json (1)

69-70: LGTM: EcoFacet deployment entry added.

The EcoFacet entry has been correctly added. Note that this uses the same address as the Sonic deployment (0x499E4A6585df0638508CA45A6Bb41B9BD385030C), which is expected if EcoFacet is deployed using deterministic deployment (CREATE2).

deployments/worldchain.json (1)

34-35: LGTM: EcoFacet deployment entry added.

The EcoFacet entry has been correctly added with the consistent address used across other networks (0x499E4A6585df0638508CA45A6Bb41B9BD385030C).

deployments/optimism.json (1)

66-67: LGTM: EcoFacet deployment entry added.

The EcoFacet entry has been correctly added with consistent formatting and address.

deployments/arbitrum.json (1)

68-69: LGTM: EcoFacet deployment entry added.

The EcoFacet entry has been correctly added. The consistent address (0x499E4A6585df0638508CA45A6Bb41B9BD385030C) across all networks (arbitrum, optimism, polygon, sonic, worldchain, unichain) suggests deterministic deployment using CREATE2, which is a good practice for cross-chain contract deployments.

config/eco.json (1)

29-34: Confirm portal address updates for Tron and Worldchain

  • Verify TBhZw2sb5DuqGXf3PcxMKDaqxtoZVUUtR7 matches the Portal entry in deployments/tron.json and is live on Tron mainnet
  • Verify worldchain’s portal (0x399Dbd5DF04f83103F77A58cBa2B7c4d3cdede97) intentionally mirrors other EVM chains
deployments/ink.json (1)

33-34: EcoFacet added; syntax OK. Please confirm intended shared address.

  • Trailing comma fix is correct.
  • Verify 0x499E4A6585df0638508CA45A6Bb41B9BD385030C is the intended Ink deployment (same as other EVM networks).

Use the script in the base.json comment to compare addresses across networks.

deployments/tron.diamond.json (1)

55-58: EcoFacet v1.0.0 registration is correct
Single entry found in deployments/tron.diamond.json matching tron.json.

deployments/tron.json (1)

19-20: Confirmed EcoFacet address alignment. TMLwFQAjLQqCJDUNVCVd9c9Q8LLqbmhaW8 is present in tron.diamond.json with Name "EcoFacet", Version "1.0.0".

deployments/base.json (1)

57-58: Confirm EcoFacet address consistency

  • Base, Mainnet, and Celo all use 0x499E4A6585df0638508CA45A6Bb41B9BD385030C; Ink’s address differs (expected for non-EVM)
  • Ensure 0x499E4A6585df0638508CA45A6Bb41B9BD385030C matches the deployments log
deployments/mainnet.json (1)

76-77: EcoFacet entry added and logged correctly
EcoFacet appears in mainnet.json and _deployments_log_file.json with the correct address.

deployments/celo.json (1)

33-34: EcoFacet address consistency confirmed; update public docs/runbooks

The address 0x499E4A6585df0638508CA45A6Bb41B9BD385030C matches all EVM deployments; update any public documentation or runbooks listing available facets per chain.

script/deploy/tron/deploy-and-register-eco-facet.ts (4)

1-32: LGTM!

Imports are well-organized and follow the coding guidelines for TypeScript scripts. All dependencies (citty, consola, tronweb) and helper functions are properly imported.


34-67: LGTM!

Environment setup and credential retrieval follow best practices with clear error messages and proper exit codes. The user-friendly error message on lines 59-64 is particularly helpful.


163-188: LGTM!

Registration flow is well-structured with proper error handling. The script correctly retrieves the diamond address, gets selectors, displays info, and handles both success and failure cases appropriately.


190-219: LGTM!

CLI command definition follows citty best practices and coding guidelines. The dryRun argument is properly defined, and the script orchestrates deployment and registration cleanly.

mirooon
mirooon previously approved these changes Oct 14, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

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

⚠️ Outside diff range comments (1)
script/deploy/tron/utils.ts (1)

197-203: Critical: deployment file path builds produce '.../tron..json' and '.../tron.diamond..json' in production.

The extra dot before an empty suffix yields invalid filenames. Fix to choose the full filename suffix, not a prefix.

Apply:

@@
-  const fileSuffix =
-    environment === EnvironmentEnum.production ? '' : 'staging.'
-  const deploymentFile = resolve(
-    process.cwd(),
-    `deployments/${network}.${fileSuffix}json`
-  )
+  const fileSuffix =
+    environment === EnvironmentEnum.production ? 'json' : 'staging.json'
+  const deploymentFile = resolve(
+    process.cwd(),
+    `deployments/${network}.${fileSuffix}`
+  )
@@
-  const fileSuffix =
-    environment === EnvironmentEnum.production ? '' : 'staging.'
-  const deploymentFile = resolve(
-    process.cwd(),
-    `deployments/${network}.${fileSuffix}json`
-  )
+  const fileSuffix =
+    environment === EnvironmentEnum.production ? 'json' : 'staging.json'
+  const deploymentFile = resolve(
+    process.cwd(),
+    `deployments/${network}.${fileSuffix}`
+  )
@@
-  const fileSuffix =
-    environment === EnvironmentEnum.production ? '' : 'staging.'
-  const diamondFile = resolve(
-    process.cwd(),
-    `deployments/${network}.diamond.${fileSuffix}json`
-  )
+  const fileSuffix =
+    environment === EnvironmentEnum.production ? 'json' : 'staging.json'
+  const diamondFile = resolve(
+    process.cwd(),
+    `deployments/${network}.diamond.${fileSuffix}`
+  )

Also applies to: 225-231, 250-256

🧹 Nitpick comments (3)
script/deploy/tron/utils.ts (2)

1410-1422: Optional: tighten Base58 regex for Tron addresses in parser.

Current [A-Za-z0-9] includes invalid Base58 chars (0,O,I,l). Use Base58 charset to reduce false matches.

-  const facetRegex = /\[([T][A-Za-z0-9]{33})\s+\[((?:0x[a-fA-F0-9]+\s*)*)\]\]/g
+  const facetRegex = /\[([T][1-9A-HJ-NP-Za-km-z]{33})\s+\[((?:0x[a-fA-F0-9]+\s*)*)\]\]/g

113-126: Optional: include stderr in shell command failures for better diagnostics.

Currently only stdout is captured. Add stderr to error message/context.

 export async function executeShellCommand(command: string): Promise<string> {
-  const proc = Bun.spawn(['bash', '-c', command], {
+  const proc = Bun.spawn(['bash', '-c', command], {
     cwd: process.cwd(),
     env: process.env,
   })
 
-  const output = await new Response(proc.stdout).text()
+  const [output, err] = await Promise.all([
+    new Response(proc.stdout).text(),
+    new Response(proc.stderr).text(),
+  ])
   const exitCode = await proc.exited
 
-  if (exitCode !== 0)
-    throw new Error(`Command failed with exit code ${exitCode}: ${command}`)
+  if (exitCode !== 0)
+    throw new Error(
+      `Command failed (${exitCode}): ${command}\nSTDERR:\n${err.trim()}`
+    )
 
   return output.trim()
 }
deployments/_deployments_log_file.json (1)

43394-43526: Pre‑deploy checklist reminder (external/privileged calls + audit).

Before merge/deploy, ensure:

  • Arbitrary external calls are validated/restricted.
  • Privileged/storage‑modifying calls are validated/restricted.
  • New facet has at least one preliminary audit; record date and auditor.
📜 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 2d38d75 and 9252820.

📒 Files selected for processing (16)
  • config/eco.json (1 hunks)
  • deployments/_deployments_log_file.json (1 hunks)
  • deployments/arbitrum.json (1 hunks)
  • deployments/base.json (1 hunks)
  • deployments/celo.json (1 hunks)
  • deployments/ink.json (1 hunks)
  • deployments/mainnet.json (1 hunks)
  • deployments/optimism.json (1 hunks)
  • deployments/polygon.json (1 hunks)
  • deployments/sonic.json (1 hunks)
  • deployments/tron.diamond.json (1 hunks)
  • deployments/tron.json (1 hunks)
  • deployments/unichain.json (1 hunks)
  • deployments/worldchain.json (1 hunks)
  • script/deploy/tron/deploy-and-register-eco-facet.ts (1 hunks)
  • script/deploy/tron/utils.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
script/**/*.ts

📄 CodeRabbit inference engine (conventions.md)

script/**/*.ts: All TypeScript scripts must follow .eslintrc.cjs, use async/await, try/catch error handling, proper logging, environment variables, correct typings, use citty for CLI parsing, consola for logging, validate env vars via getEnvVar(), and exit with appropriate codes
Prefer existing helper functions over reimplementation (e.g., getDeployments, getProvider, getWalletFromPrivateKeyInDotEnv, sendTransaction, ensureBalanceAndAllowanceToDiamond, getUniswapData*)
Always use proper TypeChain types (e.g., ILiFi.BridgeDataStruct) and never use any for bridge data or contract structures
Before/after changes: verify imports and types exist, ensure typechain is generated, keep changes comprehensive and consistent, run TS compilation, remove unused imports, and ensure function signatures match usage
Scripts must execute with bunx tsx

Files:

  • script/deploy/tron/utils.ts
  • script/deploy/tron/deploy-and-register-eco-facet.ts
🧠 Learnings (17)
📓 Common learnings
Learnt from: mirooon
PR: lifinance/contracts#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
PR: lifinance/contracts#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
PR: lifinance/contracts#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.
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/arbitrum.json
  • deployments/sonic.json
  • script/deploy/tron/utils.ts
  • deployments/worldchain.json
📚 Learning: 2025-09-25T07:47:30.735Z
Learnt from: ezynda3
PR: lifinance/contracts#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/arbitrum.json
  • deployments/optimism.json
  • deployments/unichain.json
  • deployments/ink.json
  • deployments/polygon.json
  • deployments/mainnet.json
  • deployments/worldchain.json
  • deployments/base.json
📚 Learning: 2025-09-12T10:17:51.686Z
Learnt from: CR
PR: lifinance/contracts#0
File: conventions.md:0-0
Timestamp: 2025-09-12T10:17:51.686Z
Learning: Applies to src/Facets/**/*Facet.sol : In {facetName}Data, receiverAddress must be the first field and be validated against bridgeData.receiver; verify targetChainId equals bridgeData.destinationChain for EVM-to-EVM

Applied to files:

  • deployments/arbitrum.json
  • deployments/optimism.json
  • deployments/unichain.json
  • deployments/polygon.json
  • deployments/mainnet.json
  • deployments/worldchain.json
  • deployments/base.json
📚 Learning: 2025-04-21T03:17:53.443Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/sonic.json
  • script/deploy/tron/utils.ts
  • deployments/worldchain.json
📚 Learning: 2025-09-12T10:17:51.686Z
Learnt from: CR
PR: lifinance/contracts#0
File: conventions.md:0-0
Timestamp: 2025-09-12T10:17:51.686Z
Learning: Applies to src/Facets/**/*Facet.sol : Facet contracts must implement: internal _startBridge, swapAndStartBridgeTokensVia{FacetName}, and startBridgeTokensVia{FacetName}

Applied to files:

  • deployments/sonic.json
  • deployments/unichain.json
📚 Learning: 2025-09-16T01:39:54.099Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#1381
File: deployments/arbitrum.json:65-69
Timestamp: 2025-09-16T01:39:54.099Z
Learning: When verifying facet deployments across .json and .diamond.json files, search by facet name rather than trying to cross-reference addresses between the files, as the same contract can have different addresses in different deployment files.

Applied to files:

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

Applied to files:

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

Applied to files:

  • deployments/_deployments_log_file.json
📚 Learning: 2025-05-28T17:33:33.959Z
Learnt from: mirooon
PR: lifinance/contracts#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-08-07T10:20:01.383Z
Learnt from: mirooon
PR: lifinance/contracts#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: 2024-12-04T01:59:34.045Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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-09-09T10:39:26.383Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#1357
File: deployments/lens.diamond.json:48-51
Timestamp: 2025-09-09T10:39:26.383Z
Learning: In the lifinance/contracts repository, when deployment JSON files show address changes (like AcrossFacetV3 address updates in deployments/*.diamond.json), the corresponding _deployments_log_file.json updates may be handled in separate PRs rather than the same PR that updates the diamond configuration files.

Applied to files:

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

Applied to files:

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

Applied to files:

  • deployments/_deployments_log_file.json
📚 Learning: 2025-01-09T04:17:46.190Z
Learnt from: ezynda3
PR: lifinance/contracts#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-09-22T00:52:26.172Z
Learnt from: 0xDEnYO
PR: lifinance/contracts#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/tron.diamond.json
🧬 Code graph analysis (2)
script/deploy/tron/utils.ts (1)
script/deploy/tron/constants.ts (1)
  • ZERO_ADDRESS (45-45)
script/deploy/tron/deploy-and-register-eco-facet.ts (5)
script/deploy/tron/utils.ts (12)
  • getEnvironment (131-138)
  • validateBalance (1127-1142)
  • tronAddressToHex (1120-1122)
  • confirmDeployment (1147-1185)
  • checkExistingDeployment (665-695)
  • getContractVersion (289-310)
  • deployContractWithLogging (699-753)
  • printDeploymentSummary (1190-1228)
  • getContractAddress (221-240)
  • getFacetSelectors (610-660)
  • displayRegistrationInfo (1263-1283)
  • registerFacetToDiamond (880-1052)
script/demoScripts/utils/demoScriptHelpers.ts (2)
  • getEnvVar (590-596)
  • getPrivateKeyForEnvironment (917-923)
script/deploy/tron/types.ts (2)
  • ITronDeploymentConfig (1-12)
  • IDeploymentResult (66-73)
script/deploy/tron/TronContractDeployer.ts (1)
  • TronContractDeployer (18-529)
script/deploy/tron/constants.ts (1)
  • MIN_BALANCE_WARNING (14-14)
🪛 Gitleaks (8.28.0)
deployments/tron.json

[high] 20-20: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: run-unit-tests
🔇 Additional comments (13)
deployments/tron.diamond.json (1)

55-58: EcoFacet mapping already present in deployments/tron.json — no changes required.

Likely an incorrect or invalid review comment.

deployments/ink.json (1)

33-34: Confirm EcoFacet address consistency
The EcoFacet address in deployments/ink.json (0xad8fEeFf8BC2d19495A0D5B1E1e287bAA67cA0Db) matches deployments/unichain.json. Manually verify any deployment logs or target-state files reference this same address to prevent drift.

script/deploy/tron/utils.ts (2)

4-4: Use named import for TronWeb v6.x
TronWeb v6.x switched to named exports; import { TronWeb } from 'tronweb' is correct.

Likely an incorrect or invalid review comment.


934-962: Selector registration logic: robust hex normalization and zero-address checks — LGTM.

Add a debug log or test call to confirm that diamond.facetAddress(selector).call() returns a hex or base58 string compatible with tronWeb.address.toHex.

deployments/mainnet.json (1)

76-77: EcoFacet mainnet address matches other primary networks — confirm this deterministic address is correct on-chain.

deployments/worldchain.json (1)

34-35: Worldchain diamond.json missing EcoFacet mapping

EcoFacet was added to deployments/worldchain.json but no corresponding entry was found in deployments/worldchain.diamond.json; ensure the facet is registered under the correct key in the diamond config.

config/eco.json (1)

29-33: Mixed-format portal addresses already supported
Solidity deploy scripts parse hex portals via stdJson.readAddress; Tron TS scripts convert Base58 via tronAddressToHex.

script/deploy/tron/deploy-and-register-eco-facet.ts (2)

1-32: LGTM!

The import structure and setup follow the coding guidelines correctly, using citty for CLI parsing, consola for logging, and importing appropriate helper functions from the utility modules.


200-219: LGTM!

The CLI definition follows the coding guidelines correctly, using defineCommand and runMain from citty with a clear dryRun flag for safe testing.

deployments/_deployments_log_file.json (4)

43395-43407: Log entries look consistent with prior schema.

Addresses, constructor args, optimizer runs, and verified flags align with existing patterns. Duplicate addresses across different networks are acceptable for logs.

Based on learnings


43398-43405: Confirm deterministic address method vs empty SALT.

Same ADDRESS appears across multiple chains while SALT is empty. If CREATE2 was used, consider recording the salt; if not, please confirm how deterministic addressing was achieved.

Based on learnings

Also applies to: 43428-43435, 43443-43450, 43473-43480, 43503-43510, 43518-43525


43395-43396: Verify timestamp convention (timezone/format).

Timestamps are uniform; confirm they follow the repo’s standard timezone and format for this log.

Based on learnings

Also applies to: 43415-43416, 43445-43446, 43460-43461, 43475-43476, 43505-43506, 43520-43521


43394-43526: Add EcoFacet to diamond deployments and target state
EcoFacet is present in each deployments/.json but missing from all deployments/.diamond.json files and from script/deploy/_targetState.json. Add EcoFacet entries with version 1.0.0 and the corresponding addresses across those files.

⛔ Skipped due to learnings
Learnt from: 0xDEnYO
PR: lifinance/contracts#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: 0xDEnYO
PR: lifinance/contracts#1388
File: deployments/hyperevm.diamond.json:72-75
Timestamp: 2025-09-22T00:52:26.172Z
Learning: In diamond configuration files (deployments/*.diamond.json), it's acceptable to have multiple versions of the same facet (e.g., GlacisFacet v1.0.0 and v1.1.0) deployed at different contract addresses. This is intentional design for version coexistence, gradual migration, or backward compatibility purposes.
Learnt from: 0xDEnYO
PR: lifinance/contracts#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: 0xDEnYO
PR: lifinance/contracts#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.
Learnt from: 0xDEnYO
PR: lifinance/contracts#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
PR: lifinance/contracts#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
PR: lifinance/contracts#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.
Learnt from: ezynda3
PR: lifinance/contracts#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.
Learnt from: 0xDEnYO
PR: lifinance/contracts#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
PR: lifinance/contracts#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.

@mirooon mirooon merged commit 6838031 into main Oct 14, 2025
19 checks passed
@mirooon mirooon deleted the deploy-eco-facet branch October 14, 2025 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants