---
title: Deposit on Solana
description: Building the deposit instruction, the accounts it needs, and the escrow it pays into.
---

import { PROGRAM_SOLANA, ESCROW_SOLANA } from "/snippets/vars.mdx";

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 {PROGRAM_SOLANA}, returned as `router_address` on the quote. The funds land in the escrow, a program-derived account ({ESCROW_SOLANA}, seed `escrow`); its address and token accounts derive from the program id, so nothing beyond the quote is needed to build the deposit.

## Instructions

| Instruction | When |
| --- | --- |
| `deposit_native` | `src_token` is the system program id, meaning SOL. |
| `deposit_token` | `src_token` is an SPL mint that equals `bridge_token_src`. |
| `deposit_swap` | `src_token` differs from `bridge_token_src`: the deposit swaps through an aggregator first. |

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

```
[0..8)    sha256("global:deposit_token")[0..8]
[8..40)   quote hash
[40..48)  amount, u64 little-endian
```

## Accounts

<Tabs>
  <Tab title="deposit_token">
    | Index | Account | Signer | Writable |
    | --- | --- | --- | --- |
    | 0 | Depositor | yes | yes |
    | 1 | Mint | no | no |
    | 2 | Depositor's associated token account | no | yes |
    | 3 | Escrow authority (PDA, seed `escrow`) | no | no |
    | 4 | Escrow's associated token account | no | yes |
    | 5 | Token program | no | no |
  </Tab>
  <Tab title="deposit_native">
    | Index | Account | Signer | Writable |
    | --- | --- | --- | --- |
    | 0 | Depositor | yes | yes |
    | 1 | Escrow authority (PDA, seed `escrow`) | no | yes |
    | 2 | System program | no | no |
  </Tab>
</Tabs>

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`](/api-reference/get-swap-instructions) 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`](/api-reference/gasless); 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.

```ts
import { buildSvmDeposit, createChainAdapter } from "@mayanfinance/hular-sdk";

const transaction = await buildSvmDeposit({
  rpcUrl,
  programId: quote.orderParams.routerAddress,
  owner: wallet.address,
  token: quote.orderParams.srcToken,
  amount: BigInt(quote.orderParams.amountIn),
  quoteHash: quote.quoteHash,
});
```

Or let the adapter handle it, which is the same path the EVM chains take:

```ts
const adapter = createChainAdapter(client, chainStatus);
const [deposit] = await adapter.steps(wallet, quote.quoteHash, quote.orderParams);
await deposit.run();
```

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](/integration/track).