Deploy CBridge to Gravity #856
Conversation
WalkthroughThe pull request introduces modifications to two JSON configuration files and a script. In Changes
Possibly related PRs
Suggested labels
Finishing Touches
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 (
|
Test Coverage ReportLine Coverage: 78.30% (2220 / 2835 lines) |
![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
🧹 Outside diff range and nitpick comments (1)
deployments/_deployments_log_file.json (1)
6706-6706: Verify production deployment requirementsBoth contracts are deployed to the production environment. Please ensure:
- All preliminary audits are completed
- The deployment addresses have been reviewed by the security team
- The constructor parameters have been validated for production use
Consider documenting the deployment process and security checks in a deployment checklist for future reference.
Also applies to: 15857-15857
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
config/cbridge.json(3 hunks)deployments/_deployments_log_file.json(2 hunks)deployments/gravity.json(1 hunks)
🔥 Files not summarized due to errors (1)
- deployments/_deployments_log_file.json: Error: Server error: no LLM provider could handle the message
🔇 Additional comments (7)
deployments/gravity.json (3)
25-26: Verify contract addresses and their deployment status
The newly added CBridge facet addresses need verification to ensure they are correctly deployed and consistent with the configuration.
#!/bin/bash
# Description: Verify contract addresses and their deployment status
# 1. Check if the addresses follow the checksum format
echo "Verifying checksum format of addresses..."
for addr in "0x325DA62543447A48c7b044C5642B87CeA88B0fd3" "0x49e93F6A99c590a8E70138D2710B9eDd88C077FF"; do
if ! echo "$addr" | grep -E '^0x[0-9a-fA-F]{40}$' > /dev/null; then
echo "Invalid address format: $addr"
exit 1
fi
done
# 2. Check consistency with cbridge.json configuration
echo "Checking consistency with cbridge.json..."
rg -l "0x9B36f165baB9ebe611d491180418d8De4b8f3a1f" config/
# 3. Look for any existing imports or references to these contracts
echo "Checking for contract references..."
rg -A 2 "CBridgeFacet|CBridgeFacetPacked"24-26: Ensure proper integration with EmergencyPauseFacet
The new CBridge facets are added after EmergencyPauseFacet. Verify that they respect the emergency pause functionality.
#!/bin/bash
# Description: Verify emergency pause integration
# Look for emergency pause modifier usage
echo "Checking emergency pause integration..."
ast-grep --pattern 'modifier whenNotPaused { $$$ }'
# Check for pause-related events
echo "Checking pause-related events..."
rg -A 2 "event Paused|event Unpaused"24-26: Verify security considerations for the new facets
The PR objectives emphasize validating external calls. We need to ensure these new facets have proper security controls.
Consider documenting:
- The access control model for these facets
- The validation mechanisms for external calls
- The preliminary audit status as required by PR objectives
config/cbridge.json (2)
148-150: LGTM! Clean formatting change.
The reformatting of the tokensToApprove array improves readability while maintaining the same content.
74-76: Verify the intentional reuse of cBridge address.
The cBridge address 0x9B36f165baB9ebe611d491180418d8De4b8f3a1f is also used in the Linea and Scroll networks. While address reuse across networks is a pattern seen elsewhere in this config, let's verify this is intentional.
✅ Verification successful
cBridge address is intentionally reused across gravity, linea, and scroll networks.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the cBridge address usage across networks
# Expected: Find all networks using this address to confirm the pattern
echo "Networks using cBridge address 0x9B36f165baB9ebe611d491180418d8De4b8f3a1f:"
rg -i "0x9B36f165baB9ebe611d491180418d8De4b8f3a1f" --context 2
Length of output: 884
deployments/_deployments_log_file.json (2)
15860-15864: Validate constructor arguments for second deployment
The constructor is initialized with two address parameters:
0x9b36f165bab9ebe611d491180418d8de4b8f3a1f0x11f1022ca6adef6400e5677528a80d49a069c00c
#!/bin/bash
# Description: Verify the roles and purposes of addresses used in constructor
# Search for references to the second address
rg "0x11f1022ca6adef6400e5677528a80d49a069c00c" .6709-6714: Validate constructor arguments for first deployment
The constructor is initialized with a single address parameter:
0x9b36f165bab9ebe611d491180418d8de4b8f3a1f
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
config/cbridge.json (1)
1-255: Overall configuration structure reviewThe JSON structure is consistent across all networks, following the pattern of:
- cBridge address
- Optional messageBus address
- tokensToApprove array
The configuration maintains a consistent structure across all networks, which is good for maintainability.
Consider adding:
- Chain IDs for each network for additional validation
- Version or last-updated timestamp for tracking
- Documentation for token addresses (e.g., what each token represents)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
config/cbridge.json(1 hunks)
🔇 Additional comments (5)
config/cbridge.json (5)
232-238: Verify Scroll network updates
The Scroll network configuration has been updated with new messageBus address and token approvals.
Let's check for any related configurations:
#!/bin/bash
# Search for Scroll-specific configurations
rg -g "*.{json,ts,js}" "scroll.*0x7d43AABC515C356145049227CeE54B608342c0ad"44-65: Verify BSC configuration changes
The BSC configuration has been updated with new cBridge and messageBus addresses, along with an expanded token list.
Let's verify the consistency of these addresses across the codebase:
#!/bin/bash
# Search for BSC bridge references
rg "0xdd90E5E87A2081Dcf0391920868eBc2FFB81a1aF" -A 2 -B 2
rg "0x95714818fdd7a5454f73da9c777b3ee6ebaeea6b" -A 2 -B 22-2: Note the automated nature of this configuration file
The comment indicates this file is generated by a backend script. Any manual changes made here might be overwritten.
Let's verify if there's a script that generates this file:
249-253: Verify new Gravity network configuration
A new network "gravity" has been added with cBridge address and one token to approve.
Let's verify this is consistent with deployment files:
Consider documenting the Gravity network specifics (e.g., chain ID, RPC endpoints) in the project's documentation.
✅ Verification successful
Gravity network configuration verified
The new Gravity network configuration is consistent with the codebase:
- The cBridge address
0x9B36f165baB9ebe611d491180418d8De4b8f3a1fis correctly configured and used consistently across multiple network configurations - The token
0xBB859E225ac8Fb6BE1C7e38D87b767e95Fef0EbDis properly configured as:- A token to approve in cBridge configuration
- The wrapped native token in the Gravity network configuration
- Referenced in tokenwrapper configuration
The network configuration is complete with proper chain ID (1625), native currency symbol (G), and infrastructure endpoints (RPC, explorer).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for Gravity network references
rg -l "gravity" --type json
# Check the cBridge address usage
rg "0x9B36f165baB9ebe611d491180418d8De4b8f3a1f" -A 2 -B 2
Length of output: 172
Script:
#!/bin/bash
# Let's try different approaches to verify the Gravity network configuration
# 1. Search for any JSON files containing "gravity" (case-insensitive)
echo "=== JSON files with gravity references ==="
fd -e json -x rg -i "gravity" {}
# 2. Search for the specific cBridge address
echo -e "\n=== cBridge address references ==="
rg -i "0x9B36f165baB9ebe611d491180418d8De4b8f3a1f"
# 3. Search for the token address to approve
echo -e "\n=== Token address references ==="
rg -i "0xBB859E225ac8Fb6BE1C7e38D87b767e95Fef0EbD"
# 4. Look for any network configuration files
echo -e "\n=== Network configuration files ==="
fd -e json -e yaml -e yml -x rg -l "network|chain|bridge" {}
Length of output: 91440
Script:
#!/bin/bash
# Let's verify the network configuration for Gravity
# 1. Check network configuration in networks.json
echo "=== Gravity Network Configuration ==="
fd -e json -x rg -A 10 -B 2 '"gravity"\s*:' {}
# 2. Check if there are any deployment files for Gravity
echo -e "\n=== Gravity Deployment Files ==="
fd -e json -x rg -l "gravity" {}
# 3. Check for any additional references to the cBridge contract
echo -e "\n=== Additional cBridge Contract References ==="
rg -i "0x9B36f165baB9ebe611d491180418d8De4b8f3a1f" -A 2 -B 2 --type json
# 4. Check for any additional references to the token
echo -e "\n=== Additional Token References ==="
rg -i "0xBB859E225ac8Fb6BE1C7e38D87b767e95Fef0EbD" -A 2 -B 2 --type json
Length of output: 21803
8-41: Verify token contract addresses on mainnet
The mainnet configuration has been expanded with numerous token addresses. These addresses are critical for security and functionality.
Let's verify these contract addresses:
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (3)
script/tasks/updateFacetConfig.sh (3)
15-25: Ensure 'gum' utility is available or provide an alternative input methodThe script uses
gum choosefor user selection of networks, which requires thegumutility to be installed. To enhance script robustness, consider adding a check forgumavailability or providing an alternative method for network selection ifgumis not installed.Apply this diff to check for
gumand provide a fallback:+if ! command -v gum &> /dev/null; then + echo "[error] 'gum' is required but not installed. Please install 'gum' or modify the script to use an alternative." + exit 1 +fi + echo "Select Networks" readarray -t NETWORKS < <(cat ./networks | gum choose --no-limit)
38-38: Consider parameterizing 'DIAMOND_CONTRACT_NAME' instead of hardcoding it
DIAMOND_CONTRACT_NAMEis hardcoded to"LiFiDiamond". To maintain flexibility and reusability of the script, consider accepting it as an argument or retaining the previous logic that allowed user selection or parameter input.If desired, modify the script to accept
DIAMOND_CONTRACT_NAMEas an argument:-DIAMOND_CONTRACT_NAME="LiFiDiamond" +# if no DIAMOND_CONTRACT_NAME was passed, set default +if [[ -z "$DIAMOND_CONTRACT_NAME" ]]; then + DIAMOND_CONTRACT_NAME="LiFiDiamond" +fi
41-41: Allow configuration of 'USE_MUTABLE_DIAMOND' instead of hardcodingThe variable
USE_MUTABLE_DIAMONDis set to"true"unconditionally. If the script needs to support both mutable and immutable diamonds, consider making this variable configurable through a parameter or environment variable.Example modification:
-USE_MUTABLE_DIAMOND="true" +# if not set, default to "true" +if [[ -z "$USE_MUTABLE_DIAMOND" ]]; then + USE_MUTABLE_DIAMOND="true" +fi
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
script/tasks/solidity/AddTokenApprovalsToCBridgeFacetPacked.s.sol(2 hunks)script/tasks/updateFacetConfig.sh(2 hunks)
🧰 Additional context used
🪛 Shellcheck
script/tasks/updateFacetConfig.sh
[warning] 64-64: This assignment is only seen by the forked process.
(SC2097)
[warning] 64-64: This expansion will not see the mentioned assignment.
(SC2098)
[warning] 68-68: This assignment is only seen by the forked process.
(SC2097)
[warning] 68-68: This expansion will not see the mentioned assignment.
(SC2098)
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
script/tasks/updateFacetConfig.sh (1)
19-21: Scope the IFS change to minimize side effectsThe IFS modification should be localized to prevent potential issues with other parts of the script that might rely on the default IFS value.
-IFS=$'\n' read -r -d '' -a NETWORKS < <(cat ./networks | gum choose --no-limit) +local OLD_IFS="$IFS" +IFS=$'\n' +read -r -d '' -a NETWORKS < <(cat ./networks | gum choose --no-limit) +IFS="$OLD_IFS"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
script/tasks/updateFacetConfig.sh(2 hunks)
🧰 Additional context used
🪛 Shellcheck
script/tasks/updateFacetConfig.sh
[warning] 71-71: This assignment is only seen by the forked process.
(SC2097)
[warning] 71-71: This expansion will not see the mentioned assignment.
(SC2098)
[warning] 75-75: This assignment is only seen by the forked process.
(SC2097)
[warning] 75-75: This expansion will not see the mentioned assignment.
(SC2098)
🔇 Additional comments (2)
script/tasks/updateFacetConfig.sh (2)
71-71: Fix variable assignments in command substitution
The variable assignments within the command substitution are only visible to the forked process and not to the forge command.
Also applies to: 75-75
🧰 Tools
🪛 Shellcheck
[warning] 71-71: This assignment is only seen by the forked process.
(SC2097)
[warning] 71-71: This expansion will not see the mentioned assignment.
(SC2098)
45-48: Verify the intentional hardcoding of diamond contract settings
The script now hardcodes DIAMOND_CONTRACT_NAME to "LiFiDiamond" and USE_MUTABLE_DIAMOND to "true". While this simplifies the script, it reduces flexibility. Please confirm if this is intentional for the CBridge deployment.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
config/cbridge.json(3 hunks)deployments/_deployments_log_file.json(2 hunks)deployments/gravity.json(1 hunks)script/tasks/solidity/AddTokenApprovalsToCBridgeFacetPacked.s.sol(2 hunks)
🔥 Files not summarized due to errors (1)
- deployments/_deployments_log_file.json: Error: Server error: no LLM provider could handle the message
🚧 Files skipped from review as they are similar to previous changes (1)
- deployments/gravity.json
🧰 Additional context used
🪛 Biome (1.9.4)
config/cbridge.json
[error] 221-221: The key base was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
[error] 232-232: The key scroll was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
[error] 240-240: The key blast was already declared.
This where a duplicated key was declared again.
If a key is defined multiple times, only the last definition takes effect. Previous definitions are ignored.
(lint/suspicious/noDuplicateObjectKeys)
🔇 Additional comments (6)
deployments/_deployments_log_file.json (2)
6938-6951: Verify version compatibility with existing integrations.
The deployment of CBridgeFacet v1.0.0 looks correct with proper verification and optimization. The CBridge address is correctly passed as the constructor argument.
Let's verify the version compatibility:
✅ Verification successful
Based on the search results, I can see that CBridgeFacet v1.0.0 is consistently used across multiple chains in the target state configuration file (_targetState.json). The deployment to Gravity chain follows this same version pattern, indicating compatibility with the broader deployment strategy.
Version 1.0.0 deployment is consistent with target state configuration
The CBridgeFacet v1.0.0 deployment to Gravity chain aligns with the standard version used across other chains, maintaining version consistency in the ecosystem.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any version-specific dependencies or integrations
rg -B 5 -A 5 '"1\.0\.0"' . | grep -v "_deployments_log"
# Look for any migration scripts or version upgrade handlers
fd -e sol -e js | xargs rg -l "1\.0\.0"
Length of output: 102528
16277-16290: Please clarify the constructor arguments and version jump.
A few points need clarification:
- What is the purpose of the second constructor argument (0x11f1022ca6adef6400e5677528a80d49a069c00c)?
- Why was there a version jump from 1.0.0 to 1.0.3? Are there any breaking changes?
The deployment itself looks correct with proper verification and optimization settings.
Let's check for any related changes or documentation:
✅ Verification successful
Constructor arguments and version update verified
The deployment is correct and well-documented:
- The first constructor argument (0x9b36f165bab9ebe611d491180418d8de4b8f3a1f) is the cBridge contract address for the Gravity chain, as confirmed in the config/cbridge.json file.
- The second argument (0x11f1022ca6adef6400e5677528a80d49a069c00c) is the owner address passed to the TransferrableOwnership base contract.
Regarding the version jump: The version number in the deployment log appears to be a deployment version tracking mechanism rather than a contract version, as there's no explicit VERSION constant in the contract code. This is likely used for deployment tracking and doesn't indicate breaking changes in the contract itself.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Look for documentation about version 1.0.3
fd -e md -e sol | xargs rg -l "1\.0\.3"
# Check for any references to the second constructor argument
rg "0x11f1022ca6adef6400e5677528a80d49a069c00c" .
# Look for any upgrade or migration scripts
fd -e sol | xargs rg -l "CBridgeFacetPacked"
Length of output: 592
Script:
#!/bin/bash
# Check the constructor arguments in the deployment script
ast-grep --pattern 'constructor($$$) {
$$$
}' src/Facets/CBridgeFacetPacked.sol
# Look for version changes in git history
git log -n 5 --oneline src/Facets/CBridgeFacetPacked.sol
# Check the deployment script for version info
cat script/deploy/facets/DeployCBridgeFacetPacked.s.sol
# Look for upgrade documentation
cat script/deploy/facets/UpdateCBridgeFacetPacked.s.sol
Length of output: 2321
Script:
#!/bin/bash
# Check the config file for cBridge address
cat config/cbridge.json
# Look for version changes in the contract
rg -A 2 "VERSION =" src/Facets/CBridgeFacetPacked.sol
# Check for any breaking changes or major updates
rg -B 2 -A 5 "constructor" src/Facets/CBridgeFacetPacked.sol
Length of output: 11936
script/tasks/solidity/AddTokenApprovalsToCBridgeFacetPacked.s.sol (3)
44-49: LGTM! Efficient allowance checking
The addition of allowance checking before adding tokens to the approval list is a good optimization that prevents unnecessary approvals and saves gas.
51-53: LGTM! Efficient early return
The early return when no tokens need approval is a good optimization that prevents unnecessary contract calls.
14-15:
Consider resetting the internal state variable
Since tokensToApprove is an internal state variable, it retains its values between function calls. To prevent unintended accumulation of tokens from previous runs, consider resetting it at the beginning of the run() function.
function run() public returns (address[] memory facets) {
+ delete tokensToApprove;
address facet = json.readAddress(".CBridgeFacetPacked");Likely invalid or redundant comment.
config/cbridge.json (1)
249-254: LGTM! Gravity network configuration
The addition of the Gravity network configuration looks correct with appropriate cBridge address and token configuration.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
deployments/gravity.diamond.json (1)
Line range hint
1-92: Verify configuration consistencyThe deployment configuration appears structurally sound, but please ensure:
- The facet ordering follows the upgrade pattern
- No critical periphery components are missing
Consider documenting the following in the repository:
- Facet deployment order requirements
- Required vs optional periphery components
- Version compatibility matrix
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
deployments/gravity.diamond.json(2 hunks)deployments/gravity.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- deployments/gravity.json
🔇 Additional comments (2)
deployments/gravity.diamond.json (2)
65-66: Verify audit status of CBridge facets
As per the PR checklist, new contracts must undergo at least one preliminary audit. Please confirm:
- Have both CBridgeFacet and CBridgeFacetPacked been audited?
- Why are we deploying both packed (v1.0.3) and unpacked (v1.0.0) versions?
Also applies to: 69-70
86-86: Verify the restored Receiver address
The Receiver address has been restored to 0x2DeB3bFa2b19024A0c1Ba299b6b79276f1F77b14. Please confirm:
- Is this the correct address for the current network?
- Has this address been previously audited and verified?
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
deployments/_deployments_log_file.json (1)
6947-6947: Consider using salts for deterministic deploymentsBoth contracts are deployed without salts. Using salts for deterministic deployments ensures reproducible addresses across different environments and networks.
Consider adding unique salts for each contract deployment to enable deterministic deployment addresses.
Also applies to: 6948-6948, 6286-6286, 6287-6287
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
config/cbridge.json(3 hunks)deployments/_deployments_log_file.json(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: run-unit-tests
- GitHub Check: enforce-min-test-coverage
- GitHub Check: generate-tag
- GitHub Check: analyze
🔇 Additional comments (6)
deployments/_deployments_log_file.json (2)
6946-6946: Address configuration looks correctThe CBridge address (0x9b36f165bab9ebe611d491180418d8de4b8f3a1f) passed to both facets' constructors is consistent. This is the expected configuration where:
- The CBridge contract is the main contract
- CBridgeFacet and CBridgeFacetPacked are facets that interact with the main contract
Also applies to: 16285-16285
16285-16285: Verify the additional constructor argumentCBridgeFacetPacked includes an additional constructor argument:
0x11f1022ca6adef6400e5677528a80d49a069c00c. Please verify its purpose and ensure it's the correct address.Let's check the purpose of this address:
✅ Verification successful
Constructor argument verified as correct deployer wallet
The address
0x11f1022ca6adef6400e5677528a80d49a069c00cis the official deployer wallet address for the project, as confirmed in the global configuration. Its usage as a constructor argument is consistent with other deployments in the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for references to the additional constructor argument echo "Searching for address references..." rg -A 5 "0x11f1022ca6adef6400e5677528a80d49a069c00c" . echo "Checking contract verification..." # Use etherscan-like APIs to verify the contract at this address curl -s "https://api.gnosisscan.io/api/v1/contract/0x11f1022ca6adef6400e5677528a80d49a069c00c"Length of output: 1551
Script:
#!/bin/bash # Find CBridgeFacetPacked contract and its constructor echo "Searching for CBridgeFacetPacked contract..." ast-grep --pattern 'contract CBridgeFacetPacked { $$$ }' echo -e "\nSearching for constructor..." ast-grep --pattern 'constructor($$$) { $$$ }' echo -e "\nSearching for deployment configurations..." fd -e json -e yaml -e yml . | xargs rg -l "CBridgeFacetPacked" echo -e "\nSearching for partial address matches (case insensitive)..." rg -i "11f1022ca6adef6400e5677528a80d49a069c00c"Length of output: 25129
config/cbridge.json (4)
Line range hint
227-254: Remove duplicate network configurationsThere are duplicate configurations for the following networks:
- base (lines 227-234 and 254-261)
- scroll (lines 235-242 and 262-269)
- blast (lines 243-251 and 270-282)
This could lead to confusion and potential issues during deployment. The duplicate sections should be removed, keeping only one configuration per network.
- "base": { - "cBridge": "0x7d43AABC515C356145049227CeE54B608342c0ad", - "tokensToApprove": [ - "0x54BC229d1cB15F8B6415EfEab4290a40bc8b7D84", - "0xba7D47f471ADD16875e765edEe0858C3413A56Fd", - "0x38815A4455921667d673B4cb3d48F0383eE93400", - "0xf34e0cff046e154CAfCae502C7541b9E5FD8C249", - "0xc142171B138DB17a1B7Cb999C44526094a4dae05" - ] - }, - "scroll": { - "cBridge": "0x9B36f165baB9ebe611d491180418d8De4b8f3a1f", - "messageBus": "0x7d43AABC515C356145049227CeE54B608342c0ad", - "tokensToApprove": [ - "0x78Ab77F7D590FB101AA18affc238cbfEA31EAd5b", - "0x5300000000000000000000000000000000000004" - ] - }, - "blast": { - "cBridge": "0x841ce48F9446C8E281D3F1444cB859b4A6D0738C", - "messageBus": "0xFCE49bAa70E415bF410c18D89D321f39BF2637f4", - "tokensToApprove": [ - "0x9f04B6CEfd5BCd67d76aB708F17553Ce40188e6A", - "0xcBf7B47E9da345812e3Bd732E3EE369a7203B5ae", - "0x4300000000000000000000000000000000000004" - ] - }
221-226: Verify the Gravity network configuration.Please ensure that the cBridge address and token address have been audited for the Gravity deployment.
Line range hint
24-38: Verify the newly added mainnet token addresses.Please ensure that these token addresses are correct and have been audited for the mainnet deployment.
215-218: Verify the newly added Linea token addresses.Please ensure that these token addresses are correct and have been audited for the Linea deployment.
✅ Verification successful
Token addresses verified through cross-bridge configurations
The Linea token addresses are verified through their consistent usage across multiple bridge configurations (cBridge, Hop, Across). Notably, 0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f is confirmed as the ETH token in Hop protocol, and other tokens show established cross-chain presence.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify token contracts on Linea # Note: Using Lineascan API to verify contract existence and basic properties for addr in \ "0xcf0f95E34F25d1BB3D9cad3Cbb2EB40dAb7c3841" \ "0x0A3BB08b3a15A19b4De82F8AcFc862606FB69A2D" \ "0x60D01EC2D5E98Ac51C8B4cF84DfCCE98D527c747" \ "0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f" do echo "Checking token: $addr" curl -s "https://api.lineascan.build/api?module=contract&action=getabi&address=$addr" doneLength of output: 3015
Script:
#!/bin/bash # Description: Verify token contracts on Linea with rate limiting # Using different endpoints and adding delays for addr in \ "0xcf0f95E34F25d1BB3D9cad3Cbb2EB40dAb7c3841" \ "0x0A3BB08b3a15A19b4De82F8AcFc862606FB69A2D" \ "0x60D01EC2D5E98Ac51C8B4cF84DfCCE98D527c747" \ "0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f" do echo "Checking token: $addr" # Get contract source code curl -s "https://api.lineascan.build/api?module=contract&action=getsourcecode&address=$addr" sleep 2 # Get basic token info curl -s "https://api.lineascan.build/api?module=token&action=tokeninfo&contractaddress=$addr" sleep 2 doneLength of output: 3090
Script:
#!/bin/bash # Search for token addresses and Linea token documentation echo "Searching for token addresses in the codebase..." rg -l "0xcf0f95E34F25d1BB3D9cad3Cbb2EB40dAb7c3841|0x0A3BB08b3a15A19b4De82F8AcFc862606FB69A2D|0x60D01EC2D5E98Ac51C8B4cF84DfCCE98D527c747|0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f" -g '!{package-lock.json,yarn.lock}' echo -e "\nSearching for Linea token documentation..." rg -i -C2 "linea.*token" -g '!{package-lock.json,yarn.lock}' echo -e "\nSearching for token configuration files..." fd -e json -e yaml -e yml | xargs rg -l "linea.*token"Length of output: 701
Script:
#!/bin/bash # Extract context from configuration files echo "=== Checking cbridge.json ===" rg -C5 "0xcf0f95E34F25d1BB3D9cad3Cbb2EB40dAb7c3841|0x0A3BB08b3a15A19b4De82F8AcFc862606FB69A2D|0x60D01EC2D5E98Ac51C8B4cF84DfCCE98D527c747|0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f" config/cbridge.json echo -e "\n=== Checking hop.json ===" rg -C5 "0xcf0f95E34F25d1BB3D9cad3Cbb2EB40dAb7c3841|0x0A3BB08b3a15A19b4De82F8AcFc862606FB69A2D|0x60D01EC2D5E98Ac51C8B4cF84DfCCE98D527c747|0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f" config/hop.json echo -e "\n=== Checking across.json ===" rg -C5 "0xcf0f95E34F25d1BB3D9cad3Cbb2EB40dAb7c3841|0x0A3BB08b3a15A19b4De82F8AcFc862606FB69A2D|0x60D01EC2D5E98Ac51C8B4cF84DfCCE98D527c747|0xe5D7C2a44FfDDf6b295A15c148167daaAf5Cf34f" config/across.jsonLength of output: 4535
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!!!)