deployed stargate to gnosis #993
Conversation
|
Warning Rate limit exceeded@0xDEnYO has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 12 minutes and 30 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (4)
WalkthroughThis pull request updates multiple configuration and deployment files. In Changes
Possibly related PRs
Suggested labels
Suggested reviewers
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
deployments/_deployments_log_file.json (1)
24472-24473: Consider using deterministic deployment with SALT.The
SALTfield is empty for both deployments. Consider using a deterministic deployment approach with CREATE2 by providing a SALT value. This helps in verifying that the same contract is deployed across different environments.Also applies to: 24766-24767
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
config/stargate.json(1 hunks)deployments/_deployments_log_file.json(2 hunks)deployments/gnosis.json(1 hunks)script/deploy/_targetState.json(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
script/deploy/_targetState.json (2)
Learnt from: mirooon
PR: lifinance/contracts#985
File: script/deploy/_targetState.json:0-0
Timestamp: 2025-02-12T09:44:12.961Z
Learning: The bsca network intentionally maintains different facet versions between staging and production environments, specifically:
1. CalldataVerificationFacet: v1.1.1 in staging vs v1.1.2 in production
2. EmergencyPauseFacet: present only in production
3. Permit2Proxy: present only in production
Learnt from: ezynda3
PR: lifinance/contracts#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.
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: enforce-min-test-coverage
- GitHub Check: run-unit-tests
- GitHub Check: run-unit-tests
- GitHub Check: enforce-min-test-coverage
- GitHub Check: generate-tag
🔇 Additional comments (5)
deployments/gnosis.json (1)
38-40: LGTM! Stargate facets deployed to gnosis.The addresses for
StargateFacetV2andReceiverStargateV2match the configuration inscript/deploy/_targetState.jsonfor the gnosis production environment.config/stargate.json (1)
57-57: Note: Fantom is not supported by Stargate V2.The configuration indicates that Fantom is not supported by Stargate V2. Please ensure that any existing integrations with Fantom are properly handled or disabled.
script/deploy/_targetState.json (1)
265-267: Verify version differences between environments.The gnosis environment uses different versions compared to other environments:
- StargateFacetV2: v2.2.0 (others use v1.0.1)
- ReceiverStargateV2: v1.1.0 (others use v1.0.0 or v1.1.0)
Please confirm if these version differences are intentional.
Run the following script to check version differences:
❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Check version differences for StargateFacetV2 and ReceiverStargateV2 across environments. echo "StargateFacetV2 versions:" rg -A 1 '"StargateFacetV2":' echo -e "\nReceiverStargateV2 versions:" rg -A 1 '"ReceiverStargateV2":'Length of output: 22645
Confirmed: Version discrepancies exist between environments.
The grep output shows that while most environment configurations in
script/deploy/_targetState.jsonuse:
- StargateFacetV2: "1.0.1"
- ReceiverStargateV2: "1.0.0"
there is a distinct block—presumably for the gnosis environment—that sets:
- StargateFacetV2: "2.2.0"
- ReceiverStargateV2: "1.1.0"
Please verify with the team that these version differences are intentional.
deployments/_deployments_log_file.json (2)
24470-24470:⚠️ Potential issueFix incorrect deployment timestamps.
Both deployment entries have timestamps set in the future (2025). This appears to be incorrect as deployments should have current or past timestamps.
Please update the timestamps to reflect the actual deployment dates.
Also applies to: 24764-24764
⛔ 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.Learnt from: ezynda3 PR: lifinance/contracts#861 File: deployments/_deployments_log_file.json:22488-22488 Timestamp: 2024-11-22T07:19:51.143Z Learning: In `deployments/_deployments_log_file.json`, deployment timestamps may appear to be set in the future and should not be flagged as invalid.
24471-24471: Verify constructor arguments and contract addresses.The constructor arguments contain multiple addresses that should be verified for correctness. Let's validate these addresses and their roles:
Also applies to: 24765-24765
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Verify the addresses in constructor args and deployment addresses # Extract and decode constructor args echo "Version 1.0.1 constructor args:" echo "0x000000000000000000000000af368c91793cb22739386dfcbbb2f1a9e4bcbebf" | \ python3 -c "import sys; print('Address:', '0x' + sys.stdin.read().strip()[26:])" echo -e "\nVersion 1.1.0 constructor args (multiple addresses):" ARGS="0x000000000000000000000000156cebba59deb2cb23742f70dcb0a11cc775591f0000000000000000000000002dfadab8266483bed9fd9a292ce56596a2d1378d000000000000000000000000af368c91793cb22739386dfcbbb2f1a9e4bcbebf0000000000000000000000001a44076050125825900e736c501f859c50fe728c00000000000000000000000000000000000000000000000000000000000186a0" for i in {0..3}; do start=$((26 + i*64)) echo "Address $((i+1)): 0x${ARGS:$start:40}" done echo "Value: 0x${ARGS:282:64}" # Check if these addresses have code deployed echo -e "\nChecking deployment addresses on Gnosis chain:" echo "Version 1.0.1: 0xCB68AAcEb848E5007B56b1ff09D240CE8946B4EC" echo "Version 1.1.0: 0x0dC56076590CdF0efc37114273f02f45A96B5500"Length of output: 1798
Verification Complete: Constructor Arguments and Deployment Addresses Are Correct
- Version 1.0.1 constructor arg correctly decodes to:
0xaf368c91793cb22739386dfcbbb2f1a9e4bcbebf- Version 1.1.0 constructor arguments correctly extract the following addresses:
• Address 1: 0x156cebba59deb2cb23742f70dcb0a11cc775591f
• Address 2: 0x2dfadab8266483bed9fd9a292ce56596a2d1378d
• Address 3: 0xaf368c91793cb22739386dfcbbb2f1a9e4bcbebf
• Address 4: 0x1a44076050125825900e736c501f859c50fe728c- The parsed value is as expected (0x00000000000000000000000000000000000186a0)
- Deployment addresses on the Gnosis chain are correctly listed:
• Version 1.0.1: 0xCB68AAcEb848E5007B56b1ff09D240CE8946B4EC
• Version 1.1.0: 0x0dC56076590CdF0efc37114273f02f45A96B5500All extracted addresses and deployment addresses appear to have been processed correctly. No issues were identified during the verification.
Test Coverage ReportLine Coverage: 78.66% (2238 / 2845 lines) |
…rgateV2-to-gnosis
Which Jira task belongs to this PR?
https://lifi.atlassian.net/browse/LF-12362
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)