Token-2022 vs SPL Token: When to Use Which
Pick between Token-2022 and SPL Token before mint locks the decision. Compatibility reality, a project-type decision table, and how j.tools handles each.
USDC, USDT, BONK, JTO, JUP, and W are all classic SPL tokens. Pyth, PayPal USD, and a growing list of tokenized real-world assets sit on Token-2022. Both programs live on Solana. Both look like "tokens" in your wallet. The choice between them is locked at mint time. This post is about picking the right one before you sign.
Below: what each program actually is, which on-chain features only Token-2022 unlocks, where Token-2022 still breaks in the wild, and a decision table that maps project types to a recommended standard. Concrete enough that you can act on it without reading a second post.
The original SPL Token program
The classic SPL Token program is the one Solana shipped on day one. It defines a mint, token accounts, and a small set of authorities: mint authority, freeze authority, and an owner per token account. Metadata is bolted on through Metaplex via a separate metadata account. There are no per-token feature flags. Every classic SPL token behaves the same way at the protocol level; the differences live in the metadata and the issuer's off-chain policy.
That uniformity is the whole point. Every Solana wallet, every DEX, every aggregator, and every explorer assumed classic SPL behavior for the first three years of the network. Anything more exotic than "transfer fungible balance" was the application's problem, not the token's.
If you are building a memecoin, a community token with no on-chain fee logic, an LP-tradeable governance token, or anything you want to list on Raydium and Jupiter without thinking about edge cases, classic SPL is the safe default. The Solana SPL token creator tool on j.tools mints one with custom decimals, supply, metadata, and authority revokes from a single form.
What Token-2022 actually is
Token-2022 is a second token program that ships alongside the original. Same wallet experience, different program ID. The big idea: instead of one rigid token shape, the mint can opt into specific "extensions" at creation time. Each extension is a feature you turn on, and they compose.
The set our Token-2022 creator tool currently exposes maps directly to the extensions most projects actually use:
- Transfer fee. A protocol-level fee charged on every transfer, in basis points up to a cap. The fee accrues in the recipient account and is withdrawable by a fee authority. This is on-chain enforcement, not "trust me, my contract collects fees".
- Interest bearing. The balance display in wallets accrues at a configured rate. Useful for yield-bearing stablecoin variants. The underlying balance is unchanged; only the rendered amount shifts.
- Default account state. Newly created token accounts start in the
initializedorfrozenstate. Choosefrozenfor a token that requires manual approval before the holder can move balance, which fits permissioned distributions. - Required memo on transfer. Every incoming transfer must carry a memo instruction. Compliance-friendly for fiat-backed issuers.
- Close authority on the mint. The mint itself can be closed and rent reclaimed once supply is zero. Cleaner lifecycle than the classic program where an empty mint sits forever.
- Non-transferable. Soulbound. The token holder cannot transfer; useful for badges, identity, or proof-of-attendance.
- Permanent delegate. A single authority that can move any token account's balance, forever. Powerful and dangerous, suited to issuers with a regulatory mandate to claw back funds.
- Transfer hook. A custom on-chain program runs as part of every transfer. The strongest hook is also the most risky for integrations: any DEX or aggregator has to whitelist your hook program before it will route through.
- Metadata pointer. The mint stores metadata in-program rather than relying on Metaplex. Saves an extra account and read.
The extension set is fixed at mint creation. You cannot add transfer fee to a Token-2022 mint a week later. Same as authority revoke on classic SPL: the decision lives at minute zero.
The data shape our tool accepts maps cleanly to the on-chain layout:
// tools/modules/token2022-creator/types.ts
interface Token2022Extensions {
transferFee?: { feeBasisPoints: number; maxFee: number; recipient?: string };
interestBearing?: { rate: number };
defaultAccountState?: 'initialized' | 'frozen';
memoRequired?: boolean;
closeAuthority?: string;
nonTransferable?: boolean;
permanentDelegate?: string;
transferHook?: string;
metadataPointer?: boolean;
}
The compatibility reality check
Token-2022 sounds like an upgrade. In a vacuum it is. In production it has rough edges, and you need to know where before you commit.
Raydium standard pools refuse Token-2022. The original AMM pool factory was built for the classic program and was not retrofitted for the new mint shape. Their CLMM and CPMM variants have added partial support, but transfer-fee tokens specifically get rejected in places where the routing math assumes a clean 1:1 swap. Test with the actual pool factory before you build a launch plan around Token-2022.
Jupiter routes most extensions but not all. Jupiter has invested in Token-2022 compatibility, and a clean Token-2022 mint with metadata pointer or interest bearing usually routes fine. Mints with transfer hooks are different: the aggregator has to whitelist the hook program, otherwise quoting silently drops the token from results. New hook programs do not magically appear in routes.
Wallets show the balance but extension UI varies. Phantom, Backpack, and Solflare all read Token-2022 balances and display them like any other token. Where they diverge is showing extension state to the user. Transfer fees deducted at send time, interest accrual on the displayed amount, frozen-by-default account state, required memo on send — each wallet renders some, hides others, or warns on a few. Expect users to be confused the first time their actual transferred amount is less than the displayed input.
Aggregators and explorers vary. Solscan and Solana FM both read Token-2022 metadata and balances correctly. Older third-party aggregators may misreport supply because they did not update their parsers. NFT marketplaces are not the concern here, but if you are minting an SBT-style non-transferable token, do not expect any marketplace UI to handle it; the listing flow will fail before any sale logic runs.
Before you commit to a Token-2022 launch, run a 1-token devnet mint, list it on a test DEX pool, route a swap through Jupiter quote, and try the integration you actually depend on. The general support story is real; the specific support story is what kills launches.
Decision table: which one fits your project
| Project type | Recommended standard | Why |
|---|---|---|
| Memecoin or community token | Classic SPL | Maximum DEX and wallet coverage, zero compatibility surprises, lowest mint cost. |
| Fee-on-transfer revenue token | Token-2022 (transfer fee) | The fee is on-chain enforced. No need for a fee router contract. Confirm DEX support before launch. |
| Stablecoin with compliance hooks | Token-2022 (memo required, permanent delegate) | On-chain memo for off-chain compliance, clawback authority for regulatory mandates. |
| Yield-bearing token | Token-2022 (interest bearing) | Wallet-rendered yield without an off-chain accrual service. |
| Soulbound badge or identity token | Token-2022 (non-transferable) | The transfer block is protocol level. Cannot be unwound by user mistake. |
| Tokenized real-world asset | Token-2022 (default frozen, permanent delegate) | Holders need explicit unfreeze. Issuer keeps a regulatory recovery path. |
The pattern is straightforward. If you need anything on-chain beyond "fungible balance with metadata and revokable authorities", Token-2022 is the answer. If you do not, the classic SPL Token program will get you to a Raydium pool faster and with less testing.
Launching from j.tools: what differs
Both flows start the same way: connect a wallet, fill a form, sign one transaction. The shapes diverge at the field set.
The Solana SPL token creator tool shows you classic authority controls. Revoke mint authority, revoke freeze authority, make metadata immutable. These map directly to the mint's authority slots and the metadata's update authority. A 0.1 SOL platform fee, a single wallet signature, a mint address you can paste into Raydium ten minutes later.
The Token-2022 creator tool shows you an extension list. You pick the extensions you want before signing, configure each one (basis points for transfer fee, rate for interest bearing, target wallet for permanent delegate), and the tool composes a single transaction that creates the mint with all extensions enabled at once. Once the mint is signed, the extension configuration is locked in. The platform fee is slightly higher (0.15 SOL) because the transaction does more on-chain work and uses more compute.
Authority revoke options apply to both standards. The revoke mint authority tool works against Token-2022 mints too, and the make metadata immutable tool covers both metadata paths.
Common mistakes
- Choosing Token-2022 for marketing reasons. "We use the new standard" is not a launch advantage if your DEX pool refuses your token. Pick on technical fit, not press release.
- Stacking too many extensions. Every extension adds a surface for integration partners to refuse you. A Token-2022 mint with transfer fee plus transfer hook plus default frozen state will fail Jupiter routing, fail most pool factories, and lose holders who cannot move their balance.
- Setting transfer fee too high. A 5% transfer fee crushes secondary market liquidity. LP providers see their balance decay every time they rebalance. Most viable transfer-fee tokens stay under 2%, and the most common range is 0.5% to 1%.
- Permanent delegate on a community token. The permanent delegate can move any wallet's balance. If your holders find this in your mint config, expect the listing to be flagged on every Solana risk scanner within hours.
- Forgetting that classic SPL authority revoke is one-way too. Both standards make irreversible decisions at mint config. Read each toggle twice before you sign.
For more launch-side writeups, the Solana guides category covers adjacent ground (LP setup, snapshot airdrops, holder analytics), and the Solana tagged posts page collects the full feed.
The SPL vs Token-2022 choice is a product decision in technical clothing. The standard locks in what your token can and cannot do for its entire life. Match it to what your project actually needs, not what sounds more advanced in a Twitter thread.
