Deploy all contracts to soneium #994
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 13 minutes and 50 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 (18)
WalkthroughThis pull request implements a comprehensive set of changes to integrate the Soneium network across the project. New environment variables and RPC endpoints are introduced, and configuration files are updated with Soneium-specific chain IDs, addresses, and network properties. Deployment logs and mapping files are extended with versioned entries for Soneium, while deployment and task scripts are modified to handle conditional execution (using the new Changes
Possibly related PRs
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 (
|
lifi-action-bot
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
script/tasks/updateERC20Proxy.sh (1)
16-16: Fix potential masking of return value.The current assignment might mask the return value of getRPCUrl.
- local RPC_URL=$(getRPCUrl "$NETWORK") + local RPC_URL + RPC_URL=$(getRPCUrl "$NETWORK")🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 16-16: Declare and assign separately to avoid masking return values.
(SC2155)
config/global.json (1)
54-66: Verify the completeness of core facets.Please ensure all required facets for the Soneium network deployment are included. The current list appears to have the essential facets (AccessManager, CalldataVerification, DexManager, etc.).
Consider documenting the minimum required set of facets for a new network deployment to ensure consistency across future deployments.
deployments/soneium.diamond.json (1)
3-68: Verify facet versions and completeness.The deployment includes all core facets with appropriate versions. However, please verify:
- Are these the latest stable versions for each facet?
- Have all these facet versions been audited?
Consider maintaining a version matrix document that maps network requirements to minimum facet versions to ensure consistent deployments.
config/networks.json (1)
614-630: Review Safe configuration for Soneium network.The Safe configuration is using Optimism's UI URL (safe.optimism.io) which may not be optimal. Consider setting up a dedicated Safe UI instance for Soneium or using the generic Safe UI.
- "safeWebUrl": "https://safe.optimism.io/transactions/queue?safe=soneium:0x245B16CaCE8730b009c5352186DcE7d73c3037A1", + "safeWebUrl": "https://app.safe.global/transactions/queue?safe=soneium:0x245B16CaCE8730b009c5352186DcE7d73c3037A1",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (26)
.env.example(1 hunks).github/workflows/diamondEmergencyPause.yml(1 hunks)config/across.json(1 hunks)config/amarok.json(1 hunks)config/dexs.json(1 hunks)config/gaszip.json(1 hunks)config/global.json(2 hunks)config/networks.json(1 hunks)config/permit2Proxy.json(1 hunks)config/relay.json(1 hunks)config/stargate.json(4 hunks)config/tokenwrapper.json(1 hunks)deployments/_deployments_log_file.json(27 hunks)deployments/soneium.diamond.json(1 hunks)deployments/soneium.json(1 hunks)foundry.toml(2 hunks)networks(1 hunks)script/config.example.sh(1 hunks)script/deploy/_targetState.json(5 hunks)script/deploy/deployAllContracts.sh(2 hunks)script/deploy/facets/UpdateCoreFacets.s.sol(3 hunks)script/deploy/healthCheck.ts(6 hunks)script/deploy/resources/contractSpecificReminders.sh(1 hunks)script/tasks/diamondUpdateFacet.sh(2 hunks)script/tasks/diamondUpdatePeriphery.sh(2 hunks)script/tasks/updateERC20Proxy.sh(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- networks
- deployments/soneium.json
🧰 Additional context used
🧠 Learnings (4)
config/amarok.json (1)
Learnt from: ezynda3
PR: lifinance/contracts#875
File: config/amarok.json:111-116
Timestamp: 2024-11-26T07:14:08.986Z
Learning: For the Lisk chain (chainId 1135), it's acceptable to have an empty `connextHandler`, `domain`, and `tokensToApprove` in `config/amarok.json` even if `networks.json` marks Lisk as `"status": "active"`.
.github/workflows/diamondEmergencyPause.yml (1)
Learnt from: 0xDEnYO
PR: lifinance/contracts#894
File: .github/workflows/diamondEmergencyPause.yml:82-82
Timestamp: 2024-12-05T03:42:41.402Z
Learning: The `ETH_NODE_URI_WORLDCHAIN` secret is correctly configured in the GitHub repository.
script/tasks/diamondUpdateFacet.sh (1)
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.
script/deploy/_targetState.json (1)
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
🪛 Shellcheck (0.10.0)
script/config.example.sh
[warning] 108-108: DEPLOY_NEW_NETWORK_MODE appears unused. Verify use (or export if used externally).
(SC2034)
script/deploy/resources/contractSpecificReminders.sh
[warning] 9-9: GasZipPeriphery appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 10-10: LiFiDEXAggregator appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 11-11: TokenWrapper appears unused. Verify use (or export if used externally).
(SC2034)
script/tasks/diamondUpdatePeriphery.sh
[warning] 190-190: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 190-190: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 194-194: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 198-198: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 198-198: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 198-198: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 211-211: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 211-211: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 215-215: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 222-222: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 222-222: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 222-222: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
script/tasks/diamondUpdateFacet.sh
[warning] 128-128: script is referenced but not assigned (did you mean 'SCRIPT'?).
(SC2154)
[warning] 129-129: This assignment is only seen by the forked process.
(SC2097)
[warning] 129-129: This expansion will not see the mentioned assignment.
(SC2098)
[warning] 155-155: This assignment is only seen by the forked process.
(SC2097)
[warning] 155-155: This expansion will not see the mentioned assignment.
(SC2098)
[warning] 159-159: Quote this to prevent word splitting.
(SC2046)
script/tasks/updateERC20Proxy.sh
[warning] 16-16: Declare and assign separately to avoid masking return values.
(SC2155)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: enforce-min-test-coverage
- GitHub Check: run-unit-tests
🔇 Additional comments (32)
script/deploy/facets/UpdateCoreFacets.s.sol (3)
11-11: LGTM! Import of EmergencyPauseFacet.The import is correctly added and follows the existing pattern.
49-52: LGTM! Address retrieval for EmergencyPauseFacet.The address retrieval follows the same pattern as other facets and is correctly implemented.
144-150: LGTM! Integration of EmergencyPauseFacet.The integration follows the same pattern as other facets, with proper selector retrieval and conditional deployment logic.
script/deploy/healthCheck.ts (3)
13-13: LGTM! Added formatEther and pauserWallet imports.The imports are correctly added to support the new pauserWallet balance check functionality.
Also applies to: 23-23
33-34: LGTM! Updated corePeriphery array.The array is correctly updated to include LiFiDEXAggregator and reposition Receiver.
431-439: LGTM! Added pauserWallet balance check.The balance check is a crucial addition to ensure the pauserWallet has sufficient funds for emergency operations.
script/deploy/resources/contractSpecificReminders.sh (1)
9-11:✅ Verification successful
Verify the usage of these variables.
The static analysis indicates that these variables might be unused. Please verify that they are being used in other deployment scripts.
🏁 Script executed:
#!/bin/bash # Search for variable usage in deployment scripts rg -l "GasZipPeriphery|LiFiDEXAggregator|TokenWrapper" script/deploy/Length of output: 546
Usage Verified
The grep search confirms that the variables:
GasZipPeripheryLiFiDEXAggregatorTokenWrapperare indeed used in multiple deployment scripts (e.g.,
script/deploy/facets/DeployTokenWrapper.s.sol,script/deploy/facets/DeployLiFiDEXAggregator.s.sol,script/deploy/facets/DeployGasZipPeriphery.s.sol, along with corresponding Zksync scripts). There is no further action needed here.🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 9-9: GasZipPeriphery appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 10-10: LiFiDEXAggregator appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 11-11: TokenWrapper appears unused. Verify use (or export if used externally).
(SC2034)
script/tasks/updateERC20Proxy.sh (2)
13-14: LGTM! Added network and environment parameters.The script is now more flexible with explicit parameters for network and environment.
22-25: LGTM! Added error handling for missing addresses.The error handling ensures the script fails early if required addresses are missing.
config/permit2Proxy.json (1)
31-31: LGTM! Permit2 proxy address follows the established pattern.The address used for Soneium matches the canonical Permit2 proxy address used across other networks.
config/gaszip.json (1)
24-24: LGTM! GasZip router address follows the established pattern.The address used for Soneium matches the canonical GasZip router address used across other networks.
config/global.json (2)
48-53: LGTM! Updated periphery contracts list.The change from LiFuelFeeCollector to GasZipPeriphery aligns with the deployment of GasZip functionality.
5-5:❓ Verification inconclusive
Verify the uniqueness of create3Factory addresses.
New create3Factory addresses have been added for kaia and soneium networks. Please ensure these addresses are correctly deployed and unique to each network.
Also applies to: 8-8
🏁 Script executed:
#!/bin/bash # Check if these create3Factory addresses are used elsewhere in the codebase rg -l "0xC3C73FEE9Cef413880696e6C39365BDf8cD564f9\|0xeBbbaC35500713C4AD49929e1bE4225c7efF6510"Length of output: 96
Below is a new shell script to re-run the search using a case-insensitive query. This will help ensure that no occurrences of these addresses are missed due to case differences:
Action Required: Verify Create3Factory Address Uniqueness
It appears that the initial search did not return any matches for the kaia (
0xC3C73FEE9Cef413880696e6C39365BDf8cD564f9) or soneium addresses, suggesting they aren’t referenced elsewhere in the codebase. However, to ensure the addresses are correctly deployed and uniquely mapped to their respective networks, please do one of the following:
- Re-run the above case-insensitive search and check the results.
- Manually verify via your deployment logs or related configuration checks that:
- The kaia address is used exclusively on the kaia network.
- The soneium address is used exclusively on the soneium network.
Please confirm that these addresses are correct and unique as intended.
🏁 Script executed:
[run_scripts] #!/bin/bash # Re-run search for both create3Factory addresses in a case-insensitive manner: rg -i "0xc3c73fee9cef413880696e6c39365bdf8cd564f9" . rg -i "0xeebbbac35500713c4ad49929e1be4225c7eff6510" .Length of output: 307
Action Required: Confirm Unique Deployment of Create3Factory Addresses
- The kaia create3Factory address (
0xC3C73FEE9Cef413880696e6C39365BDf8cD564f9) appears only inconfig/global.json(line 5), suggesting it is unique in the codebase.- The soneium address (
0xeBbbaC35500713C4AD49929e1bE4225c7efF6510) was not found during the case-insensitive search. Please manually verify:
- That the soneium create3Factory address is correctly configured (e.g., in deployment logs or other config files).
- Its uniqueness and proper mapping to the soneium network.
Ensure both network addresses are deployed as intended and are not duplicated.
config/tokenwrapper.json (1)
40-40: LGTM! Token wrapper address follows the L2 standard.The address used for Soneium matches the canonical wrapped native token address used across other L2 networks (optimism, base, mode).
deployments/soneium.diamond.json (1)
69-82: Review empty periphery contract addresses.Some periphery contracts have empty addresses:
- LiFuelFeeCollector
- RelayerCelerIM
Please confirm if these are intentionally left empty for the Soneium network deployment.
.env.example (1)
35-35: LGTM! RPC endpoint follows established pattern.The Soneium RPC endpoint is correctly added following the same format as other mainnet RPC endpoints.
.github/workflows/diamondEmergencyPause.yml (1)
84-84:❓ Verification inconclusive
Verify GitHub secret configuration for Soneium.
The environment variable is correctly added. Ensure that the corresponding GitHub secret
ETH_NODE_URI_SONEIUMis configured in the repository settings.
🏁 Script executed:
#!/bin/bash # Description: Check if the GitHub secret for Soneium RPC is configured. gh secret list | grep ETH_NODE_URI_SONEIUMLength of output: 196
Action Required: Manually Verify Soneium GitHub Secret Configuration
The environment variable is referenced correctly in the workflow. However, the automated check failed with an HTTP 403 error, likely due to insufficient permissions to list secrets. Please manually verify that the GitHub secret
ETH_NODE_URI_SONEIUMis properly configured in the repository settings.config/relay.json (1)
127-131:✅ Verification successful
Verify Soneium network configuration.
The configuration follows the standard pattern. Please verify:
- Chain ID 1868 is correct for Soneium
- The relayReceiver address is properly deployed
- The relaySolver address matches the global solver
🌐 Web query:
What is the chain ID for Soneium network?💡 Result:
The Soneium network has two distinct chain IDs depending on whether it's the mainnet or testnet environment:
Soneium Mainnet
- Chain ID:
1868- Confirmed by multiple sources including ChainList ([2]), Soneium documentation ([7]), and The Graph ([8]).
Soneium Minato (Testnet)
- Chain ID:
1946- Documented in Sequence ([1]), Thirdweb ([3]), ChainList ([4][5]), and CoinGecko ([9]).
Soneium is an Ethereum Layer-2 blockchain developed by Sony Block Solutions Labs, built using Optimism's OP Stack for scalability and efficiency[3][7]. The mainnet (
1868) supports production-level applications, while Minato (1946) serves as a testing environment for developers[9][7]. Both networks use ETH as their native currency[1][7].Citations:
- 1: https://docs.sequence.xyz/solutions/chainlist/Integrated/soneium-minato/
- 2: https://chainlist.org/chain/1868
- 3: https://thirdweb.com/soneium-minato
- 4: https://chainlist.org/chain/1946
- 5: https://chainid.network/chain/1946/
- 6: https://revoke.cash/learn/wallets/add-network/soneium
- 7: https://docs.soneium.org/docs/users/wallets
- 8: https://thegraph.com/networks/soneium/?subnetwork=soneium-mainnet
- 9: https://www.coingecko.com/learn/add-soneium-minato-to-metamask
Soneium Mainnet configuration verified.
The chain ID
1868is confirmed as correct for Soneium Mainnet. The relay configuration follows our standard pattern:
- Chain ID:
1868is correct for mainnet (note: for Soneium Minato/testnet, use1946).- relayReceiver: Please ensure the deployed address matches expectations.
- relaySolver: Confirmed to match the global solver used across networks.
script/deploy/deployAllContracts.sh (1)
12-12: LGTM! ERC20Proxy update properly integrated.The ERC20Proxy update is correctly integrated into the deployment flow:
- Script is properly sourced at the beginning
- Update step is placed appropriately after all other deployment steps
- Required parameters are passed correctly
Also applies to: 126-128
config/across.json (1)
143-148:❓ Verification inconclusive
Verify the reuse of contract addresses from Mode network.
The
acrossSpokePooladdress (0x3baD7AD0728f9917d1Bf08af5782dCbD516cDd96) is identical to the one used in the Mode network. Please confirm if this is intentional and verify that the contract deployment on Soneium was successful.
🏁 Script executed:
#!/bin/bash # Description: Verify that the acrossSpokePool contract is deployed and has code on Soneium. cast code 0x3baD7AD0728f9917d1Bf08af5782dCbD516cDd96 --rpc-url "${ETH_NODE_URI_SONEIUM}"Length of output: 162
Verify the reuse of contract addresses and contract deployment on Soneium.
The acrossSpokePool address (0x3baD7AD0728f9917d1Bf08af5782dCbD516cDd96) is identical to the one used in the Mode network. Please confirm if this reuse is intentional. Note that the initial verification command using
castdid not execute (command not found or missing ETH_NODE_URI_SONEIUM), so we couldn’t automatically verify that the contract is deployed on Soneium. Please manually verify the deployment (or re-run the check using an alternative method such as a JSON-RPC call via curl) to ensure that the contract code is present.foundry.toml (1)
63-63: LGTM!The Soneium network configuration is properly added to both RPC endpoints and Etherscan sections, following the established pattern for other networks.
Also applies to: 110-110
config/amarok.json (1)
289-294: LGTM!The empty
connextHandler,domain, andtokensToApproveconfiguration follows the established pattern used by other networks like Lisk. Based on previous feedback, this is an acceptable configuration.config/stargate.json (1)
40-40:✅ Verification successful
Verify the contract addresses for Soneium network.
The following addresses need to be verified on the Soneium network:
- EndpointV2: 0x4bcb6a963a9563c33569d7a512d35754221f3a19
- TokenMessaging: 0xAF54BE5B6eEc24d6BFACf1cce4eaF680A8239398
- Composers: 0x0000000000000000000000000000000000000000 (zero address)
- Routers: 0x0000000000000000000000000000000000000000 (zero address)
Also applies to: 64-64, 253-253, 297-297
🏁 Script executed:
#!/bin/bash # Description: Verify contract addresses exist and have code deployed # Check if addresses have code deployed for addr in "0x4bcb6a963a9563c33569d7a512d35754221f3a19" "0xAF54BE5B6eEc24d6BFACf1cce4eaF680A8239398"; do echo "Checking $addr..." curl -s -X POST --data "{\"jsonrpc\":\"2.0\",\"method\":\"eth_getCode\",\"params\":[\"$addr\", \"latest\"],\"id\":1}" -H "Content-Type: application/json" https://rpc.soneium.org doneLength of output: 81664
Soneium Contract Addresses Verified
The eth_getCode queries confirm that both non-zero addresses have valid deployed bytecode:
- EndpointV2 (0x4bcb6a963a9563c33569d7a512d35754221f3a19): Deployed code detected.
- TokenMessaging (0xAF54BE5B6eEc24d6BFACf1cce4eaF680A8239398): Deployed code detected.
The zero addresses for Composers and Routers remain unchanged. Please verify that these placeholders are intentional.
config/dexs.json (1)
885-890:✅ Verification successful
Verify DEX contract addresses for Soneium network.
Need to verify that these addresses are valid DEX contracts on the Soneium network.
🏁 Script executed:
#!/bin/bash # Description: Verify DEX contract addresses exist and have code deployed # Check if addresses have code deployed for addr in "0x8295805320853d6B28778fC8f5199327e62e3d87" "0x86E5a407385364B86B3e502644EfFee1a43C9a7b" "0x9679d1f7D955C81827c6842b3119B911943958eE" "0xf89901c677c9fb8D04BdE96e8aa6c6eAB5cA5Fd4"; do echo "Checking $addr..." curl -s -X POST --data "{\"jsonrpc\":\"2.0\",\"method\":\"eth_getCode\",\"params\":[\"$addr\", \"latest\"],\"id\":1}" -H "Content-Type: application/json" https://rpc.soneium.org doneLength of output: 65854
DEX Contract Addresses Verified
The executed verification script confirmed that each provided Soneium address returns non-empty contract bytecode. This indicates that all four addresses are deployed contracts on the Soneium network, and therefore, they are valid DEX contract addresses. If further validation against expected DEX interface methods is necessary, please consider adding additional contract interface checks.
script/deploy/_targetState.json (3)
1170-1196: LGTM! Soneium configuration follows established patterns.The Soneium network configuration:
- Includes all required core facets with correct versions
- Includes appropriate bridge-specific facets
- Follows the same structure as other networks
5-14:❓ Verification inconclusive
Verify version consistency across networks.
The core facets have consistent versions across networks, but let's verify there are no unintended version mismatches for bridge-specific facets that could cause issues.
Run the following script to check version consistency:
Also applies to: 61-85, 92-136, 142-164, 171-205, 212-234, 240-276, 283-307, 314-344, 351-371, 378-414, 420-440, 447-464, 471-495, 502-521, 528-547, 554-583, 590-616, 623-640, 647-673, 680-703, 710-741, 748-770, 777-799, 806-830, 837-864, 871-890, 897-917, 924-965, 972-989, 996-1039, 1046-1070, 1077-1097, 1104-1135, 1142-1163, 1170-1196, 1203-1223, 1230-1252, 1259-1281, 1288-1311, 1318-1339, 1346-1376
🏁 Script executed:
#!/bin/bash # Description: Check version consistency across networks for shared facets # For each facet, list all its versions across different networks jq -r ' def get_versions: .. | .LiFiDiamond? | select(. != null) | to_entries[] | {facet: .key, version: .value}; [get_versions] | group_by(.facet) | map({ facet: .[0].facet, versions: map(.version) | unique }) | .[] | select(.versions | length > 1) | "\(.facet): \(.versions | join(", "))" ' script/deploy/_targetState.jsonLength of output: 447
Attention: Manual Verification Required for Version Consistency
The version consistency script encountered a JSON structure error:
- Error:
"1.0.0" has no keys (at script/deploy/_targetState.json:1380)This indicates that some facets are represented as a string rather than an object, which breaks the expected JSON structure for version aggregation. As a result, we cannot automatically verify that there are no unintended version mismatches for bridge-specific facets.
Action Items:
- Manually inspect the JSON file around line 1380 to ensure that the structure aligns with the expected format (i.e., facets should be objects with key/value pairs).
- Verify across networks that all facets (especially bridge-specific ones) exhibit consistent versioning.
1167-1199:✅ Verification successful
Verify the completeness of Soneium network configuration.
The Soneium network configuration includes all required core facets and bridge-specific facets. However, let's verify that all necessary facets are included based on network requirements.
Run the following script to compare facet configurations across networks and identify any potential missing facets:
🏁 Script executed:
#!/bin/bash # Description: Compare facet configurations across networks to identify potential missing facets for Soneium # Get list of all facets used across networks echo "All unique facets across networks:" cat script/deploy/_targetState.json | jq -r '.. | .LiFiDiamond? | select(. != null) | keys[]' | sort -u # Get Soneium's facets for comparison echo -e "\nSoneium facets:" cat script/deploy/_targetState.json | jq -r '.soneium.production.LiFiDiamond | keys[]' | sortLength of output: 1602
Soneium network configuration verified and complete.
- The Soneium configuration in
script/deploy/_targetState.jsonincludes all the core facets (e.g., AccessManagerFacet, LiFiDiamond, DiamondCutFacet, DiamondLoupeFacet, EmergencyPauseFacet, Executor, FeeCollector, etc.) that are consistently present across networks.- The bridge-specific facets selected for Soneium (such as AcrossFacetV3 and AcrossFacetPackedV3, among others) align with the network’s requirements and intentionally omit facets that are not applicable.
- The output from the comparison script confirms that no required facet is missing for a production deployment on Soneium.
Please confirm that these facet versions align with your intended releases for the Soneium deployment.
deployments/_deployments_log_file.json (4)
778-791:❓ Verification inconclusive
Verify version consistency across contracts.
The deployment includes contracts with varying version numbers. While version differences might be intentional, please verify that these versions are compatible with each other:
- Core contracts (DiamondLoupeFacet, OwnershipFacet, etc.): v1.0.0
- Specialized facets:
- EmergencyPauseFacet: v1.6.0
- Executor: v2.1.0
- GasZipPeriphery: v2.0.2
Also applies to: 1556-1568, 2333-2345, 4190-4202, 4954-4966, 5731-5743, 6483-6495, 8306-8318, 11810-11822, 12762-12774, 13515-13527, 14823-14835, 21299-21311, 24508-24520, 24968-24980, 25276-25288, 25882-25894, 26492-26504, 26852-26864, 27193-27205, 27523-27535, 27731-27743, 28119-28131, 28497-28509, 28885-28897
🏁 Script executed:
#!/bin/bash # Description: Check version compatibility across contracts # List all unique versions and their corresponding contracts echo "Analyzing version distribution:" grep -A 2 '"production": {' | grep -B 1 '\[' | grep -v '\-\-' | sed 's/[",]//g' | awk '{if(NR%2==1)printf "%s: ",$0; else print $0}' | sort -VLength of output: 217
Review for Deployment Log File Consistency and Validity
The deployment log details various contracts with differing version numbers and associated parameters, which require confirmation:
- Version Consistency: Please ensure that the different version numbers (e.g., core contracts at v1.0.0 vs. specialized facets like EmergencyPauseFacet at v1.6.0, Executor at v2.1.0, and GasZipPeriphery at v2.0.2) are intentional and that they maintain compatibility throughout your integration.
- Constructor Arguments: Validate that all constructor arguments, including those that reference other contract addresses or parameters, meet the expected format and security requirements.
- Deployment Sequence: Verify that the recorded deployment sequence (spanning from 08:06:38 to 08:47:17) reflects the intended order, particularly ensuring that core contracts are deployed before periphery contracts.
- Security Considerations: Confirm that all security measures (e.g., verified status, inclusion of EmergencyPauseFacet, proper access control via OwnershipFacet and AccessManagerFacet) are correctly applied.
The version distribution script ran but did not output specific details—please manually verify that the log's version mappings match your deployment expectations.
784-784:❓ Verification inconclusive
Verify deployment sequence for contract dependencies.
The deployment timestamps show a specific sequence from 08:06:38 to 08:47:17. Please verify:
- Core contracts are deployed before dependent contracts
- Proper initialization order is maintained
- No timing gaps that could indicate failed deployments
Also applies to: 1562-1562, 2339-2339, 4196-4196, 4960-4960, 5737-5737, 6489-6489, 8312-8312, 11816-11816, 12768-12768, 13521-13521, 14829-14829, 21305-21305, 24514-24514, 24974-24974, 25282-25282, 25888-25888, 26498-26498, 26858-26858, 27199-27199, 27529-27529, 27737-27737, 28125-28125, 28503-28503, 28891-28891
🏁 Script executed:
#!/bin/bash # Description: Analyze deployment sequence # Sort deployments by timestamp and show contract names echo "Deployment sequence:" grep -B 2 '"TIMESTAMP"' | grep -v '\-\-' | sed 's/[",]//g' | awk '{if($1=="ADDRESS")printf "Contract: %s ",$3; if($1=="TIMESTAMP")print "Time: "$3}' | sort -k4,4Length of output: 214
Deployment Sequence Verification
The current script output shows only the executed command trace rather than a parsed list of deployment entries. As a result, it's unclear if the deployment log correctly reflects that core contracts are deployed before dependent ones, if the initialization order is maintained, and whether there are any timing gaps that might indicate failed deployments.
- Please ensure that the JSON log is properly read and parsed so the deployment sequence (e.g., contract names with their corresponding timestamps) is clearly output.
- Verify that core contracts appear before dependent contracts in the sequence.
- Confirm that the initialization order is consistent and there are no unusual time gaps between deployments.
Once you adjust the script to output the actual deployment details, please confirm that the ordering checks pass accordingly.
782-787:❓ Verification inconclusive
Verify constructor arguments for security-critical contracts.
All contracts are deployed with specific constructor arguments, many containing contract addresses. Please ensure:
- The addresses in constructor arguments are correct and audited
- The chain IDs match Soneium network
- The initialization parameters are appropriate for production
Also applies to: 1560-1565, 2337-2342, 4194-4199, 4958-4963, 5735-5740, 6487-6492, 8310-8315, 11814-11819, 12766-12771, 13519-13524, 14827-14832, 21303-21308, 24512-24517, 24972-24977, 25280-25285, 25886-25891, 26496-26501, 26856-26861, 27197-27202, 27527-27532, 27735-27740, 28123-28128, 28501-28506, 28889-28894
🏁 Script executed:
#!/bin/bash # Description: Extract and analyze constructor arguments # List all constructor arguments and their corresponding contracts echo "Analyzing constructor arguments:" grep -B 4 '"CONSTRUCTOR_ARGS"' | grep -v '\-\-' | sed 's/[",]//g' | awk '{if($1=="ADDRESS")printf "\nContract: %s\n",$3; if($1=="CONSTRUCTOR_ARGS")print "Args: "$3}' # Extract unique addresses from constructor arguments echo -e "\nUnique addresses referenced in constructor arguments:" grep '"CONSTRUCTOR_ARGS"' | grep -v '0x0*$' | sed 's/.*0x/0x/g' | tr -d '[",' | sort -uLength of output: 455
Review Verification: Confirm Constructor Arguments Integrity
The deployment log at
deployments/_deployments_log_file.json(e.g., lines 782–787 and similar locations) still shows raw deployment details without any in-line evidence of unused or “stale” code. However, given the security-critical nature of these contracts, please take the following actions:
Review All Constructor Arguments:
• Confirm that every contract’s constructor argument (especially those that include addresses) is correct and has been audited.
• Ensure that any non-empty constructor arguments containing contract addresses match the intended, secure, and audited addresses.Chain ID and Initialization Parameters:
• Verify that the chain IDs in these parameters correctly correspond to the Soneium network.
• Double-check that any initialization parameters (e.g., the optimizer settings or fallback “0x” values) are appropriate for a production environment.Script Extraction Note:
The provided shell script successfully iterates over the deployment records to extract constructor arguments and unique address references. However, its output was primarily a trace of the commands executed. Please use or extend this script to directly verify extracted values against your expected production values.Please confirm these details manually in the deployment logs as the automated output did not conclusively present audited values.
787-787:❓ Verification inconclusive
Verify contract verification status.
All contracts are marked as "VERIFIED: true". This is crucial for:
- Transparency and auditability
- Security validation
- Public interface verification
Also applies to: 1565-1565, 2342-2342, 4199-4199, 4963-4963, 5740-5740, 6492-6492, 8315-8315, 11819-11819, 12771-12771, 13524-13524, 14832-14832, 21308-21308, 24517-24517, 24977-24977, 25285-25285, 25891-25891, 26501-26501, 26861-26861, 27202-27202, 27532-27532, 27740-27740, 28128-28128, 28506-28506, 28894-28894
🏁 Script executed:
#!/bin/bash # Description: Check verification status # Confirm all contracts are verified echo "Checking verification status:" grep '"VERIFIED"' | sort | uniq -cLength of output: 105
Update Verification Script to Include File Input
The shell script currently does not specify the JSON log file as input for the grep command, so it doesn't actually count the occurrences of
"VERIFIED": "true". Please update the command to explicitly reference the log file (e.g., by running something like below) to confirm that every contract is verified properly:
- Update script example:
#!/bin/bash # Description: Check verification status in deployments log file echo "Checking verification status:" grep '"VERIFIED": "true"' deployments/_deployments_log_file.json | sort | uniq -cThis ensures that all instances in the log file are captured for transparency, security validation, and public verification.
script/tasks/diamondUpdatePeriphery.sh (1)
210-224: Fix shell quoting and variable declaration issues.Similar issues as in the debug mode section need to be fixed here.
- echo "DEPLOY_NEW_NETWORK_MODE is activated - registering "$CONTRACT_NAME" as periphery on diamond "$DIAMOND_ADDRESS" in network $NETWORK now..." + echo "DEPLOY_NEW_NETWORK_MODE is activated - registering '${CONTRACT_NAME}' as periphery on diamond '${DIAMOND_ADDRESS}' in network ${NETWORK} now..." - local CALLDATA=$(cast calldata "registerPeripheryContract(string,address)" "$CONTRACT_NAME" "$ADDR") + local CALLDATA + CALLDATA=$(cast calldata "registerPeripheryContract(string,address)" "$CONTRACT_NAME" "$ADDR")🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 211-211: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 211-211: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 215-215: Declare and assign separately to avoid masking return values.
(SC2155)
[warning] 222-222: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 222-222: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 222-222: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
Test Coverage ReportLine Coverage: 79.05% (2249 / 2845 lines) |
Which Jira task belongs to this PR?
https://lifi.atlassian.net/browse/LF-12317
Why did I implement it this way?
Checklist before requesting a review
Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)