feat: sonic chain #1545
feat: sonic chain #1545
Conversation
WalkthroughThis pull request introduces comprehensive support for the new "sonic" network across multiple smart contract artifacts and configurations. The changes primarily involve adding deployment entries for various contract versions in the artifacts directory, including BatchConversionPayments, ChainlinkConversionPath, ERC20FeeProxy, ERC20Proxy, Erc20ConversionProxy, EthConversionProxy, EthereumFeeProxy, EthereumProxy, and RequestDeployer. Additionally, the Hardhat configuration file is updated to include network-specific settings for sonic, such as chain ID, API keys, and deployment parameters. Changes
Possibly related PRs
Suggested reviewers
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 (
|
github-actions
bot
requested review from
aimensahnoun,
MantisClone,
sstefdev and
yomarion
![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)
packages/smart-contracts/src/lib/artifacts/ERC20FeeProxy/index.ts (1)
Line range hint
90-169: Consider documenting the deployment strategy and version compatibility.The deployment pattern shows:
- Sequential block numbers (3973538-3974151) indicating coordinated deployment
- Consistent address reuse patterns across networks
- Multiple version compatibility scenarios
Recommendations:
- Document the rationale for address reuse across networks
- Maintain a version compatibility matrix
- Consider adding deployment verification tests
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
packages/smart-contracts/hardhat.config.ts(4 hunks)packages/smart-contracts/src/lib/artifacts/BatchConversionPayments/index.ts(1 hunks)packages/smart-contracts/src/lib/artifacts/ChainlinkConversionPath/index.ts(2 hunks)packages/smart-contracts/src/lib/artifacts/ERC20FeeProxy/index.ts(1 hunks)packages/smart-contracts/src/lib/artifacts/ERC20Proxy/index.ts(1 hunks)packages/smart-contracts/src/lib/artifacts/Erc20ConversionProxy/index.ts(2 hunks)packages/smart-contracts/src/lib/artifacts/EthConversionProxy/index.ts(2 hunks)packages/smart-contracts/src/lib/artifacts/EthereumFeeProxy/index.ts(1 hunks)packages/smart-contracts/src/lib/artifacts/EthereumProxy/index.ts(1 hunks)packages/smart-contracts/src/lib/artifacts/RequestDeployer/index.ts(1 hunks)
👮 Files not reviewed due to content moderation or server errors (1)
- packages/smart-contracts/src/lib/artifacts/Erc20ConversionProxy/index.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build-and-test
🔇 Additional comments (8)
packages/smart-contracts/src/lib/artifacts/ERC20Proxy/index.ts (1)
44-47: LGTM! Verify contract verification status.The Sonic chain deployment entry is properly structured. However, since this is a new chain deployment, ensure the contract is verified on the Sonic chain explorer.
packages/smart-contracts/src/lib/artifacts/RequestDeployer/index.ts (1)
92-95: LGTM! Deployment sequence is correct.The RequestDeployer contract was deployed first (block 3970964) before other contracts, which is the correct deployment sequence. The address consistency across networks follows the established pattern.
packages/smart-contracts/src/lib/artifacts/BatchConversionPayments/index.ts (1)
89-92: Verify proxy dependencies for Sonic chain.Other networks have caution comments when certain proxies are missing. Please verify that all required proxies (ETHConversion, ERC20Conversion, chainlinkConversionPath) are available on Sonic chain.
✅ Verification successful
All required proxies are deployed on Sonic chain
All necessary proxy contracts (ETHConversion, ERC20Conversion, and ChainlinkConversionPath) are properly deployed on the Sonic chain. No caution comment is needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for the existence of required proxy contracts on Sonic chain echo "Checking for required proxy contracts on Sonic chain..." # Search for proxy deployment entries rg -l "sonic.*address.*creationBlockNumber" | while read -r file; do echo "=== $file ===" rg "sonic.*address.*creationBlockNumber" "$file" doneLength of output: 181
Script:
#!/bin/bash # Search for Sonic chain deployments in specific contract artifacts echo "=== Checking ETHConversion ===" rg -A 5 "sonic" "packages/smart-contracts/src/lib/artifacts/ETHConversion/index.ts" || true echo "=== Checking ERC20Conversion ===" rg -A 5 "sonic" "packages/smart-contracts/src/lib/artifacts/ERC20Conversion/index.ts" || true echo "=== Checking ChainlinkConversionPath ===" rg -A 5 "sonic" "packages/smart-contracts/src/lib/artifacts/ChainlinkConversionPath/index.ts" || true # Also search broadly in artifacts directory for any Sonic mentions echo "=== All Sonic deployments in artifacts ===" fd . "packages/smart-contracts/src/lib/artifacts" -t f -x rg -l "sonic" {} \;Length of output: 1825
Script:
#!/bin/bash # Check deployment data in the correct proxy files echo "=== Checking EthConversionProxy ===" rg -A 5 "sonic" "packages/smart-contracts/src/lib/artifacts/EthConversionProxy/index.ts" echo "=== Checking Erc20ConversionProxy ===" rg -A 5 "sonic" "packages/smart-contracts/src/lib/artifacts/Erc20ConversionProxy/index.ts"Length of output: 943
packages/smart-contracts/src/lib/artifacts/EthConversionProxy/index.ts (1)
111-114: LGTM! Version compatibility is maintained.The deployment entries for both versions 0.2.0 and 0.2.1 are consistent with the pattern used in other networks. The same address is correctly used as only administrative functions differ between versions.
Also applies to: 133-136
packages/smart-contracts/src/lib/artifacts/EthereumProxy/index.ts (1)
207-210: LGTM! Consistent with CREATE2 deployment pattern.The sonic network entry follows the established pattern of deterministic deployment using CREATE2, reusing the same contract address across multiple networks. This is a good practice as it ensures contract address consistency.
Let's verify this deployment pattern across other contract artifacts:
✅ Verification successful
Verified: CREATE2 deployment pattern confirmed
The sonic network deployment (0x171Ee0881407d4c0C11eA1a2FB7D5b4cdED71e6e) shares the same deterministic address with several other networks (goerli, optimism, moonbeam, mantle, core, sepolia), confirming the use of CREATE2 for consistent cross-chain deployments.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify CREATE2 deployment pattern for sonic network # Expected: Same address pattern across multiple contracts # Search for sonic network entries in all contract artifacts rg -A 2 'sonic: \{' packages/smart-contracts/src/lib/artifacts/Length of output: 4106
Script:
#!/bin/bash # Description: Check if contract addresses are consistent across networks # Expected: Same addresses for each contract across different networks # Search for network entries in all contract artifacts rg -B 1 -A 2 'address:.*' packages/smart-contracts/src/lib/artifacts/EthereumProxy/index.tsLength of output: 6455
packages/smart-contracts/hardhat.config.ts (1)
207-211: LGTM! Verify API endpoints accessibility.The sonic network configuration is comprehensive and follows the established patterns across all sections (networks, etherscan, and xdeploy).
Let's verify the API endpoints are accessible:
Also applies to: 251-251, 294-301, 334-334
✅ Verification successful
✓ API endpoints are accessible and properly configured
Both the API endpoint (api.sonicscan.org) and browser interface (sonicscan.org) are operational and return successful responses with appropriate security configurations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify sonic network API endpoints # Expected: HTTP 200 OK response # Test the API endpoint curl -I https://api.sonicscan.org/api # Test the browser endpoint curl -I https://sonicscan.org/Length of output: 2680
packages/smart-contracts/src/lib/artifacts/EthereumFeeProxy/index.ts (1)
153-156: Review version mismatch between ABI and deployment.Version 0.2.0 is using ABI_0_1_0. While this might be intentional, please verify that:
- The 0.1.0 ABI is compatible with 0.2.0 functionality
- No new features from 0.2.0 are missing from the 0.1.0 ABI
✅ Verification successful
Version mismatch is intentional and safe
The contract implementation shows that v0.2.0 maintains the same interface as v0.1.0 with no breaking changes or new features. Using ABI_0_1_0 for the Sonic chain deployment is correct and won't cause any compatibility issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for version compatibility and missing features # Search for version-specific features or functions ast-grep --pattern 'contract EthereumFeeProxy { $$$ function $FUNC($$$) { $$$ } $$$ }'Length of output: 100
Script:
#!/bin/bash # Find contract source files fd -e sol "EthereumFeeProxy" # Find ABI definitions and version references rg -l "ABI_0_1_0|ABI_0_2_0" --type ts # Check deployment configurations rg -A 5 "sonic.*address.*0x4989F941D62bEEb3548Bf55d0D5291Ec335429f0"Length of output: 1679
Script:
#!/bin/bash # Check contract content cat packages/smart-contracts/src/contracts/EthereumFeeProxy.sol # Check ABI definitions in artifacts rg -A 10 "ABI_0_1_0|ABI_0_2_0" packages/smart-contracts/src/lib/artifacts/EthereumFeeProxy/index.tsLength of output: 3409
packages/smart-contracts/src/lib/artifacts/ERC20FeeProxy/index.ts (1)
166-169: LGTM! Deployment follows established patterns.The Sonic chain deployment:
- Uses a consistent address pattern seen in other networks (goerli, optimism, moonbeam)
- Has a creation block number (3974138) that aligns chronologically with other contract deployments in this PR
packages/smart-contracts/src/lib/artifacts/ChainlinkConversionPath/index.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/payment-detection/src/eth/multichainExplorerApiProvider.ts (1)
Line range hint
37-84: Consider refactoring thegetBaseUrlmethod for better maintainability.The method is growing large with the addition of new networks. Consider refactoring to use a map or configuration object:
- // eslint-disable-next-line complexity - getBaseUrl(): string { - switch (this.network.name) { - case 'sonic': - return 'https://api.sonicscan.org/api'; - // ... other cases - } - } + private static readonly BASE_URLS: Record<string, string> = { + sonic: 'https://api.sonicscan.org/api', + base: 'https://api.basescan.org/api', + // ... other mappings + }; + + getBaseUrl(): string { + return MultichainExplorerApiProvider.BASE_URLS[this.network.name] || super.getBaseUrl(); + }packages/utils/src/providers.ts (1)
56-56: Consider making the RPC URL configurable via environment variable.While the hardcoded RPC URL works, following the pattern used for other networks, consider documenting that it can be overridden using the environment variable
RN_WEB3_RPC_URL_SONICfor production deployments.Add a comment above the
networkRpcsobject:/** * Default RPC URLs for networks. Can be overridden using RN_WEB3_RPC_URL_[NETWORK] environment variables. * Example: RN_WEB3_RPC_URL_SONIC for the Sonic network. */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
packages/currency/src/chains/evm/data/sonic.ts(1 hunks)packages/currency/src/chains/evm/index.ts(2 hunks)packages/currency/src/conversion-aggregators.ts(1 hunks)packages/currency/src/native.ts(1 hunks)packages/payment-detection/src/eth/multichainExplorerApiProvider.ts(3 hunks)packages/types/src/currency-types.ts(1 hunks)packages/utils/src/providers.ts(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- packages/currency/src/chains/evm/data/sonic.ts
- packages/currency/src/conversion-aggregators.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build-and-test
🔇 Additional comments (5)
packages/currency/src/chains/evm/index.ts (1)
31-31: LGTM! The Sonic chain integration follows the established pattern.The changes correctly integrate the Sonic chain definition into the EVM chains configuration.
Also applies to: 66-66
packages/payment-detection/src/eth/multichainExplorerApiProvider.ts (1)
20-20: LGTM! The Sonic network configuration is correctly defined.The chain ID and network name are properly configured.
packages/currency/src/native.ts (1)
175-180: LGTM! The Sonic native currency is properly configured.The native currency configuration follows the standard pattern with correct decimal precision and network reference.
Let's verify that the symbol is unique across all native currencies:
✅ Verification successful
Symbol '$S' is unique across all native currencies
The native currency configuration for Sonic network with symbol '$S' is unique and doesn't conflict with any other native currency symbols in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for duplicate native currency symbols rg -B 1 -A 1 "symbol: '\$S'" packages/currency/src/native.tsLength of output: 67
Script:
#!/bin/bash # Search for native currency configurations using ripgrep rg -A 3 "symbol: .*," packages/currency/src/native.ts # Alternative search using ast-grep to find object literals with symbol property ast-grep --pattern '{ symbol: $_, $$$ }'Length of output: 20773
packages/types/src/currency-types.ts (1)
29-29: LGTM! The Sonic chain type is properly defined.The addition to
EvmChainNametype maintains alphabetical order and consistency.packages/utils/src/providers.ts (1)
56-56: Verify the RPC endpoint's reliability and rate limits.Since this RPC will be used for contract interactions mentioned in the PR (RequestDeployer, ERC20Proxy, etc.), ensure that:
- The RPC endpoint is stable and production-ready
- It has sufficient rate limits for your use case
- It supports all required JSON-RPC methods needed by the contracts
Description of the changes
Add support for the Sonic chain.
Contracts deployed:
All contracts have been setup ✅
All contracts have been verified ✅
Safe currently not supported on Sonic, admin isn't a multisig ❌
For reference, deployment & setup txs can be found here
Summary by CodeRabbit