SPL Token vs Token-2022: What Actually Changed on Solana

Two Token Programs, One Blockchain

Here is something that catches you off guard when you dig deep enough into Solana development: there are two completely separate token programs running on the network. Not two versions of the same program — two different deployed programs at two different addresses, each managing their own tokens. If you have been building anything that touches token transfers, swaps, or account parsing, this is the kind of thing that turns a working afternoon into a debugging marathon. The original SPL Token program and Token-2022 (officially called Token Extensions) coexist on Solana right now, and understanding the differences is no longer optional.

Why Solana Needed a Second Token Program

The original SPL Token program is elegantly simple. It handles minting, transferring, burning, and the basic account lifecycle that every token needs. Think of it like a standard checking account at your bank — deposits, withdrawals, balance checks. It does the fundamentals well.

But here is the problem. As Solana's ecosystem grew, developers kept running into the same wall: they needed features the original program did not offer. Transfer fees baked into the protocol. Privacy for transaction amounts. The ability to freeze tokens by default for compliance. Metadata stored directly on-chain instead of relying on external programs.

The solution developers reached for was forking. They would copy the entire Token program source code, bolt on whatever custom feature they needed, and deploy their modified version as a separate program. According to the official Solana documentation, this created a fragmentation problem — multiple token programs in transactions complicate development and require trust decisions from wallets and dApps. Every fork meant another program ID that wallets had to recognize, DEXs had to integrate, and users had to trust.

Imagine if every restaurant in your city that wanted to accept tips had to build its own version of the credit card terminal. Some would work with Visa, some with Mastercard, some with neither. That is essentially what was happening — an ecosystem-wide compatibility headache born from legitimate feature demands.

Solana's answer was not to update the original program. Instead, the original SPL Token program was permanently frozen. According to the official documentation, there are no plans to ever add new instructions to Token. A brand new program — Token-2022 — was developed and deployed to a completely different address. The original lives at TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA. Token-2022 lives at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb.

Two programs. Two addresses. One ecosystem trying to hold them both.

Backward Compatible by Design

The smartest decision the Token-2022 designers made was ensuring backward compatibility. This is not a breaking change — it is a strict superset.

According to RareSkills' technical analysis, Token-2022 supports the exact same instruction layouts as the original Token program, preserving the same byte-level format. The original SPL Token program has 25 unique instructions, indexed 0 through 24. Token-2022 supports all 25 of those instructions identically, then adds new functionality starting at index 25. The familiar operations — MintTo, Transfer, Burn — behave exactly as they always have.

The account structures are preserved too. Mint accounts keep their first 82 bytes intact: supply, decimals, freeze authority, all in the same positions. Token accounts keep their first 165 bytes: owner, amount, the fields that every piece of infrastructure already knows how to parse. New extension data gets appended after the base data, not mixed into it.

This is like upgrading from basic cable to a premium package. Your existing channels still work on the same channel numbers. The new channels just start at a higher number. Your old TV remote does not break.

The mechanism for this extension data is Type-Length-Value (TLV) encoding. As RareSkills describes, each entry states both its type and its length, so a program can read the type to understand what it is parsing and then read exactly that number of bytes as the value. This means a program that only understands the base fields can still read a Token-2022 account — it just ignores the extension bytes it does not recognize.

For developers switching from SPL Token to Token-2022, the code change can be surprisingly minimal: swap the program_id in your instructions. The instruction data format stays the same for all the original operations.

The Extension System: What Token-2022 Actually Adds

Token-2022 is not just "SPL Token plus a few extras." It adds twenty new instructions (indices 25 through 44, per RareSkills) and a modular extension system that fundamentally changes what a Solana token can do natively.

Extensions are opt-in. When you create a new mint, you choose which extensions to enable. This is a critical design choice — and a critical constraint. According to the Solana documentation, most extensions cannot be added after an account is initialized. You have to plan your token's capabilities upfront. It is like choosing the options package when you buy a car off the lot. You cannot add all-wheel drive to a front-wheel-drive model after it rolls off the assembly line.

Let me walk through the extensions that matter most.

Transfer Fees: Revenue at the Protocol Level

This is the extension that makes business people sit up straight. Transfer fees allow token creators to configure protocol-level transaction fees that accumulate automatically. No smart contract wrappers, no external fee collection mechanisms. Every transfer of the token automatically skims a configured percentage.

The fees accumulate in the recipient's token accounts and can be withdrawn by the designated authority on the mint account. One real-world example: $BERN (BonkEarn) was one of the first tokens built on Token Extensions, implementing a 6.9% transfer fee distributed across holder rewards, buybacks, burns, developer funding, and DAO contributions, according to Helius.

For anyone parsing token transfers on-chain, this matters. The amount that arrives in a recipient's account is not the same as the amount that was sent. If your calculations assume transfer amounts equal received amounts, they will be wrong for any token using this extension.

Confidential Transfers: Privacy Through Zero-Knowledge Proofs

Confidential Transfers use zero-knowledge proofs and what the Solana documentation describes as Twisted ElGamal Encryption to mask both balances and transfer amounts. The tokens still move on-chain, but observers cannot see how much was transferred or what the current balance is.

This is not total anonymity — it is selective disclosure. An optional auditor can be granted access, which makes this extension particularly relevant for institutional and regulatory use cases where privacy and auditability need to coexist.

Transfer Hooks: Custom Logic on Every Transfer

Transfer Hooks let token creators attach a custom program that executes during every transfer of their token. Think of it as a callback function that fires automatically. This is particularly useful for enforcing NFT royalties, running compliance checks, or implementing KYC verification at the protocol level.

For anyone processing transactions on-chain, transfer hooks mean that a token transfer is not just a transfer anymore. It triggers additional program execution, which means additional accounts in the instruction, additional compute units consumed, and additional failure modes to handle.

Permanent Delegate: The Compliance Power Tool

The Permanent Delegate extension grants a designated address unlimited authority to transfer or burn tokens from any account holding that mint. According to the Solana docs, this delegate can transfer or burn tokens in any token account of that mint.

This sounds alarming from a DeFi-native perspective — someone can reach into your wallet and move your tokens? But the use case is compliance-driven. Regulated stablecoins, real-world asset tokens, and KYC-gated ecosystems need the ability to claw back tokens under specific regulatory conditions. It is the financial equivalent of an escrow agent with master key access.

For on-chain observers, this means that tokens with a permanent delegate can move in ways that do not follow normal authorization patterns. A transfer might happen without the token account owner's signature, which fundamentally changes assumptions about who initiated a transaction.

Non-Transferable Tokens: Soulbound on Solana

The Non-Transferable extension creates what the broader crypto community calls "soulbound" tokens. According to the Solana documentation, once minted, the tokens remain permanently in the token account. The owner can burn them and close the account, but they cannot send them to anyone else.

Use cases include certificates, on-chain identity markers, achievement badges, and event tickets — anything where the value is tied to the holder, not the asset itself.

CPI Guard: Defense Against Malicious Programs

The CPI Guard is a security-focused extension that protects token accounts from unexpected transfers through Cross Program Invocations. When enabled, tokens can only be transferred through direct calls to the Token Extensions program's transfer instruction. As the Solana documentation warns, without this guard a malicious CPI could call set_delegate and gain transfer and burn authority over the token account.

This is an account-level extension — each individual token account must enable it separately. It does not apply at the mint level.

Other Notable Extensions

The full extension list includes additional capabilities that fill specific niches:

• Default Account State allows mint creators to freeze all new token accounts by default, requiring explicit approval before holders can transact — a compliance-first feature.
• Interest-Bearing Tokens display an interest-accruing value in the UI without rebasing the actual supply.
• Mint Close Authority permits closing mint accounts, which was impossible with the original Token program.
• Required Memo on Transfer enforces that all incoming transfers include an on-chain memo — useful for institutional transfers requiring reference codes.
• Metadata and Metadata Pointer allow storing token metadata natively on-chain within the mint account, reducing dependence on external metadata programs.
• Pausable (one of the newer additions) allows a designated authority to halt all token transfers — an emergency stop mechanism.

What Cannot Coexist

Not all extensions play nicely together. According to RareSkills and the official Solana documentation, several extension combinations are incompatible:

• Non-Transferable tokens cannot have Transfer Fees (if you cannot transfer, there is nothing to charge a fee on)
• Non-Transferable tokens cannot have Transfer Hooks (same logic)
• Confidential Transfers conflict with Transfer Hooks, Transfer Fees, and Permanent Delegate

These restrictions make sense when you think about the mechanics. Confidential transfers encrypt amounts — how would you calculate a percentage-based fee on an amount you cannot see? How would a transfer hook program operate on data it cannot decrypt? The incompatibilities are not bugs; they are logical constraints.

The Ecosystem Compatibility Gap

Here is where the reality gets complicated. Token-2022 is technically superior in almost every way. It offers everything the original program offers plus a modular extension system. But technology superiority does not automatically translate to ecosystem adoption.

As Smithii observes, "The SPL token is the most common option for Solana projects. Its compatibility with the Solana ecosystem is almost absolute and it is indexable on absolutely all exchanges. A significantly smaller number of wallets support [Token-2022] compared to SPL."

This is the classic adoption chicken-and-egg problem. Think of it like the early days of USB-C. Everyone agreed it was better than micro-USB — faster data, reversible connector, power delivery. But for years, you still needed to carry both cables because half your devices had not switched yet.

The wallet situation is improving. Several major wallets have integrated Token Extensions support. Developer tooling has caught up as well — Anchor v0.30.1, released in December 2024, added support for token account constraints for Token Extensions, per the Anchor release notes.

Enterprise adoption is where Token-2022 is gaining the most traction. According to the Solana Solutions page, regulated entities have launched stablecoins on Solana using Token Extensions. The compliance features — transfer fees, default frozen accounts, permanent delegate authority — are exactly what regulated financial products need.

The Security Picture

A new token program handling potentially billions in value needs serious security validation. According to the official documentation, Token-2022 has been audited by six independent firms as of March 2025: Halborn, Zellic, Trail of Bits, NCC Group, OtterSec, and Certora. That is a substantial audit surface — each firm brings different methodologies and specializations.

The depth of auditing matters because the extension system increases the attack surface significantly compared to the original program. Each extension adds new instruction handlers, new account validation logic, and new state transitions. The incompatible extension combinations hint at the complexity — even the designers recognized that certain feature interactions create unsafe conditions.

What This Means for Anyone Building On-Chain

If you are building anything that reads, writes, or processes Solana tokens, you cannot treat the token landscape as monolithic anymore. Every token account you encounter might be managed by either program. The implications cascade:

Account parsing changes. A Token-2022 mint account has the same first 82 bytes as an SPL Token mint, but it may have additional extension data appended. If your parsing code reads a fixed number of bytes, it still works for the base fields. But if you need to understand the token's capabilities — does it have transfer fees? Is it non-transferable? Does it have a permanent delegate? — you need to parse the TLV extension data.

Transfer amount assumptions break. With transfer fees, the amount debited from the sender is not the amount credited to the receiver. Any calculation that assumes conservation of token amounts across a transfer will produce wrong results for tokens with this extension enabled.

Authorization models expand. Permanent delegates can move tokens without the account owner's signature. CPI Guards restrict how tokens can be moved programmatically. Transfer hooks inject additional program execution into what used to be a simple transfer instruction. The mental model of "tokens only move when the owner signs" is no longer universal.

Compute budget considerations. Transfer hooks mean a token transfer can trigger arbitrary program execution. The compute units required for a transfer are no longer predictable based solely on the transfer instruction itself. You need to account for whatever the hook program does.

Program identification becomes critical. You need to determine which program manages a given token before you can correctly construct instructions for it. The Associated Token Account program handles creation for both standards, but the program ID in your transfer, mint, or burn instructions must match the token's actual program.

The migration path between standards is not automatic. You cannot convert an existing SPL Token into a Token-2022 token. You cannot add extensions to an already-initialized account. If a project wants Token-2022 features, it needs to create a new mint with the desired extensions configured from the start.

The Coexistence Reality

The framing that matters is not "SPL Token vs. Token-2022" as a competition where one replaces the other. Both programs are deployed, both are processing transactions, and both will continue to exist indefinitely. The original SPL Token program is frozen but not deprecated. It will keep running as long as Solana runs. Existing tokens built on it will continue to work exactly as they always have.

Token-2022 is where all new development happens. It is the program that gets new features, new extensions, and new capabilities. For anyone creating tokens today — especially for enterprise, compliance, or advanced DeFi use cases — Token-2022 is the clear choice.

But for anyone consuming tokens — building DEXs, wallets, analytics tools, or any program that processes arbitrary tokens — the reality is dual-program support. You handle both, or you miss tokens. There is no shortcut.

I am discovering that the implications run deeper the more I dig. Every layer of assumption I had about how tokens behave on Solana needs re-examination. The base operations are the same, but the edge cases — fees, hooks, delegates, guards — create a landscape that is significantly more complex than what the original SPL Token program defined. The question is not whether to learn this. The question is how quickly you can adapt.

Key Takeaways

• Token-2022 is a strict superset of SPL Token, preserving byte-level instruction compatibility while adding twenty new instructions and a modular extension system based on TLV encoding.
• The original SPL Token program is permanently frozen — it will never receive new features, but it will never be deprecated either. Both programs coexist indefinitely.
• Extensions must be chosen at mint creation and cannot be added later, making upfront design decisions critical for token creators.
• Transfer fees, confidential transfers, and permanent delegates fundamentally change assumptions about how tokens move — any on-chain program that processes arbitrary tokens must account for these behaviors.
• Ecosystem support is growing but not yet universal — enterprise adoption is leading the charge, while broader wallet and DEX support continues to catch up to the original SPL Token's near-total compatibility.