Skip to main content
For Solana, call_data is a base64-encoded serialized legacy Transaction. It already contains the native SOL or SPL-token transfer and a top-level memo used to match the deposit.

Transaction construction

1

Decode the transaction

Convert the base64 call_data string into a Transaction object.
2

Set a fresh blockhash

Fetch the latest blockhash from the Solana RPC and update the transaction so it doesn’t expire before it’s confirmed.
3

Validate balances (optional)

Estimate the transaction fee and verify the sender has enough SOL for fees and enough of the source token for the transfer amount.
4

Sign the transaction

Sign with the sender’s keypair or wallet adapter.
5

Send and confirm

Submit the signed transaction to the network and wait for confirmation.

Submit the prepared transaction

Decode the transaction, replace its expired blockhash, sign it, and submit the signed bytes. The Server-side tab signs locally with a Keypair; the Browser tab uses a connected wallet adapter (Phantom, Solflare, and similar) and its signTransaction method.
Do not remove, reorder, or replace the prepared instructions.

Resend until confirmed

Under congestion a submitted transaction can be dropped before it lands. Resending the same signed bytes is safe — the signature deduplicates — so keep resubmitting until confirmation succeeds or the blockhash expires:
If confirmation fails because the blockhash expired, refresh the blockhash and request a new signature before retrying.

If you construct the transaction yourself

A custom transaction must do both of the following:
  1. Transfer the native SOL or SPL token to the returned destination.
  2. Add swap.metadata.sequence_number as a top-level instruction through the SPL Memo program.
An inner memo emitted through CPI is not used for matching. A transfer that reaches the correct address without the top-level memo can remain unmatched and expire. The safer default is to submit the prepared call_data transaction. Store the signature and track the swap.