Redeploy Relay to Mode and Scroll

[ezynda3]

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 pull request introduces comprehensive updates to the config/relay.json file, involving significant reorganization of network configurations and chain ID assignments. The changes include renaming existing sections, adding new network entries like "boba," "zksync," and "zora," and systematically updating chain IDs for various networks such as mainnet, optimism, polygon, and others. Additionally, deployment-related JSON files for Mode and Scroll are updated, specifically modifying the RelayFacet address across multiple configuration files.

Changes

File	Change Summary
config/relay.json	- Added comment about file generation - Updated/renamed network sections (e.g., polygon → bsc, base → gnosis) - Added chainId for multiple networks - Introduced new network sections (boba, zksync, worldchain, etc.)
deployments/_deployments_log_file.json	- Updated deployment address - Modified timestamps - Updated constructor arguments and salt value
deployments/mode.diamond.json	- Updated RelayFacet address to 0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E
deployments/mode.json	- Updated RelayFacet address to 0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E
deployments/scroll.diamond.json	- Updated RelayFacet address to 0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E
deployments/scroll.json	- Updated RelayFacet address to 0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E

Possibly related PRs

• Debridge DLN Facet (Version 1.0.0) [DeBridgeDlnFacet v1.0.0] #827: DeBridgeDlnFacet changes related to bridging functionalities
• Deploy CBridge to Gravity #856: Modifications to network configurations in config/cbridge.json
• Redeploy relay facet #929: Redeployment of relay facet

Suggested labels

AuditNotRequired

Suggested reviewers

• maxklenk

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 01b78ad and 6fdf301.

📒 Files selected for processing (6)

• config/relay.json (1 hunks)
• deployments/_deployments_log_file.json (2 hunks)
• deployments/mode.diamond.json (1 hunks)
• deployments/mode.json (1 hunks)
• deployments/scroll.diamond.json (1 hunks)
• deployments/scroll.json (1 hunks)

🧰 Additional context used

📓 Learnings (2)

deployments/scroll.diamond.json (1)

Learnt from: 0xDEnYO
PR: lifinance/contracts#819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-11-12T09:43:10.543Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.

deployments/mode.diamond.json (1)

Learnt from: 0xDEnYO
PR: lifinance/contracts#819
File: deployments/scroll.diamond.json:82-82
Timestamp: 2024-11-12T09:43:10.543Z
Learning: In the `deployments/*.diamond.json` and `deployments/*.json` files, the `LiFiDEXAggregator` contract may intentionally have the same contract address across multiple networks. This is acceptable and should not be flagged as an issue in future code reviews.

⏰ Context from checks skipped due to timeout of 90000ms (5)

• GitHub Check: enforce-min-test-coverage
• GitHub Check: run-unit-tests
• GitHub Check: enforce-min-test-coverage
• GitHub Check: run-unit-tests
• GitHub Check: analyze

🔇 Additional comments (12)

deployments/mode.json (1)

34-34: Verify the RelayFacet contract deployment.

The RelayFacet address has been updated. Let's verify the contract deployment and its bytecode.

✅ Verification successful

✓ RelayFacet contract deployment verified

Contract is properly deployed at 0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E with expected implementation and consistent references across deployment files.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify RelayFacet contract deployment and bytecode consistency

# Check if the contract exists and has code at the new address
curl -s -X POST -H "Content-Type: application/json" --data '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getCode",
  "params": ["0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E", "latest"]
}' https://mode-mainnet.rpc.thirdweb.com

Length of output: 257

---

Script:

#!/bin/bash
# Description: Verify RelayFacet contract deployment using official Mode RPC

# Check if the contract exists and has code at the new address
curl -s -X POST -H "Content-Type: application/json" --data '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getCode",
  "params": ["0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E", "latest"]
}' https://mainnet.mode.network

# Also check other deployment files for consistency
echo -e "\nChecking address consistency across deployment files:"
rg -i "0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E" --type json

Length of output: 25907

deployments/scroll.json (1)

38-38: LGTM! Address consistent with Mode deployment.

The RelayFacet address matches the Mode deployment, which is expected for this redeployment.

deployments/mode.diamond.json (1)

88-91: Verify RelayFacet version consistency.

The RelayFacet is configured with version 1.0.0. Let's verify this version is consistent with the implementation.

✅ Verification successful

Version 1.0.0 is correctly configured for RelayFacet

The version declared in mode.diamond.json matches the contract implementation's @Custom:version tag and audit report.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check RelayFacet version consistency across files

# Search for version declarations in RelayFacet contract
ast-grep --pattern 'contract RelayFacet {
  $$$
  string constant VERSION = "$_";
  $$$
}'

Length of output: 92

---

Script:

#!/bin/bash
# Find RelayFacet contract file
fd RelayFacet

# If found, examine its contents
fd RelayFacet --exec cat {}

Length of output: 92520

deployments/scroll.diamond.json (1)

104-107: LGTM! Configuration consistent with Mode deployment.

The RelayFacet configuration matches the Mode deployment, maintaining consistency across networks.

config/relay.json (4)

2-2: Important note about file modification.

This file is generated by a backend script and should not be modified manually. Ensure all changes are made through the appropriate backend process.

---

28-32: Verify chain configurations for newly deployed networks.

The configuration includes new entries for Boba, ZkSync, Mode, and Scroll networks. Let's verify the chain IDs and relay addresses.

Also applies to: 33-37, 73-77, 108-112

✅ Verification successful

Chain configurations for new networks are valid

The configurations for Boba, ZkSync, Mode, and Scroll networks have been verified:

• All chain IDs are unique and valid
• All addresses follow the correct Ethereum address format
• The configuration structure is consistent with other networks

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify chain IDs and address formats

# Check for any duplicate chain IDs
jq -r '.[] | select(.chainId != null) | .chainId' config/relay.json | sort -n | uniq -d

# Verify address format for new networks
jq -r '.[] | select(.relayReceiver != null) | .relayReceiver' config/relay.json | grep -v '^0x[a-fA-F0-9]\{40\}$' || true
jq -r '.[] | select(.relaySolver != null) | .relaySolver' config/relay.json | grep -v '^0x[a-fA-F0-9]\{40\}$' || true

Length of output: 581

---

Script:

#!/bin/bash
# First, validate JSON syntax and view structure
echo "=== JSON validation and structure ==="
cat config/relay.json

# If the file is large, we can alternatively just check the specific sections
echo -e "\n=== Specific network configurations ==="
grep -A4 '"boba"\|"zksync"\|"mode"\|"scroll"' config/relay.json

Length of output: 4993

---

30-31: Verify relay receiver addresses across networks.

The relay receiver addresses vary across networks. This is expected but should be verified for correctness.

Also applies to: 35-36, 75-76, 110-111

✅ Verification successful

Relay receiver addresses verified across networks

The variation in relay receiver addresses across different networks appears intentional and follows a consistent pattern. Major networks share common addresses while specialized chains have distinct configurations. This aligns with the comment indicating the file is generated by a backend script.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Group and compare relay receiver addresses

# List unique relay receivers and their networks
jq -r 'to_entries | .[] | select(.value.relayReceiver != null) | [.key, .value.relayReceiver] | @tsv' config/relay.json | sort -k2

Length of output: 218

---

Script:

#!/bin/bash
# First, let's examine the content of the file
cat config/relay.json

Length of output: 4060

---

31-31: Verify relay solver consistency.

The same relay solver address is used across all networks, which appears to be intentional.

Also applies to: 36-36, 76-76, 111-111

✅ Verification successful

Relay solver address consistency verified

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify relay solver consistency

# Check if all networks use the same solver
jq -r 'to_entries | .[] | select(.value.relaySolver != null) | .value.relaySolver' config/relay.json | sort | uniq -c

Length of output: 203

---

Script:

#!/bin/bash
# First, let's see the content of the file
cat config/relay.json

Length of output: 4060

---

Script:

#!/bin/bash
# Count unique relaySolver addresses
jq -r 'values | .relaySolver' config/relay.json | sort | uniq -c

Length of output: 79

---

Script:

#!/bin/bash
# Count unique relaySolver addresses with proper nested structure handling
jq -r 'to_entries[] | .value.relaySolver' config/relay.json | sort | uniq -c

Length of output: 162

deployments/_deployments_log_file.json (4)

26767-26767: ⚠️ Potential issue

Fix incorrect future timestamps.

The deployment timestamps are set to 2025, which is incorrect as deployments should have current timestamps.

Update the timestamps to reflect the actual deployment time.

Also applies to: 26809-26809

⛔ Skipped due to learnings

Learnt from: ezynda3
PR: lifinance/contracts#823
File: deployments/_deployments_log_file.json:10542-10543
Timestamp: 2024-11-21T08:17:27.878Z
Learning: When reviewing deployment timestamps in `deployments/_deployments_log_file.json`, ensure that the timestamps are accurately compared with the current date to avoid incorrectly flagging valid timestamps as future deployment dates.

---

26769-26769: Verify the salt value usage.

Both deployments use the same salt value "17012025". Please confirm if this is intentional and verify that it hasn't been used in previous deployments to avoid potential conflicts.

Let's check the salt usage:

Also applies to: 26811-26811

✅ Verification successful

Salt reuse is valid in this context ✅

The same salt value is intentionally used for two deployments to the same contract address (0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E) that occurred minutes apart on 2025-01-17. This appears to be a deployment retry or update, which is a valid use case for salt reuse. The salt value follows the established date-based format pattern seen in other deployments.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify salt value uniqueness

# Check if this salt has been used before
echo "Checking salt usage in previous deployments..."
rg -l "SALT.*17012025" deployments/

Length of output: 179

---

Script:

#!/bin/bash
# Show the actual occurrences of the salt with context
echo "Checking detailed salt usage..."
rg -C 5 '"SALT".*17012025' deployments/_deployments_log_file.json

# Check for any salt patterns in recent deployments
echo -e "\nChecking recent salt patterns..."
rg -C 1 '"SALT".*202[45]' deployments/_deployments_log_file.json | tail -n 20

Length of output: 2465

---

26765-26765: Verify the new RelayFacet contract address.

The same RelayFacet address (0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E) is being used for both Mode and Scroll deployments. Please verify:

1. The contract at this address has been properly deployed
2. The contract code matches the expected RelayFacet implementation

Let's verify this address:

Also applies to: 26807-26807

✅ Verification successful

RelayFacet address verification successful ✅

The same address is intentionally achieved through deterministic deployment (CREATE2) with:

• Verified contract deployments on both networks
• Network-specific configuration through different constructor arguments
• Successful deployment confirmation on 2025-01-17

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify RelayFacet address usage and deployment

# Check if this address is consistently used across all relevant config files
echo "Checking RelayFacet address usage..."
rg -l "0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E"

# Check if this is a new address or reused from previous deployments
echo "Checking previous deployments..."
rg -l "ADDRESS.*0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E" deployments/

Length of output: 469

---

Script:

#!/bin/bash
# Get more context around the address usage in each file
echo "=== Checking scroll.json ==="
rg -B 2 -A 2 "0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E" deployments/scroll.json

echo -e "\n=== Checking mode.json ==="
rg -B 2 -A 2 "0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E" deployments/mode.json

echo -e "\n=== Checking deployment history ==="
rg -B 5 -A 5 "0xB3D1fB435af4E8a185a9bC68f1Cf142EF82D213E" deployments/_deployments_log_file.json

# Look for deployment transaction details
echo -e "\n=== Checking for deployment transactions ==="
rg -B 2 -A 2 "RelayFacet.*deploy" deployments/_deployments_log_file.json

Length of output: 1974

---

26768-26768: Verify constructor arguments for Mode and Scroll deployments.

The constructor arguments differ between deployments but share the same second parameter (0xf70da97812cb96acdf810712aa562db8dfa3dbef). Please verify:

1. First deployment args are correct for Mode
2. Second deployment args are correct for Scroll

Let's verify these addresses:

Also applies to: 26810-26810

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[lifi-action-bot]

Test Coverage Report

Line Coverage: 78.66% (2238 / 2845 lines)
Function Coverage: 84.71% ( 388 / 458 functions)
Branch Coverage: 39.60% ( 221 / 558 branches)
Test coverage (78.66%) is above min threshold (76%). Check passed.