A Solana deposit is a single instruction to the Hular 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 5xYDhC59T7TXVtgCMpHYaaXyXsd3GDT4j4RHzQzMfyrs, returned as router_address on the quote. The funds land in the escrow, a program-derived account (DvCPeroncQwfZxWBzQxHbUYNr4wpYGRZ4AoNkj2iUqhA, 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_native and 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

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 svm payload carries the aggregator’s setup, swap, and cleanup instructions plus lookup tables; the swap step is wrapped in the program’s deposit_swap instruction, which invokes the aggregator, checks that the escrow received at least min_bridge_out, and emits the deposit event. buildSvmSwapDeposit in the SDK assembles the whole versioned transaction.

​
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.

​
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.