SOC 2 Badge

GetBlock Secures SOC 2 Type 1 Attestation.Strengthening Enterprise & Institutional Position

How to Create Tokens with Token Extensions on Solana (Token-2022 Guide)

blog_author_logo

GETBLOCK

April 1, 2026

6 min read

You want to add transfer fees to your token. The original SPL Token program says no. You need KYC-gated transfers for compliance. The original program can't help. You're tokenizing real-world assets that are subject to regulatory controls. You're on your own.

Token Extensions (Token-2022) is a Solana Program Library (SPL) that addresses the limitations that have held back institutional adoption and advanced token use cases. 

In this guide, you’ll learn what Token Extensions are, which extensions matter most, and walk you through our step-by-step tutorial for creating your first token with embedded metadata.

TL;DR

Token Extensions expand what's possible with Solana tokens—without custom code or security risks. Here's what you need to know:

  • Token-2022 maintains all original SPL Token functionality while adding optional extensions you can enable at the protocol level.

  • Extensions solve real problems: transfer fees for enforceable royalties, confidential transfers for private payments, transfer hooks for compliance controls.

  • No more forking. Each forked token program introduces unaudited code and ecosystem fragmentation. Token Extensions are native, audited, and composable.

  • We've published a complete implementation guide with working JavaScript code in our documentation.

Let's explore what makes Token Extensions essential and how to use them effectively.

What Are Token Extensions?

The original Solana Program Library (SPL) Token program handles the basics: creating, minting, transferring, and burning tokens. Think of it as Solana's equivalent to Ethereum's ERC-20 standard.

But the original program has a restricted definition. Need functionality beyond the fundamentals? You have two options: build custom code from scratch or fork the token program entirely.

Both approaches create problems. Custom code is time-consuming and difficult to get adopted across the ecosystem. Forked programs introduce unaudited code and complicate transactions - Solana's programming model requires programs to be included in transactions alongside accounts, making multi-program token interactions unnecessarily complex.

Token Extensions (Token-2022) solves this by maintaining all original functionality while adding optional extensions you can enable natively. No custom code. No forks. No security compromises.

Think of it like building with LEGO. The original program gives you basic blocks. Token-2022 gives you specialized pieces - wheels, hinges, motors - that snap right in.

Ready to access blockchain data with flexible pricing? Sign up for GetBlock and start building with our RPC endpoints today.

Why Token Extensions Matter?

Token Extensions address a fundamental tension: permissioned tokens on a permissionless network. This unlocks three major categories:

1. Institutional Adoption:

Banks, asset managers, and regulated entities need compliance controls that the original token program simply can't provide. Paxos uses Token-2022 for its USDP stablecoin, leveraging confidential transfers and permanent delegate authority to support regulatory compliance.

2. Real-World Asset (RWA) Tokenization:

Securities, bonds, and other regulated assets require features like transfer restrictions and mandatory compliance checks. Token Extensions make this possible at the protocol level - not through fragile workarounds.

3. Creator Economies:

NFT royalties have been a persistent problem - marketplaces can simply ignore them. Transfer fees in Token-2022 are enforced at the protocol level. The BERN token demonstrates this with a 6.9% transfer fee on every transaction. Royalties that actually stick.

Understanding the Available Extensions

Token Extensions fall into two categories: Mint Extensions (applied to token mints) and Account Extensions (applied to token accounts).

Transfer Fees:

Charge fees at the protocol level. Fees are withheld from the recipient automatically. Use cases include permanent royalties and transaction-based revenue.

Transfer Hooks:

Control which wallets can interact with your token. Essential for KYC verification and token-gated access.

Confidential Transfers:

Hide transaction amounts while maintaining validity proofs. Critical for on-chain payroll and B2B payments.

Metadata & Metadata Pointer:

Embed token metadata directly on mint accounts. No external metadata programs required.

Non-Transferable Tokens:

Create soulbound credentials that can't be traded or transferred.

Permanent Delegate:

Grant irrevocable authority over tokens for regulatory compliance (freeze/seize orders).

Memo Transfer:

Require memo instructions for payment attribution and compliance records.

Immutable Owner:

Prevent token account hijacking by locking ownership.

CPI Guard:

Protect against cross-program invocation attacks.

Not all extensions can be combined. Non-Transferable tokens can't use Transfer Hooks or Transfer Fees - if tokens can't transfer, those extensions have nothing to do. Confidential Transfers conflict with Transfer Hooks because hooks need to read amounts that confidential transfers encrypt.

The Four-Step Process That Actually Works

Let's build a token using the Metadata Extension. This embeds token metadata directly on the mint account - one of the most commonly needed features.

1. Set Up Your Environment

Create a new project and install dependencies:

1

2

3

4

mkdir token-2022-tutorial
cd token-2022-tutorial
npm init -y
npm install @solana/web3.js @solana/spl-token @solana/spl-token-metadata dotenv bs58

Create a .env file with your GetBlock RPC endpoint and wallet private ke

1

2

RPC_URL=https://go.getblock.io/YOUR_ACCESS_TOKEN
PRIVATE_KEY=your-wallet-private-key

2. Calculate Space and Rent Requirements

This is where most developers make mistakes. The mint account needs sufficient space for the extensions you use:

1

2

3

const mintLen = getMintLen([ExtensionType.MetadataPointer]); 
const metadataLen = TYPE_SIZE + LENGTH_SIZE + pack(metadata).length;
const lamports = await connection.getMinimumBalanceForRentExemption(mintLen + metadataLen);

Underestimate this, and you'll get an "insufficient lamports" error. The TYPE_SIZE (2 bytes) and LENGTH_SIZE (2 bytes) account for the metadata structure overhead, plus the actual packed metadata size.

3. Build the Transaction in the Correct Order

Order matters. The sequence must be: create account, initialize metadata pointer, initialize mint, initialize metadata.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

const transaction = new Transaction().add( 
SystemProgram.createAccount({ 
fromPubkey: payer.publicKey,
newAccountPubkey: mint,
space: mintLen,
lamports: lamports,
programId: TOKEN_2022_PROGRAM_ID,
}), 
createInitializeMetadataPointerInstruction( 
mint, payer.publicKey, mint, TOKEN_2022_PROGRAM_ID, 
), 
createInitializeMintInstruction( 
mint, decimals, payer.publicKey, null, 
TOKEN_2022_PROGRAM_ID,
), 
createInitializeInstruction({ 
programId: TOKEN_2022_PROGRAM_ID, 
mint: mint, 
metadata: mint, 
name: metadata.name, 
symbol: metadata.symbol, 
uri: metadata.uri, 
mintAuthority: payer.publicKey,
updateAuthority: payer.publicKey, 
}), );

The metadata pointer points to the mint itself - this is what allows the metadata to live directly on the mint account rather than in a separate program.

4. Send and Verify

1

2

3

4

5

const signature = await sendAndConfirmTransaction( 
connection, transaction, 
[payer, mintKeypair], 
{ commitment: "confirmed"
}, );

You should see output confirming your token creation with the mint address and transaction signature. Verify on Solscan by searching for your mint address.

What Can You Build With This?

Understanding Token Extensions unlocks several capabilities:

  1. Compliant stablecoins with built-in freeze/seize capabilities for regulatory requirements.

  2. NFT collections with enforceable royalties that marketplaces can't bypass.

  3. Membership tokens that are non-transferable - true soulbound credentials on Solana.

  4. Privacy-preserving payment systems using confidential transfers for payroll or B2B transactions.

  5. RWA platforms where securities and bonds have transfer restrictions enforced at the protocol level.

The difference between building on the original SPL Token program and Token-2022 lies in the choice between workarounds and native solutions.

Ready to Build Your Own?

We've created a comprehensive guide that walks you through building a fully functional Token-2022 implementation. You'll learn how to:

  1. Set up the development environment with the right dependencies

  2. Connect to Solana using GetBlock's RPC endpoints for reliable connectivity

  3. Calculate space requirements for your chosen extensions

  4. Build properly ordered transactions with extension instructions

  5. Send and confirm with appropriate commitment levels

The complete implementation takes under 50 lines of JavaScript. By the end, you'll have a reusable pattern for any token type - fungible tokens, NFTs, or compliance-gated assets.

Access the full guide here and the complete code repository.

Conclusion

Token Extensions aren't complicated, but getting them right requires understanding which extensions solve your specific problem and building transactions in the correct order.

The pattern is simple: choose your extensions based on use case, calculate space requirements accurately, initialize in the right sequence, and verify on-chain.

If you're creating tokens on Solana in 2025, Token-2022 isn't optional. It's the standard.

Want reliable Solana infrastructure for your Token-2022 implementation?  Create your free GetBlock account and access production-grade RPC endpoints.