A Solana deposit is a single instruction to the Blink program, carrying the quote hash and the amount. There is no approval step: SPL transfers are authorized by the signature on the transaction itself. The program id is BLinKtWiWoLWqeFpBS3esiVjUxtM5h15VNmg8dzev6ee, returned as router_address on the quote. The funds land in the escrow, a program-derived account (45AE2z4b7bhaapKQLRDNMfx6P5gMkTZScmzhg2bEZex6, seed escrow); its address and token accounts derive from the program id, so nothing beyond the quote is needed to build the deposit.

​
Instructions

For deposit_token, instruction data is 48 bytes: an 8-byte discriminator, the 32-byte quote hash, then the amount as a little-endian u64.

​
Accounts

The last two accounts let the program emit its deposit event as a call to itself signed by the event authority. A deposit that omits them, or passes a different event authority, fails. Derive both associated token accounts against the mint’s owning token program, read from the mint account, and derive the escrow ATA with the escrow PDA as owner. Token-2022 mints are owned by a different program than legacy SPL mints, and deriving against the wrong one produces an address the transfer will not accept.

​
Deposits that swap first

When the source token is not the asset that bridges, fetch GetSwapInstructions for the quote. The aggregator builds the route for the swap authority, a program-derived address with seeds swap_authority, the depositor, and the quote hash, so the depositor’s wallet never signs anything the aggregator produced and the depositor is the transaction’s only signer. The route is built for the quote’s depositor, or its refund_address when the quote request named none, so request the quote with the wallet that will sign the deposit. One transaction then runs:
  1. Create the swap authority’s token account for the source token, rent paid by the depositor.
  2. Move expected_amount_in into it: a TransferChecked under the mint’s token program for SPL and Token-2022 tokens, or a lamport transfer plus SyncNative for SOL.
  3. When swap_authority_lamports is not zero, a lamport transfer of that amount from the depositor to the swap authority. Some venues pay rent for accounts they open during the swap, and on this route the swap authority is their payer.
  4. The aggregator’s setup, which may only create the swap authority’s associated token accounts with the depositor paying rent.
  5. deposit_swap, which invokes the aggregator with the program signing as the swap authority, checks that the escrow received at least min_lock_amount, returns every lamport the swap authority still holds to the depositor, and emits the deposit event. Its named accounts end with the system program, the event authority, and the Blink program, and the swap’s accounts follow them. The swap authority is writable. The program rejects the call if the depositor is among the swap’s accounts.
  6. Release every token account the swap authority owns, returning the rent to the depositor: close_swap_account for WSOL, and sweep_swap_account for any other mint, which first returns a leftover balance to the depositor’s token account and harvests withheld transfer fees to the mint. Nothing can be stranded with the authority.
For a Token-2022 source with a transfer fee, the depositor still sends exactly expected_amount_in. The authority’s account receives it less the fee for the current epoch, and both the quote and the route from GetSwapInstructions are priced and built for that net amount. If the mint’s fee rises before the deposit lands, the swap cannot take its input and the transaction fails; if it falls, step 6 returns the remainder. Transfer hook accounts are resolved for step 2. Mints whose new accounts start frozen are not supported. buildSvmSwapDeposit in the SDK checks the payload, assembles the whole versioned transaction, simulates it, and sets the compute unit limit to the simulated usage plus 30% headroom; the wallet adds the depositor’s signature. svmSwapAuthority derives the authority for a program id, depositor, and quote hash.

​
Gasless deposits

A quote requested with gasless: true returns a sponsor_address. Build the same deposit with the sponsor as fee payer, sign it, and hand the serialized transaction to SubmitGaslessOrder; the sponsor co-signs and submits it, so the depositor needs no SOL. The SDK’s gaslessSteps does this end to end.

​
With the SDK

buildSvmDeposit assembles the instruction, derives the escrow accounts, resolves the token program, sets the fee payer, and attaches a recent blockhash. It returns a serialized unsigned transaction ready for a wallet to sign.
Or let the adapter handle it, which is the same path the EVM chains take:
Solana deposits are always a single step. There is no approval to prompt for.

​
Priority fee

Every deposit transaction the SDK builds carries its own SetComputeUnitLimit and SetComputeUnitPrice instructions. A transaction without them is one many wallets rewrite with a flat priority fee of their own, often far above what the network needs. The builders take the price as computeUnitPriceMicroLamports. The adapter takes it as svmComputeUnitPrice in the deposit options:
Gasless deposits ignore the option: the sponsor pays the fee and only accepts its own fixed price.

​
Account rent

If the recipient on a Solana destination has no associated token account for the delivered mint, one is created during fulfillment and its rent appears as dst_ata_create in the fee breakdown. The same applies on the source side for refunds, as src_ata_create. Both are already priced into amount_out.

​
Confirmation

The deposit is picked up once it confirms and the required confirmations accrue. As on EVM chains, nothing else is submitted by the user. Move to Track an order.