Unlike other blockchains, Solana token model uses Associated Token Accounts (ATAs) to store information about a token, its balance, and its owner. This architecture enables Solana's high performance but requires a deeper understanding of the underlying mechanisms. This practical guide will walk through the code for transferring any token on Solana.

Pre-requisite

Before proceeding with this tutorial, make sure you have the following prerequisites:

1. Basic knowledge of TypeScript.

2. Node.js installed on your machine.

3. npm or yarn package manager installed. (I prefer yarn, so that’s what I’ll be using)

Understanding Solana Token Architecture

Before diving into the code, let's establish a clear mental model of how tokens work on Solana:

1. Token Mint: The definition of a token (like USDC, BONK, or RAY)

2. Token Account: Where token balances are actually stored

3. Wallet: Controls access to token accounts but doesn't directly hold tokens

On Solana, your wallet doesn't directly hold tokens. Instead, for each token type you own, you have a separate Token Account that your wallet controls.

Associated Token Accounts (ATAs): The Practical Solution

An Associated Token Account (ATA) is a special type of token account with an address that's deterministically derived from:

• Your wallet address

• The token's mint address

This creates a predictable mapping that anyone can calculate.

In TypeScript, here's how this mapping works:

import { getAssociatedTokenAddressSync, ASSOCIATED_TOKEN_PROGRAM_ID, TOKEN_PROGRAM_ID } from '@solana/spl-token';

// To find the ATA address for any wallet and token mint
const associatedTokenAddress = getAssociatedTokenAddressSync(
  mintAddress,  // The token's mint address
  walletAddress // The wallet address
);

// Under the hood, this function calculates a PDA (Program Derived Address)
// using the wallet address, TOKEN_PROGRAM_ID, and mint address as seeds

Visually, the relationship looks like this:

Wallet Address    Token Mint Address
       ↓                 ↓
       └────────┬────────┘
                ↓
    Deterministic Calculation
                ↓
    Associated Token Account (ATA)

Code Walkthrough: Transferring Any Token on Solana

Now let's walk through our function for transferring tokens on Solana, explaining each part:

export async function sendSplToken() {
  const wallet = // Create wallet ;
  const mint = new PublicKey("");
  const amount = 1;
  const toAddress = new PublicKey("");
  const connection = new Connection(SOLANA_RPC_ENDPOINT);
  const signer = await wallet.getSigner();

  const Ixs: TransactionInstruction[] = [];

We start by setting up our wallet, mint (the token we want to transfer), amount, recipient address, and a connection to Solana. The Ixs array will hold all our transaction instructions.

Step 1: Handle Native SOL vs SPL Token Transfers

if (new PublicKey(mint).equals(SystemProgram.programId)) {
    Ixs.push(
      SystemProgram.transfer({
        fromPubkey: new PublicKey(wallet.address),
        toPubkey: new PublicKey(toAddress),
        lamports: BigInt(Math.round(amount * LAMPORTS_PER_SOL)),
      }),
    );
  } else {
    // SPL token transfer logic...
  }

Why Native SOL Doesn't Require ATAs:

Solana makes a distinction between its native token (SOL) and all other tokens (SPL tokens):

• Native SOL is built into Solana's core protocol and is stored directly in wallet accounts

• SPL tokens are created using the SPL Token program and require separate token accounts

When transferring native SOL, we simply use SystemProgram.transfer which moves SOL directly between wallet accounts. No ATAs are involved because SOL doesn't use the token program - it's a fundamental part of Solana itself.

Step 2: SPL Token Transfers - Handle Source and Destination ATAs

Now let's analyse the SPL token transfer logic:

} else {
    const sourceAccount = getAssociatedTokenAddressSync(
      new PublicKey(mint),
      new PublicKey(wallet.address),
    );

    const destinationTokenAccountInfo = await connection.getAccountInfo(
      new PublicKey(toAddress),
      "finalized",
    );

    let destinationTokenAccount: PublicKey | null;

    try {
      const tokenAccount = await getOrCreateAssociatedTokenAccount(
        connection,
        signer,
        new PublicKey(mint),
        new PublicKey(toAddress),
      );

      destinationTokenAccount = tokenAccount.address;
    } catch (error) {
      destinationTokenAccount = null;
    }

1. We first determine the sender's ATA using getAssociatedTokenAddressSync

2. We check if the recipient already has an account for this token

3. We try to get or create the recipient's ATA

Important point: The getOrCreateAssociatedTokenAccount function will throw an error if you try to create an ATA that already exists. This is why we catch the error and set destinationTokenAccount to null if it fails. The next section of code handles this scenario.

Step 3: Create ATA for Recipient If Needed

if (!destinationTokenAccountInfo || !destinationTokenAccount) {
      destinationTokenAccount = getAssociatedTokenAddressSync(
        new PublicKey(mint),
        new PublicKey(toAddress),
      );

      Ixs.push(
        createAssociatedTokenAccountInstruction(
          new PublicKey(wallet.address),
          destinationTokenAccount,
          new PublicKey(toAddress),
          new PublicKey(mint),
        ),
      );
    }

This block is critical - if the recipient doesn't have an ATA for this token:

1. We calculate what the recipient's ATA address should be

2. We create an instruction to create this account

Why ATA Creation Throws Errors:

If you attempt to create an ATA that already exists, the transaction will fail with an error like "account already exists". This is a protection mechanism that prevents duplicate accounts and ensures each wallet has exactly one ATA per token mint.

To avoid this error in production code, we first check if the ATA exists before attempting to create it. Our function handles this by:

1. First trying to use getOrCreateAssociatedTokenAccount

2. If that fails, falling back to a manual creation approach

3. Only pushing the create instruction if we confirm the ATA doesn't exist

Step 4: Create Transfer Instruction

const numberDecimals = await getNumberDecimals(mint, connection);

Ixs.push(
    createTransferInstruction(
      sourceAccount,
      destinationTokenAccount,
      new PublicKey(wallet.address),
      Math.round(amount * Math.pow(10, numberDecimals)),
    ),
  );
}

Here we:

1. Get the decimal precision for the token

2. Create the actual transfer instruction and add it to our array

Why Instruction Order Matters:

In Solana, instructions within a transaction are executed in the exact order they're added to the transaction. This is crucial when creating an ATA and then transferring tokens to it in the same transaction:

1. First Instruction: Create the destination ATA

2. Second Instruction: Transfer tokens to the newly created ATA

If we reversed this order, the transfer would fail because it would try to send tokens to an account that doesn't exist yet. This is why in our code, the ATA creation instruction comes before the transfer instruction.

Step 5: Build and Send the Transaction

const latestBlockHash = await connection.getLatestBlockhash();

  const messageV0 = new TransactionMessage({
    payerKey: new PublicKey(wallet.address),
    recentBlockhash: latestBlockHash.blockhash,
    instructions: Ixs,
  }).compileToV0Message();

  const transaction = new VersionedTransaction(messageV0);

  const signedTx = await signer.signTransaction(transaction);

  const signature = await connection.sendRawTransaction(signedTx.serialize(), {
    skipPreflight: true,
  });

  console.log("signature", signature);

  return signature;
}

Finally, we:

1. Get a recent blockhash (required for all Solana transactions)

2. Build a transaction message containing our instructions

3. Create a versioned transaction (the modern transaction format on Solana)

4. Sign the transaction with our wallet

5. Send the transaction to the network and return the signature

Practical Considerations

Token Decimals Matter

Different tokens use different decimal places:

• USDC: 6 decimals (1 USDC = 1,000,000 units)

• Most SPL tokens: 9 decimals (1 token = 1,000,000,000 units)

Our code handles this by fetching the token's decimals and adjusting the amount:

amount * Math.pow(10, numberDecimals)

Rent and Account Creation

Creating an ATA requires SOL to pay for account "rent" (storage space on the blockchain). In our function, the sender pays this cost when creating the recipient's ATA.

As of early 2025, creating an ATA costs approximately 0.00203928 SOL. Keep this in mind when building applications that might create many ATAs.

Error Handling in Practice

In production code, you should add more robust error handling:

try {
  const signature = await sendSplToken();
  console.log("Transfer successful:", signature);
} catch (error) {
  // Common errors to handle:
  // - Insufficient funds (either token balance or SOL for fees)
  // - Invalid addresses
  // - Account already exists errors
  console.error("Transfer failed:", error);
}

Conclusion

This practical guide walked through transferring any token on Solana, highlighting key differences between native SOL and SPL tokens, explaining ATA creation requirements, and demonstrating how to structure your transaction instructions in the correct order.

By understanding these mechanisms, you can now build reliable token transfer functionality into your Solana applications. The token architecture may seem complex at first, but it enables Solana's speed and efficiency while providing a predictable system for managing token ownership.

Finished Work : )

You can find the complete working solution in this GitHub gist here:
https://gist.github.com/Gift-Stack/ca900bc338d636ff5e687d76f59a77cb#file-send-spl-token-ts

Next Steps

To extend this functionality, consider:

• Adding better error handling

• Supporting batch transfers

• Implementing approval flows (delegate authority)

• Supporting Token2022 tokens with their extended features

This article aims to give readers an introduction to building reusable components using Storybook (To visually test your component) and Svelte (To build the actual component).

We will be creating a simple button library that allows users to create styled buttons with just one line of code.

What is Storybook?

Storybook is a tool for UI development that makes development faster and easier by isolating components. This also has an environment for us to view our components. You can check Storybook documentation for more.

Quick introduction to Svelte

According to its blog, Svelte is a component framework — like React or Vue — but with an important difference; unlike other frameworks, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.

So what the above explanations simply mean is that Svelte doesn’t work like other frameworks that use “virtual doms” to update the UI rather, it compiles component files into beautifully optimized JavaScript behind the scenes. So yes, Svelte is just a compiler rather than a framework!

Assumptions

This article assumes that you are already familiar with HTML, CSS, JavaScript, and Svelte basics. No worries, no prior experience of Storybook is necessary.

Getting started with Storybook

We will be using the Storybook + Svelte boilerplate to set up our application and the first thing we need to do is to use degit to set up our boilerplates. Run the following commands:

# Clone template
npx degit chromaui/intro-storybook-svelte-template svelte-button

cd svelte-button

# Install dependencies
npm install

If all has gone well so far, run the following command:

npm run storybook

The Storybook will be opened on localhost:6006 and you will see a screen just like this;

Now you can take a sip of coffee as you are one step closer to building your Svelte library.

File structure

There are important files and folders to pay close attention to in the template you generated earlier. They include;

• rollup.config.js
• src/main.js
• src/stories

rollup.config.js

The rollup.config.js file contains metadata as to how the svelte compiler should read and compile the entire code. Therefore, we have to carefully understand how the compiler is set so we know how to structure our codebase properly.

So, the input portion of it like that in the code below tells the compiler where to look when compiling. Therefore, our main components will be exported.

export default {
  input: "src/main.js",
  output: {
    sourcemap: true,
    format: "iife",
    name: "app",
    file: "public/build/bundle.js",
  }
}

src/main.js

By default we would get something like this;

import App from './App.svelte';

const app = new App({
  target: document.body,
  props: {
    name: 'world'
  }
});

export default app;

This is a basic way to pass props between components in Svelte but we won't be needing this. But at the end of the project, we’d have something like this;

export { default as Button } from './components/buttons/Button.svelte'

src/stories

The stories folder would contain .stories.js files for different components. In these files, we would write our storybook code to help us test our code visually.

You can go ahead to clear the files in this folder for we would be creating ours.

Creating the button component

Firstly, I'd like us to delete every file and folder in the src folder except the main.js file as that is our root file.

In our src folder, we'll create a "components" folder where we'll store, individually, every component our library should have. But in this article, we'd have just one component; The buttons component. In our newly created components folder, we'll create a "buttons" folder where we'll store every code related to the button component. In our buttons folder, we'll create a Button.svelte file.

src                     
└─ components            
    └─ buttons           
      └─ Button.svelte

The next thing we want to do is create our button element and give it some dynamic class names so that it has different styles as requested.

<script>
  export let value
  export let size = 'md';
  export let type = 'default';
  export let shape = 'default';
  export let outlined = false;

  const outlinedClass = outlined
    ? `gl-btn-outlined gl-btn-outlined-${type}`
    : `gl-btn-${type}`;
</script>

  <button class="gl-btn gl-btn-{shape} gl-btn-{size} {outlinedClass}">
    {value}
  </button>

Now that we have specified what our button component should be, let's write our styles to fit every use cases that we want.

<script>
  export let value
  export let size = 'md';
  export let type = 'default';
  export let shape = 'default';
  export let outlined = false;

  const outlinedClass = outlined
    ? `gl-btn-outlined gl-btn-outlined-${type}`
    : `gl-btn-${type}`;
</script>

  <button class="gl-btn gl-btn-{shape} gl-btn-{size} {outlinedClass}">
    {value}
  </button>


<style>
  .gl-btn {
    border-radius: 5px;
    cursor: pointer;
  }
  .gl-btn-outlined {
    background: transparent !important;
  }
  .gl-btn-pill {
    border-radius: 50px;
  }
  .gl-btn-sm {
    padding: 10px 20px;
  }
  .gl-btn-md {
    padding: 13px 32px;
  }
  .gl-btn-lg {
    font-size: larger;
    padding: 15px 50px;
  }
  .gl-btn-primary{
    color: white;
    background: #0275d8;
    border: #0275d8
  }
  .gl-btn-outlined-primary {
    color: #0275d8;
    border: 1px #0275d8 solid
  }
  .gl-btn-success{
    color: white;
    background: #5cb85c;
    border: #5cb85c;
  }
  .gl-btn-outlined-success {
    color: #5cb85c;
    border: 1px #5cb85c solid
  }
  .gl-btn-secondary{
    color: white;
    border: grey;
    background: grey;
  }

  .gl-btn-outlined-secondary{
    color: grey;
    border: 1px grey solid;
  }

  .gl-btn-danger{
    color: white;
    background: #d9534f;
    border: #d9534f;
  }
  .gl-btn-outlined-danger{
    color: #d9534f;
    border: 1px #d9534f solid;
  }
  .gl-btn-warning{
    color: white;
    background: #f0ad4e;
    border: #f0ad4e
  }
  .gl-btn-outlined-warning{
    color: #f0ad4e;
    border: 1px #f0ad4e solid
  }
  .gl-btn-info{ color: white;
    background: #5bc0de;
    border: #5bc0de;
  }
  .gl-btn-outlined-info{
    color: #5bc0de;
    border: 1px #5bc0de solid;
  }
  .gl-btn-light{
    background: #f7f7f7;
    border: #f7f7f7;
  }
  .gl-btn-dark{
    color: white;
    background: #292b2c;
    border: #292b2c;
  }
  .gl-btn-outlined-dark{
    color: #292b2c;
    border: 1px #292b2c solid;
  }
  .gl-btn-link{
    background: transparent;
    border: transparent;
    color: #0275d8;
  }
  .gl-btn-link:hover {
    text-decoration: underline;
  }

</style>

Note, you can store your css anywhere, I just chose to store mine in the same file.

Finally, we'll export our Button component in the main.js file for reusability by replacing the existing code with this;

export { default as Button } from './components/buttons/Button.svelte'

Creating the storybook visual test

Storybook helps document components for reuse and automatically visually test your components to prevent bugs.

Firstly, we will create a stories folder in our src folder, and in our stories folder, we'll create a button.stories.js file.

src                      
└─ stories               
  └─ button.stories.js

Step1: Importing our Button component

import Button from '../components/buttons/Button.svelte'

Step2: Exporting the component to storybook

export default {
    title: 'Button',
    component: Button
}

This would be displayed in Storybook as the folder titled "Button" holding all your test cases.

Step3: Writing the main visual tests

export const Default = () => ({
    Component: Button,
    props: {
        value: 'Button'
    }
})

export const Success = () => ({
    Component: Button,
    props: {
        value: 'Button',
        type: 'success'
    }
})

You should see a screen just like this:

And your button.stories.js file should look like this:

import Button from '../components/buttons/Button.svelte'

export default {
    title: 'Button',
    component: Button
}

export const Default = () => ({
    Component: Button,
    props: {
        value: 'Button'
    }
})

export const Success = () => ({
    Component: Button,
    props: {
        value: 'Button',
        type: 'success'
    }
})

Now that wraps up our button component library. The library flow should look like the image above. I also added some more visual tests to the button.stories.js file, the source code is available at the end of the tutorial.

Publish to npm

This is the easiest segment.

Step1: Create an npm account

Visit npmjs.com and create an account if you haven't before.

Step2: Login to npm on your CLI

npm login

You’ll be prompted to enter your username, password, and email address.

Step3: Publish

npm publish

NOTE: Your package name can be changed in the package.json file.

Conclusion

With Svelte and Storybook, we were able to create a button component library with minimal effort.

The full source code of the app can be found here on Github. Trying out Storybook was very interesting and I recommend you read the documentation to see the magical things you could do with it. If you have any questions, don't hesitate to hit me up on Twitter: @theNameIsGiFTED