SPL Token: The Program Behind Every Solana Token (2026)
What an SPL token actually is on-chain: mint accounts, ATAs, the 3 authorities, Token-2022 extensions, and how the SPL Token Program runs Solana's token economy.
An SPL token is any token issued by Solana's SPL Token Program (program ID TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA), the single on-chain program that owns every Solana token's state. Unlike Ethereum, where each ERC-20 deploys its own contract, one shared program mints, transfers, freezes, and burns balances for every SPL token, from USDC to BONK to a coin launched 20 minutes ago. The model is composed of 5 accounts: a Mint Account, per-holder Token Accounts (usually ATAs), the ATA program derivation, an optional Metaplex Metadata PDA, and the 3 Authority keys. Creation costs ~0.07 SOL, confirms in 1-2 seconds. This piece walks through each account, who controls what, and where Token-2022 changes the picture.
The 60-second version
| Spec | Value |
|---|---|
| SPL Token Program ID | TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA |
| Token-2022 Program ID | TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb |
| ATA Program ID | ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL |
| Metaplex Metadata Program ID | metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s |
| Typical creation cost | |
| Token account rent | ~0.00204 SOL per ATA |
| Metaplex metadata account rent | ~0.0144 SOL |
| Block confirmation | 1-2 seconds |
| Authorities you can revoke | 3 (mint, freeze, update) |
| Token-2022 extensions available | 15+ |
| Memecoin convention | 1B supply, 6 decimals, 3 authorities revoked |
Almost everyone arriving on this page is solving for one of four things. They want to launch a token and figured out "SPL" is the word they need. They want to integrate something that takes SPL deposits and need to know what an SPL token actually is in the wallet. They are coming from Ethereum and want the analog mapping. Or they hit Token-2022 in some doc and are wondering whether the original SPL is the wrong answer. This piece covers all four, but the core is the 5-account model in section three, that's the thing the SERP top results never name.
What an SPL Token Actually Is

The phrase "SPL token" gets used three ways in casual writing, and the casualness causes confusion.
Sense 1: A token issued by Solana's SPL Token Program. This is the technically correct meaning. Any mint account owned by program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA is an SPL token. That covers fungible tokens like USDC (6 decimals, the parity reference), BONK (5 decimals, 100T supply), and WIF (6 decimals, 1B supply). It also covers NFTs (most Solana NFTs are SPL tokens with supply=1, decimals=0, and a Metaplex metadata PDA pointing at the artwork).
Sense 2: Any Solana token. People say "SPL token" when they mean "any Solana fungible thing," which informally also includes Token-2022 tokens. Token-2022 tokens are technically NOT SPL tokens (they're owned by a different program at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb), but in conversational use this distinction collapses. Through the rest of this piece, "SPL token" means sense 1 unless I'm specifically contrasting with Token-2022.
Sense 3: The SPL Token CLI (spl-token). Some developers say "SPL token" when they mean the official Solana command-line tool for creating and managing these tokens. Different thing, same name. Context usually disambiguates.
The reason this token model exists at all is Solana's account model. Every piece of on-chain state is an account, and accounts are owned by exactly one program. The SPL Token Program owns mint accounts and token accounts; it's the only program allowed to mutate their state. Every other program that wants to move tokens (Raydium, Jupiter, your wallet) calls into the SPL Token Program via Cross-Program Invocation (CPI). One shared program, every Solana token routes through it. That's the architecture.
The 5-Account SPL Model

Most explainers treat mint accounts, token accounts, ATAs, and metadata as separate concepts. They're separate accounts, but they form one model. Naming the model makes the rest of this piece (and your debugging) easier.
Here is the 5-account framework. Every functioning SPL token has all five.
-
Mint Account. Stores the token's global state: total supply, decimals, mint authority pubkey, freeze authority pubkey. Owned by the SPL Token Program. Created once per token, by the deployer. Approximate rent: 0.00203928 SOL. Solscan calls this "the mint address" and it's the public-facing identifier (e.g. BONK's mint is
DezX...B263). -
Token Account. Stores one specific holder's balance of one specific token. Owned by the SPL Token Program but the authority is the holder's wallet. Created once per (holder, mint) pair. Approximate rent: 0.00203928 SOL. A wallet with balances of 50 different tokens has 50 token accounts.
-
Associated Token Account (ATA). A deterministically derived token account where the address is computed from
(wallet_address, mint_address, ATA_program_id). The Associated Token Account Program atATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knLdoes this derivation. Same fields as a regular token account; just predictable rather than arbitrary. This is what Phantom and Solflare create automatically. 99% of token accounts in practice are ATAs. -
Metaplex Metadata PDA. Stores the token's name, symbol, image URI, and royalty config. Owned by the Metaplex Token Metadata program at
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s. PDA stands for Program Derived Address, the address is derived from(metadata_program_id, mint_address). Approximate rent: 0.01437 SOL. Technically optional (tokens function without metadata) but every consumer-facing token has one. See what is Metaplex Token Metadata. -
Authority Keys. Not separate accounts, but pubkey fields inside the Mint Account. Three of them: mint authority (can call
MintToto create more supply), freeze authority (can callFreezeAccountto freeze a holder's token account), update authority (Metaplex's, can update the metadata PDA's name/image). Setting an authority toNone(viaSetAuthority) revokes it permanently. By Solana protocol design, irreversible.
The five accounts plus the three authority fields are the complete on-chain footprint of a working SPL token. When you create a memecoin via alchemii's memecoin flow, the tool builds all five in a single signed transaction, plus revokes the authorities as a follow-up signature. Total cost lands around 0.07 SOL (0.002 mint + 0.002 ATA + 0.0144 metadata + service fee + small overhead).
flowchart TD
Mint["Mint Account<br/>(total supply, decimals,<br/>authority pubkeys)"]
Meta["Metaplex Metadata PDA<br/>(name, symbol, image URI)"]
TA1["Token Account / ATA<br/>(holder A's balance)"]
TA2["Token Account / ATA<br/>(holder B's balance)"]
TA3["Token Account / ATA<br/>(LP pool's balance)"]
Authority["Authority Keys<br/>(mint, freeze, update<br/>or null)"]
Mint -.derived from.-> Meta
Mint -.referenced by.-> TA1
Mint -.referenced by.-> TA2
Mint -.referenced by.-> TA3
Mint -.contains.-> Authority
The Mint Account is the hub. Token accounts (one per holder) and the metadata PDA all reference it. The authority pubkeys live inside the Mint and control who can change what.
A common mistake when reading Solana data the first time: people think the Mint Account stores balances. It doesn't. The Mint Account stores global state (total supply, decimals, authorities) but each holder's balance lives in their own token account. To find out who holds how much, you query all token accounts whose mint field equals the target mint, not the mint account itself. This is also why Solana RPCs offer getTokenAccountsByOwner and getTokenLargestAccounts as separate methods.
Mint Accounts, Token Accounts, and ATAs: How They Connect

The relationship between these three account types is the single most confusing thing about Solana tokens for developers arriving from Ethereum. The mental model that helps: the Mint is a menu item in the SPL Token Program's records, the Token Accounts are individual receipts that say "wallet X owns Y units of menu item Z," and ATAs are receipts with predictable filenames.
Concretely. Say you want to send 100 BONK to a friend.
- The SPL Token Program needs to find your token account for BONK and your friend's token account for BONK. If your friend has never held BONK before, their ATA does not yet exist on-chain.
- Your wallet (Phantom, Solflare, Backpack) checks: does the friend's ATA exist? If no, your wallet creates it as part of the transaction. Creating the ATA costs ~0.00204 SOL of rent, paid by the sender.
- Now both ATAs exist. The SPL Token Program decrements 100 from your token account and increments 100 in your friend's token account. The Mint Account's total supply doesn't change (this is a transfer, not a mint).
- Total transaction cost: ~0.00005 SOL signature fee + ~0.00204 SOL ATA rent if you opened a new ATA. The whole thing confirms in 1-2 seconds.
The 30-day Phantom indexing window I mentioned in my bio's list of scars bites in step 2. If you minted a brand-new SPL token less than ~30 days ago, the recipient's Phantom may show the token as "Unknown Token" or refuse to display the symbol/image, because Phantom's indexer hasn't picked up the new metadata PDA yet. The tokens are there; the on-chain state is correct; Phantom just hasn't gotten around to indexing it. Solscan will show it correctly immediately; Phantom catches up within days or weeks. See solana token not showing in Phantom for the workaround.
The reason ATAs exist (rather than letting every transaction specify arbitrary token account addresses) is wallet UX. Without deterministic addressing, you'd have to look up "what is wallet X's BONK account address?" before every transaction. With ATAs, you compute it: findProgramAddress([wallet_address, token_program_id, mint_address], ATA_program_id). Same inputs, same output, always. Phantom can pre-compute every ATA you might ever need. So can DEXes, indexers, anything.
| Account type | Created by | Who pays rent | Typical count per wallet |
|---|---|---|---|
| Mint Account | Token deployer (once per token) | Deployer | N/A (one per token, not per wallet) |
| Token Account (non-ATA) | Anyone, with arbitrary address | Creator | Rare in practice |
| ATA | First receiver or sender | The transaction signer | One per held token (potentially hundreds) |
| Metaplex Metadata PDA | Token deployer | Deployer | N/A (one per token) |
One operational note that costs roughly 0.5 SOL of rent across most active Solana wallets I help debug. Every ATA you've ever held (even tokens you've sold and have 0 balance in) is still rent-exempt on-chain. Closing about 30 unused ATAs recovered roughly 0.5 SOL of rent — at ~0.00204 SOL per account, the math is straightforward. Solflare has a built-in "close unused token accounts" button; Phantom doesn't but lets you do it via custom transactions. Most users never bother.
The 3 Authorities: Who Controls What Post-Mint
Three authority fields determine whether your token can be modified after launch. Each one is set when the token is created (defaults to the deployer's wallet) and can be revoked permanently by calling SetAuthority with newAuthority: None. Revocation is, by Solana's protocol design, irreversible.
Mint Authority. The pubkey allowed to call MintTo and create new supply. If active, the holder can inflate the supply to any number. If null, the supply is permanently capped at its current value. For memecoins promising fixed supply, revoking mint authority is non-negotiable. See how to revoke mint authority on Solana for the walkthrough and what is mint authority on Solana for the concept-deep-dive.
Freeze Authority. The pubkey allowed to call FreezeAccount and freeze a specific holder's token account, preventing them from transferring. If active, the holder can freeze any wallet's ability to move the token, a serious centralization concern in DeFi. If null, no one can be frozen. USDC keeps freeze authority active (Circle needs it for OFAC compliance). Memecoins revoke it.
Update Authority. This is the Metaplex authority on the metadata PDA, not on the mint itself. The pubkey allowed to update the token's name, symbol, image URI, and (in older Metaplex versions) immutability flag. If active, the deployer can swap the image or rename the token after launch. If null, the metadata is frozen. Pre-Metaplex-v2, this was an extra gotcha because the immutability flag was a separate setting from the update authority, leading to tokens that looked immutable but actually weren't. Metaplex Token Metadata v2 cleaned this up.
| Authority | Lives in | Default value | Memecoin convention | What revocation prevents |
|---|---|---|---|---|
| Mint authority | Mint Account | Deployer wallet | Set to None before LP open | New supply ever being minted |
| Freeze authority | Mint Account | Deployer wallet | Set to None before LP open | Any holder's tokens being frozen |
| Update authority | Metaplex Metadata PDA | Deployer wallet | Set to None before launch | Name, symbol, or image being changed |
The order of operations matters. Across the 47 SPL tokens I've shipped, the launches that held up consistently had mint and freeze revoked before LP deposit, not after. The reason isn't technical (revocation works fine after LP open). The reason is trader perception. A serious memecoin trader checks the Jupiter strict list and verifies on Solscan that both authority fields read null before placing a meaningful buy. If the LP has been live for 6 hours and authorities are still active, they assume the deployer is hesitating, and they don't buy. The signal you want to send is "I made my decision before I opened liquidity." For the full pre-launch sequence see the how-to flagship, and for the LP-side of the flow see alchemii's liquidity tool.
flowchart LR
A[Mint Account created<br/>3 authorities = deployer] --> B[Initial supply minted to deployer]
B --> C[Metadata PDA written<br/>name, symbol, image URI]
C --> D{Revoke authorities?}
D -->|Yes, BEFORE LP| E[mint = null<br/>freeze = null<br/>update = null]
D -->|No| F[Authorities retained,<br/>trader-perceived risk]
E --> G[Open Raydium LP]
F --> G
G --> H[Burn LP tokens<br/>for full lock]
SPL Token vs Token-2022: What Changed
Token-2022 is a successor program deployed in 2023 at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb. It is not a replacement for the original SPL Token Program, both run concurrently on Solana mainnet. Tokens deployed under Token-2022 are owned by a different program and are not interchangeable with original SPL tokens, even though they appear identically in wallets.
Token-2022 adds 15+ optional "extensions" you can enable per-token at creation. The headline ones:
- Transfer fees. A built-in tax on every transfer (e.g. 2% routed to a treasury wallet). Original SPL has no native way to do this; you'd need an external program. Cost: ~0.01-0.05 SOL extra rent per extension.
- Confidential transfers. Hide transfer amounts on-chain using zero-knowledge proofs. Useful for institutional settlements or compliance-sensitive payments.
- Non-transferable (soulbound). Tokens that can't be transferred after issuance. Used for credentials, badges, identity.
- Permanent delegate. A specific wallet can move tokens from any holder's account. Used by regulated stablecoins for OFAC compliance.
- Interest-bearing. Balance grows over time at a configured rate. Used for tokenized treasuries, bonds, auto-compounding stablecoins.
- Default account state. New holder accounts frozen by default until KYC'd.
- Metadata pointer. Native on-chain metadata, no separate Metaplex PDA required.
The compatibility caveat is what bites in production. Phantom displays Token-2022 tokens correctly (since late 2023). Raydium CPMM pools support Token-2022, but specific extensions (transfer fees, non-transferable) sometimes break Jupiter routing or LP creation. The Solana docs on Token Extensions maintain a current compatibility matrix.
For 95% of launches, the original SPL Token Program is the right pick. Memecoins, simple utility tokens, governance tokens, none need extensions. Token-2022 is for the specific cases (regulated stablecoins, reflection tokens, soulbound credentials) where an extension is the whole point. The full breakdown of trade-offs and per-extension costs is in Token-2022 extensions deep-dive.
SPL Token vs ERC-20: The Mental Model Shift
For developers and operators arriving from Ethereum, the SPL model requires a shift. ERC-20 is a contract standard, every token deploys its own smart contract that implements the ERC-20 interface, and you call methods on that contract. SPL is one shared program, every token is just state owned by the same Token Program, and you call methods on the program, passing the mint as a parameter.
| Dimension | SPL Token | ERC-20 |
|---|---|---|
| Architecture | One shared program for all tokens | One deployed contract per token |
| Token identity | Mint account address | Contract address |
| Balance storage | Separate token accounts (one per holder) | Mapping inside the contract |
| Metadata | Separate Metaplex PDA | Inside contract OR external (e.g. token list) |
| Authorities | 3 fields in mint account (mint, freeze, update) | Owner pattern, varies by implementation |
| Custom transfer logic | Not possible (program is shared) | Override transfer in contract |
| Creation cost | ~$10-50 in gas at typical mainnet rates | |
| Confirmation time | 1-2 seconds | ~12 seconds per block |
| Audit requirement | None (program already audited) | Strongly recommended (your code is on-chain) |
| Upgrade path | Token-2022 extensions | New contract deployment |
The structural consequence of "one shared program" is that SPL tokens cannot ship custom on-chain logic the way ERC-20s can. An ERC-20 reflection token can override transfer to skim 2% on every move; an SPL token cannot, unless you use Token-2022's transfer-fee extension. This is by design, Solana's account model prefers composition (multiple programs CPI-ing into each other) over inheritance (one contract overriding another's behavior). If you need custom logic on transfers, you build a separate program that wraps the token, you don't modify the Token Program.
The cost and speed differences compound across operations. Deploying an ERC-20 on Ethereum mainnet ran $10-50 at 2024-2025 gas levels, plus the cost of any subsequent admin transactions (which can each run $5-30). Confirmation is ~12 seconds per block, finality is multiple blocks. SPL creation runs around 0.07 SOL with metadata included, and subsequent operations (revoke, mint, burn) cost fractions of a cent each. Confirmation is 1-2 seconds, finality is typically within 10 seconds for memecoin-grade activity. For the full chain-level breakdown see Solana token vs Ethereum ERC-20.
The honest part: ERC-20 has 9 more years of compatibility shimming. Every Ethereum wallet, every DeFi protocol, every backend integration knows how to handle ERC-20 quirks. SPL is younger, leaner, and arguably better-designed, but it's also less battle-tested against the long tail of edge cases that you only find at scale.
Operator Notes: What I've Learned Across 47 SPL Token Launches
This section is where the founder voice lives. Twelve of these 47 were paid client launches; the rest were my own experiments, some that worked, several that didn't. The patterns below are not "best practices" in the generic sense, they're the things I've watched cost real SOL and real attention when ignored.
The authority-revocation order has more impact than the LP size. Across the 47 SPL tokens I've shipped, the launches that held up consistently had mint and freeze revoked before LP deposit, not after. The launches that opened LP first and revoked later (or never) had measurably worse first-hour holder retention, even when the LP was the same size. I don't have a published dataset for this, just the operator pattern from being on the inside of every launch.
Closing about 30 unused ATAs recovered roughly 0.5 SOL of rent — at ~0.00204 SOL per account, the math is straightforward but almost nobody bothers. After every failed launch, the deployer's wallet usually has 10-30 ATAs for tokens nobody wants anymore. The rent is sitting there. Solflare's "close token accounts" button reclaims it in one signed transaction. I recovered about 0.5 SOL across abandoned launches earlier in 2024, which paid for ~7 more SPL token creations.
The 30-day Phantom indexing window is real and frustrating. Sometime in the first month after you create an SPL token, Phantom may display it as "Unknown Token" or refuse to render the metadata image, even though Solscan shows everything correctly. The indexer just lags. You can pre-warm it by sending the token to a Phantom-active wallet and waiting; usually within 3-10 days the metadata catches up. This costs zero on-chain SOL but costs the launch real attention if a buyer's Phantom shows blanks. The Phantom indexing window post covers the diagnostic flow.
The Metaplex pre-v2 immutable-metadata gotcha will eat you if you copy old code. Before Metaplex Token Metadata v2, the "immutable" flag on a metadata PDA was a separate setting from the update authority. You could set immutable=true and still update the metadata if the update authority was active, or set immutable=false and still freeze the metadata accidentally. v2 cleaned this up but copy-pasted tutorials from 2021-2022 still set both flags independently and produce surprising behavior. Always set update authority to None for "real" immutability. Don't trust just the immutable flag.
The Raydium V4 vs V3 difference matters more than people think. Raydium V4 (the current AMM v4) and Raydium V3 (the older CLMM-precursor) use different pool templates with different fee tiers and different LP token structures. New tokens default to V4 these days, but some older tutorials still wire up V3 deployments, and the LP burn instruction is different between them. If you copy a "how to burn LP" snippet from 2023, it might be targeting V3. Check the pool program ID before signing.
The 1B supply / 6 decimals memecoin convention exists because Phantom's UI rounding makes other numbers look weird. A 100T supply (like BONK) displays as "100,000,000,000,000" in raw form and traders mentally lose track of the unit. A 1B supply with 6 decimals (like WIF) lets a typical holder show a balance of "12,345.67 WIF," which fits Phantom's display without scientific notation. This is not a technical requirement, it's a UX convention that survived because it works. Most memecoins follow it. Some don't, and they look weirder in wallets, which costs trust.
Where the SPL Token Program Sits in the Solana Stack
To round out the model, here's how the SPL Token Program relates to everything else on Solana you'll touch. The SPL repository on GitHub hosts ~30 reference programs maintained by Solana Labs and contributors; the Token Program is one of them. Other notable SPL programs include the Memo program, the Stake Pool program, and the Token Lending program.
flowchart TD
subgraph Solana["Solana runtime"]
Token["SPL Token Program<br/>(every token's state)"]
Token22["Token-2022 Program<br/>(extensions)"]
ATA["ATA Program<br/>(deterministic addressing)"]
Meta["Metaplex Token Metadata<br/>(name, symbol, image)"]
end
subgraph Consumers["Programs that call into SPL Token via CPI"]
Ray["Raydium AMM<br/>(creates LP tokens, also SPL)"]
Jup["Jupiter Aggregator<br/>(routes swaps)"]
Wallet["Phantom / Solflare / Backpack<br/>(wallet UX)"]
Orca["Orca Whirlpools<br/>(concentrated liquidity LP tokens)"]
end
Token -.referenced by.-> Ray
Token -.referenced by.-> Jup
Token -.referenced by.-> Wallet
Token -.referenced by.-> Orca
Token22 -.alternative to.-> Token
ATA -.derives accounts of.-> Token
Meta -.attaches PDA to.-> Token
When you swap BONK for USDC on Jupiter, the trade is composed of a Jupiter Aggregator program call that routes through Raydium (or Orca, or Lifinity, depending on the best price), which CPI-calls the SPL Token Program to debit your BONK token account and credit your USDC token account. Five-plus on-chain programs cooperate in one transaction. The SPL Token Program is at the bottom of that stack, the boring foundation that everything else assumes works.
This is also why the Token Program almost never changes. A breaking change to TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA would break every Solana DeFi protocol simultaneously. So Solana Labs introduced new features as a separate program (Token-2022) rather than upgrading the original. The original SPL Token Program has the same instruction set today that it had in 2021 when I started launching tokens, which is unusual and a feature, not a bug.
Where this breaks
A few places where this guide's framing falls short and you should look elsewhere.
- Token-2022-specific concerns are skimmed. This piece covers the original SPL Token Program in depth and Token-2022 only as a comparison. For the per-extension trade-off analysis (when transfer fees are worth the compatibility cost, which extensions break Jupiter routing) see the Token-2022 extensions deep-dive.
- NFTs are mostly out of scope. Solana NFTs are SPL tokens with supply=1 and decimals=0, but the practical NFT workflow (Candy Machine, Bubblegum compressed NFTs, royalty enforcement) is its own ecosystem. The 5-account model still applies but the NFT-specific tooling is different.
- Legal classification is a separate question. Whether your specific token is a security under your jurisdiction's law is not a technical question and this guide doesn't touch it. If you're launching anything with revenue-sharing or yield, talk to a lawyer.
- CPI-level developer details are abbreviated. This is a conceptual / operator-focused pillar. For implementation specifics (Anchor IDLs, native instruction layouts, transaction-building patterns in TypeScript / Rust) read the Solana docs on the Token Program and the solana-program-library repo directly.
- Bridged token contexts are not covered. Wormhole-wrapped tokens (e.g. wormhole-wrapped ETH on Solana) are SPL tokens technically, but their economics and trust model are about the bridge, not the SPL standard. Out of scope here.
- Token Extensions on Solana mobile / non-EVM wallets. Compatibility moves quickly. The wallet support details in this piece are accurate as of mid-2026; check the current Solana Token Extensions compatibility matrix before launching anything Token-2022-based that needs broad reach.
SOL needed for an SPL token launch (worked formula)
A reader who wants to know "how much SOL do I actually need" can run this formula with their own numbers.
SOL needed = 0.00204 (Mint Account rent) + 0.01437 (Metaplex Metadata rent) + 0.00204 (deployer ATA) + 0.00010 (signature fees for 2-3 txs) + service_fee + (LP_amount_in_SOL)
Three worked examples at different inputs:
- Pure-on-chain SPL token, no LP, no service fee (CLI launch): 0.00204 + 0.01437 + 0.00204 + 0.00010 = ~0.018 SOL total (~$3 at SOL=$170).
- Memecoin via alchemii, 5 SOL LP, 0.07 SOL service fee: 0.018 + 0.07 + 5.0 = ~5.09 SOL total (~$865 at SOL=$170).
- Token-2022 with 3 extensions, 10 SOL LP, no service fee: 0.018 + (3 × 0.03) extension overhead + 10.0 = ~10.11 SOL total (~$1,720 at SOL=$170).
The LP amount dominates. If you're using a no-code tool the service fee is small relative to LP. If you're CLI-launching pure-supply (no LP, no metadata), you can do it for under 0.02 SOL but the resulting token has no liquidity and won't trade.
Questions readers ask
What is an SPL token?
An SPL token is any fungible or non-fungible asset issued by Solana's SPL Token Program (program ID TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA). It is not a separate blockchain or smart contract. It is a row of state managed by one shared on-chain program that mints, transfers, freezes, and burns balances for every token on Solana, from USDC to BONK to a coin you launched twenty minutes ago.
What is the SPL Token Program?
The SPL Token Program is the Solana on-chain program at TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA that owns every SPL token's mint account and every holder's token account. It is roughly Solana's analog to ERC-20, except instead of one contract per token, one program serves every token. The newer Token-2022 program at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb is its successor and adds optional extensions.
What is a Token Account and an Associated Token Account (ATA)?
A token account holds your balance of a specific SPL token. It is a separate account from your wallet's main SOL account. An Associated Token Account (ATA) is a deterministically derived token account, one per wallet per mint, computed from your wallet address plus the mint address using the ATA program at ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL. Wallets like Phantom create ATAs automatically when you first receive a token.
How is an SPL token different from an ERC-20 token?
Three structural differences. First, there is one shared SPL Token Program on Solana, versus one contract per token on Ethereum, so SPL tokens cannot ship custom logic the way ERC-20s can override transfer. Second, balances live in separate token accounts, not in a contract-owned mapping. Third, on-chain metadata is a separate Metaplex PDA, not encoded in the contract itself. Cost and speed differ too. SPL creation costs around 0.07 SOL and confirms in 1-2 seconds, versus 10-50 dollars and roughly 12 seconds for ERC-20 deployment on Ethereum mainnet.
What is the difference between SPL Token and Token-2022?
Token-2022 is a successor program at TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb that adds 15+ optional extensions, transfer fees, confidential transfers, non-transferable balances, permanent delegate, interest-bearing tokens, and others. The original SPL Token Program does not have these. Tokens deployed against Token-2022 are not interchangeable with SPL Token, they live at separate program IDs. For a memecoin or simple utility token, stick with the original. For a regulated stablecoin or tax token, Token-2022 is the right pick. See the Token-2022 extensions deep-dive for the full extension catalogue.
Sources
- SPL Token Program documentation: official spec for the original Token Program, including instruction list and account layout.
- Solana Token Program developer docs: developer-facing program reference, CPI patterns, instruction encoding.
- Solana Account Model: why Solana uses one shared program per asset type rather than per-asset contracts.
- Solana Token Extensions (Token-2022): the 15+ extensions catalogue with current wallet and DEX compatibility.
- Metaplex Token Metadata documentation: Metaplex Token Metadata program spec, including the update-authority and immutability flag.
- Associated Token Account program: ATA derivation algorithm and program ID.
- BONK mint on Solscan: 100T supply, 5 decimals; mint and freeze authorities both
null. - WIF mint on Solscan: 1B supply, 6 decimals; the modern memecoin convention.
- USDC mint on Solscan: 6 decimals; freeze authority active (Circle's compliance design).
- solana-program-library on GitHub: reference implementation for the Token Program, ATA Program, and ~30 other SPL programs.
- Raydium AMM documentation: how Raydium V4 and CLMM pools issue LP tokens (themselves SPL tokens).
- Jupiter aggregator docs: routing behavior, strict-list and all-list semantics.
- Phantom token-display documentation: how Phantom indexes new SPL tokens and the metadata window.
- Orca Whirlpools documentation: concentrated-liquidity DEX that emits LP positions as SPL tokens — alternative to Raydium CLMM.
- Solana Explorer — Token Program account: live view of the SPL Token Program account itself, showing it as a deployed BPF program at this address.
Related guides
Raydium Token Launch: The 5-Step Playbook (2026)
End-to-end Raydium token launch flow: mint your SPL, configure metadata, seed a Raydium pool, burn LP, and get listed on Jupiter. Total cost ~0.5 SOL.
Solana LP Burn Proof: What to Share After You Burn
Burned LP is only a trust signal if traders can verify it. The 10-step proof-of-burn checklist — what to share, in what order, on Solscan, DexScreener, TG, X.
Solana Token Creator No-Code: When It Wins vs CLI
An operator's 47-launch breakdown of no-code Solana token creator tools vs the spl-token CLI and Anchor: when each wins, scored across 6 scenarios.