Solana Migration Guide

Across is expanding support to Solana and 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 this date to prevent disruptions.

---

Introduction

The changes detailed in this guide aim to support Developers, Integrators and Relayers in order to advance their current codebases and implement the suggested changes to support bridging USDC to-and-from Solana. Here is a quick overview:

• Developers and Integrators: We will be highlighting changes and additions you can make to your current integration and specifying libraries you can leverage to ensure a safe and robust upgrade. Special emphasis will be on integratorIDs.

• Relayers and Indexers: We will be highlighting changes in events to listen to and details around handling Solana address format.

Supporting Solana is a huge milestone in our roadmap and with this we also want to ensure that we enable all Across integrations to be able to add Solana to their product suites.

---

Summary of Product Changes

SpokePool contract deployed on Solana supports USDC bridging between Ethereum Mainnet, all supported L2s and Solana. Integrators must use the new Deposit()function in order to use the Solana routes. You can learn more about the contract here.

DepositV3 is not being deprecated and can continue to be used for all EVM routes.

We urge integrators to reach out to us in case they want to use the multicall handler contract on Solana. We are still building out a seamless experience here and are open to helping out.

---

For Indexers

When working with the deposit/status endpoint, there are important parameter changes to note:

1. The parameter depositTxnHash will still work for EVM chains but is being deprecated.

2. A new parameter depositTxnId is being introduced that works universally for both EVM and Solana transactions:

   1. For EVM: This will be the transaction hash

   2. For Solana: This will be the transaction signature

Transaction Status Tracking

The status values returned by the deposit/status API remain unchanged:

• pending

• filled

• expired

• requestSlowFill

• refunded

However, be aware that Solana transactions use signatures rather than transaction hashes for identification.

---

For Developers and Integrators

All integrators must get their integratorIDs by filling this form, if they haven't already. IntegratorIDs increase our power to help integrators by 10 times! We can assess your traffic and even alert you in case of any emergencies. For Solana routes, here is a utility script that shows how deposit()can be called along with the integratorID for seamless deposit transaction execution.

To support Solana integration, you'll need to add the following packages:

# For EVM chains
npm install @across-protocol/sdk @across-protocol/contracts viem

# For Solana
npm install @across-protocol/sdk @across-protocol/contracts @solana/kit

The @solana/kit package (previously named @solana/web3.js@^2.0.0) provides utility functions and types for working with Solana addresses and transactions, similar to how viem functions for EVM chains.

The across-protocol/app-sdk will ensure that you can fetch relayerFees and gas needed for bridging transactions on Solana. You will also be able to get Solana in the supportedChains() utility of the App-SDK.

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

---

For Relayers

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 to derive 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 change is the transition from using fillV3 to fillRelay for handling cross-chain transactions:

1. For deposits from Solana to EVM chains:

   1. Relayers monitor for deposit events on Solana

   2. Use fillRelay to complete the transaction on the EVM destination

   3. Receive repayment in either USDC on Solana or ERC20 tokens (based on preference)

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, one needs to fetch all transactions involving the SVM Spokepool program and inspect the internal event transaction. Please checkout the helper in the SDK to implement this.

---

Technical Reference

Deposit Function

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

// This function is called when a user wants to bridge from Solana to another chain
function deposit(
    Pubkey depositor,           // The depositor address in Pubkey format
    Pubkey recipient,           // The recipient address on the destination chain
    Pubkey input_token,          // Token being deposited (on Solana)
    Pubkey output_token,         // Token to receive on destination chain
    u64 input_amount,         // Amount of input token being deposited
    u64 output_amount,        // Amount of output token to receive
    u64 destination_chain_id,  // Destination chain ID
    Pubkey exclusive_relayer,    // Address of exclusive relayer (use Pubkey::default() if none)
    u32 quote_timestamp,       // Timestamp when quote was generated
    u32 fill_deadline,         // Deadline after which deposit can't be filled
    u32 exclusivity_parameter,  // Deadline for exclusive relayer's priority
    Vec<u8> calldata message       // Additional message data
) external payable;

FillRelay Function

Relayers use this function to complete cross-chain transactions:

/// This function is called when a relayer wants to fulfill a cross-chain bridge request by sending
/// the specified output tokens to the recipient on the destination chain.
function fillRelay(
    [u8; 32] relay_hash,             // Hash uniquely identifying the deposit to be filled. Computed as hash of relay_data & destination_chain_id.
    V3RelayData relay_data,         // Struct containing all deposit data (matches parameters from FundsDeposited event).
    Pubkey depositor,              // The account credited with the deposit on the origin chain.
    Pubkey recipient,              // The recipient account receiving the funds on this chain.
    Pubkey input_token,            // Token used for deposit on the origin chain.
    Pubkey output_token,           // Token to be received by the recipient on the destination chain.
    u64 input_amount,           // Amount deposited by the user on the origin chain.
    u64 output_amount,          // Amount sent to the recipient on the destination chain.
    u64 origin_chain_id,        // Origin chain identifier.
    Pubkey exclusive_relayer,      // The exclusive relayer allowed to fill the deposit before the exclusivity deadline.
    u32 fill_deadline,           // Deadline after which deposit cannot be filled.
    u32 exclusivity_deadline,    // Deadline for exclusive relayer to maintain priority.
    bytes calldata message,         // Message to be passed.
    u64 repayment_chain_id,     // Chain where the relayer expects repayment after the challenge period.
    Pubkey repayment_address       // Address where relayer wants to receive refund on the repayment chain.
) external;

---

Support

To learn more and get help based on your specific needs, please head over to developer support and reach out to us!