Solana Migration Guide

Across is expanding support to Solana, enabling seamless USDC bridging between Ethereum Mainnet, other supported chains and Solana. The migration is scheduled to go live soon. All integrators and relayers are encouraged to complete the necessary updates before the migration happens to prevent disruptions.


For Solana routes, check out this utility script demonstrating how to call deposit()with the integratorID for seamless transaction execution.

Building and Executing Transactions

Developers are requested to build transactions by fetching details from the /suggested-fees API, adding integratorID and calling the deposit() function in the SVM SpokePool contract to execute deposit transactions. We will let you know as soon as Solana routes are available in the /suggested-fees API.

When calling the /suggested-fees API, you must provide the recipient parameter in Solana Pubkey format (base-58 encoded string).

If the recipient is missing or not a valid Solana public key, the API will return an error response with status code 400

There are no changes in the /suggested-fees API's response body. However please note that you will be able to see Solana addresses (in Pubkey format) in fields like recipient, inputToken, outputToken, spokePoolAddress, exclusiveRelayer and destinationSpokePoolAddress .

Solana is not currently supported in the Across App-SDK. We’re actively working on expanding support and improving the developer experience for Solana. Stay tuned, we’ll share updates as soon as it becomes available.

Restrictions with Embedded Crosschain Actions (Across+) on Solana

When integrating Solana for crosschain deposits, it's crucial to know that Solana transactions have a maximum size limit of 1232 bytes. This can affect your deposit transactions in the following ways:

  • Deposits from EVM Chains to Solana: Due to Solana's inherent message size limitations, there is a potential for deposit transactions failing when bridging (with an attached message) from EVM chains to Solana.

  • Deposits from Solana to EVM Chains: While the Solana side of the deposit may experience a revert due to message size limitations during the initial deposit, if the transaction successfully completes on Solana, the EVM side is designed to process the message without issues. This means that as long as the deposit transaction is successfully broadcast and confirmed on Solana, the subsequent fill on the EVM destination chain should proceed as expected.

If you need any help adding the integratorID, please reach out to us here.


For Relayers

We encourage relayers to update their codebases and follow the below guidelines as soon as possible and support bridging to and from Solana. Early support on Solana routes will positively affect their nomination percentage. Relayers supporting Solana will need:

  1. A valid Solana address to perform fill operations.

  2. The following package dependencies:

    1. @across-protocol/sdk

    2. @across-protocol/contracts

    3. @solana/kit (previously @solana/web3.js@^2.0.0)

While each relayer can decide how to manage their Solana addresses, the recommended approach is deriving the Solana address from the same private key used for EVM operations. This approach minimizes the need to store additional secrets.

Fill Mechanism Changes

For relayers, the most significant update for relayers is the transition from fillV3Relay to fillRelay for handling crosschain transactions:

  1. For deposits from Solana to EVM chains:

    1. Relayers monitor for deposit events on Solana

    2. Use fillRelay to complete the fill transaction on the EVM destination. You can learn more about it here.

  2. For deposits from EVM chains to Solana:

    1. Monitor for deposit events on EVM chains

    2. Use Solana-specific fill functions to complete the transaction

We use emit_cpi!() method in Anchor to emit events through a Cross Program Invocation (CPI) by including the event data in the instruction data. Here, you need to fetch all transactions involving the SVM Spokepool program and inspect the internal event data. Please checkout the helper in the SDK to implement this.

Testing the Migration

You can check that you have updated your relayer codebase properly by simply following the below script to bridge 10 USDC from Solana to Base.

1

Setup the Testing Environment

Start by making an empty folder and running the following commands on the terminal:

2

Running the script

Now, make 3 files in the same directory:

  1. index.js : Main code for the script should be here. feel free to simply copy paste the script given below and add your relayer address on line 102 as the exclusiveRelayer .

  2. .env : Put your Solana Wallet's private key here to be able to bridge funds for testing your relayer.

  3. helper.js : Add all helper functions here to support you as you build the bridge flow.

To run the script, simply head over to your terminal and run the following command and you can see the deposit transaction go forward and get filled by your relayer:


Technical Reference

Deposit Function

The deposit function is used when users want to transfer funds from Solana to an EVM chain:

FillRelay Function

Relayers use this function to complete crosschain transactions:


Support

Want to learn more or need personalized help? Check out developer support and reach out to us!

Last updated