-
Notifications
You must be signed in to change notification settings - Fork 34
Add Solana support to Across bridge for EVM -> Solana swaps #670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- Add Solana chain support to AcrossDeployment with ChainType enum - Implement cross-chain address encoding with AddressType enum for EVM/Solana - Add USDC_SOLANA_ASSET_ID constant and asset mapping support - Integrate SOL/USD Chainlink price feed for accurate relayer fee calculation - Create encode_v3_relay_data method with proper 32-byte address handling - Add comprehensive tests for Solana address conversion and cross-chain encoding - Support EVM -> Solana USDC swaps only (Solana -> EVM for future work) 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Changed Files
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @0xh3rman, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces comprehensive Solana support to the Across bridge, enabling cross-chain swaps from EVM-compatible chains to Solana. The primary focus is on facilitating USDC transfers from EVM chains to Solana, with future plans for Solana to EVM swaps. Key architectural changes include a new address type handling mechanism for both EVM and Solana addresses, a unified encoding method for V3 relay data to ensure proper 32-byte Solana address representation, and the integration of a SOL/USD Chainlink price feed for accurate relayer fee calculations.
Highlights
- Cross-chain Architecture: Implemented an AddressType enum to correctly handle both 20-byte EVM addresses (padded to 32 bytes) and native 32-byte Solana addresses.
- V3 Relay Data Encoding: Developed a custom encode_v3_relay_data method to ensure proper 32-byte address encoding within the V3RelayData structure for cross-chain compatibility.
- Asset and Price Integration: Added Solana USDC to supported assets and integrated a SOL/USD Chainlink price feed to enable accurate relayer fee calculations for Solana destinations.
- Enhanced is_supported_pair logic: Updated the is_supported_pair function to correctly identify and support EVM to Solana USDC swaps, while explicitly preventing Solana to EVM swaps for now.
- Comprehensive Testing: Included new tests covering Solana address conversion, AddressType enum behavior, and cross-chain V3 relay data encoding scenarios.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request adds comprehensive support for EVM to Solana swaps via the Across bridge. The changes are well-structured, introducing an AddressType
enum for handling cross-chain addresses and a custom encoding method for V3RelayData
. The integration of a SOL/USD price feed for fee calculation is also a key addition. The test coverage for the new functionality is good.
My review focuses on improving robustness by removing potential panics from unwrap()
calls, enhancing maintainability by addressing magic numbers, and fixing a critical issue with data decoding that could cause failures in the quote fetching process for Solana swaps. Overall, this is a solid implementation that will be even better with these refinements.
- Replace unsafe unwrap() calls with proper error handling in is_supported_pair - Use expect() with descriptive message in get_address_type_for_chain - Fix critical V3RelayData decode compatibility issue for Solana addresses - Add decode_v3_relay_data method to handle cross-chain address decoding - Replace try_into().unwrap() with proper error mapping in get_destination_chain_id - All tests passing with improved robustness and error handling 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Replace NotSupportedPair with InvalidAddress for Solana address decode errors - More semantically correct error type for address format issues - Maintains consistent error handling across address validation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Convert U256 from_amount directly to BigInt using from_bytes_le - Remove unsafe BigInt::from_str(request.value).unwrap() call - More efficient by avoiding redundant string parsing - Safer code with no potential panics from unwrap() 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Replaces hardcoded multicall result indices for ETH and SOL price feeds with dynamically calculated indices. This improves maintainability and correctness when determining the position of price feed results in the multicall response array.
Moved the AddressType enum and its related methods from provider.rs to a new address_type.rs module for better code organization and reuse. Updated imports and usage accordingly. This change improves maintainability and modularity of address handling for EVM and Solana addresses.
Updated chain type checks to use ChainType instead of direct Chain enum matching. Refactored gas estimation logic to handle Solana and Ethereum chains separately, returning a fixed gas limit for Solana. Improved address type resolution and destination chain ID handling for better cross-chain compatibility.
Introduces logic to fetch and use Solana prioritization fees for gas estimation in the Across swapper, including a new SolanaRpc variant and related client changes. Refactors gas price and fee calculation to support both EVM and Solana chains. Also updates import conventions and minor code style improvements.
Introduces unit tests for the Across swapper's message_for_multicall_handler method, covering ETH-to-Base and USDC Arbitrum-to-Optimism scenarios. These tests validate correct fee calculation, instruction encoding, and call structure for both native and ERC20 asset transfers.
Replaces the function token_bytes32_for_chain with token_bytes32_for_asset, updating all usages to accept an AssetId reference instead of separate chain and token_id parameters. This change improves clarity and correctness in token handling, especially for native assets and EVM chains, and updates related tests to match the new interface.
Introduces support for the Hyperliquid chain in Across deployment logic, asset constants, and swapper provider. Adds USDC asset definitions for Hyperliquid, enabling swaps and deployment configuration for this new chain.
Summary
Key Changes
Test Plan
🤖 Generated with Claude Code