Solana Migration Guide
Last updated
Last updated
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.
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 highlight the changes and additions you can make to your current integrations.
Relayers and Indexers: We will be highlighting changes to events worth listen to and details on handling Solana address format.
Supporting Solana is a major milestone in our roadmap. With this, weβre ensuring all Across integrations can seamlessly add Solana to their product suites.
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 in case they want to use the multicall handler contract on Solana. We are still building a seamless experience here and are eager to assist.
Across Protocol will use 34268394551451 as the chain ID for Solana.
When working with the deposit/status
endpoint, there are important parameter changes to note:
The parameter depositTxHash
will still work for EVM chains but is deprecated and will be removed soon.
A new parameter depositTxnId
is being introduced that works universally for both EVM and Solana transactions:
For EVM: This will be the transaction hash
For Solana: This will be the transaction signature
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. All other fields in the API response body will remain the same.
We do not support Solana devnet or testnet at the moment. We urge developers and integrators to test their Solana integration using the Solana mainnet with small amount of tokens. We will let you know as soon as we are live and you can begin testing.
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.
Relayers supporting Solana will need:
A valid Solana address to perform fill operations.
The following package dependencies:
@across-protocol/sdk
@across-protocol/contracts
@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.
When filling to or from Solana, relayers must always specify a valid address on the chain where they request repayment. Failing to do so may result in loss of funds.
For relayers, the most significant update for relayers is the transition from fillV3Relay
to fillRelay
for handling crosschain transactions:
For deposits from Solana to EVM chains:
Relayers monitor for deposit events on Solana
For deposits from EVM chains to Solana:
Monitor for deposit events on EVM chains
Use Solana-specific fill functions to complete the transaction
The deposit function is used when users want to transfer funds from Solana to an EVM chain:
Relayers use this function to complete crosschain transactions:
For Solana routes, demonstrating how to call deposit()
with the integratorID for seamless transaction execution.
Developers are requested to build transactions by fetching details from the API, adding integratorID and calling the deposit()
function in the contract to execute deposit transactions. We will let you know as soon as Solana routes are available in the /suggested-fees
API.
There are no changes in the 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
.
If you need any help adding the integratorID, please reach out to us .
Use fillRelay
to complete the fill transaction on the EVM destination. You can learn more about it .
We use method in 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 to implement this.
Want to learn more or need personalized help? Check out and reach out to us!