How to create an SPL token on Solana, step by step (Token Program and Token-2022)

This guide goes from a test token on devnet to a token with issuer controls. The commands were tested on October 16, 2026 with solana-cli 4.3.1 and spl-token-cli 5.6.1 (the versions the stable channel installed that day) against a local validator; on devnet, only the URL changes. For the network and service context, start with our page on Solana development.

Before you start: SOL, SPL tokens and the two token programs

SOL is the network's native token: you pay fees and deposits with it. One lamport is 0.000000001 SOL. Tokens that anyone creates are called SPL tokens (from Solana Program Library), and they are not contracts of their own: they are data accounts owned by a token program that is already deployed. Three pieces:

• Mint. Identifies the token and stores the supply, the decimals, the mint authority (who can create new units) and the freeze authority (who can lock accounts). Its address is the token's identifier in wallets and explorers.
• Token account. Holds one owner's balance for one mint. A wallet needs one for each token it holds.
• Associated token account (ATA). The wallet's "default" account for a mint, at an address derived from both. The CLI uses it unless you point to another one.

There are two official token programs. The original is immutable and widely used. Token Extensions, known as Token-2022, includes everything in the original plus optional features called extensions. Each mint belongs to one of the two, and most extensions can't be added after the mint is created: decide before your first command. For a refresher on the network, see the Solana glossary entry.

Step 1: install the Solana CLI and set up a devnet wallet

The official docs offer an installer that sets up Rust, the Solana CLI, Anchor, Surfpool, Node.js and Yarn on macOS, Linux or Windows. On Windows you need WSL. If you only want the CLI, Anza's installer is enough; the package it installed on October 16, 2026 already included spl-token.

sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"
export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"
solana --version
spl-token --version

Then point the CLI at devnet, create a wallet and request test SOL. According to the docs, as of October 16, 2026 the devnet faucet caps each request at 5 SOL; if it fails, use the web faucet (faucet.solana.com). Devnet SOL and tokens have no value.

solana config set --url devnet
solana-keygen new
solana address
solana airdrop 2
solana balance

A warning for when you move to mainnet: solana-keygen new stores the key in ~/.config/solana/id.json as unencrypted plain text. That's fine for testing. For the authority of a real token, it isn't: use a hardware wallet or a multisig (step 4).

Step 2: create the mint of an SPL token

With the original program, one command creates the mint. If you don't set decimals, the CLI uses 9; here we set 2, like an amount with cents. Your wallet becomes the mint authority and pays the account deposit.

spl-token create-token --decimals 2 --enable-freeze
# Address:  <MINT>   (save this address)
spl-token supply <MINT>
spl-token display <MINT>

A new mint has a supply of zero. Note --enable-freeze: without it, the mint is created with no freeze authority. Since every authority change is signed by the current authority, one that doesn't exist can't be assigned later. If you will ever need to lock accounts, enable it now.

Step 3: open a token account, mint and transfer

Your wallet needs a token account for this mint before it can hold a balance. Then you mint: the mint authority signs, and both your balance and the total supply go up.

spl-token create-account <MINT>
spl-token mint <MINT> 1000
spl-token balance <MINT>

To send tokens to another wallet, --fund-recipient creates the recipient's associated account if it doesn't exist, and you pay the deposit. With spl-token-cli 5.6.1, if the destination wallet holds no SOL, the CLI refuses to transfer and also asks for --allow-unfunded-recipient. Check the address before you add it.

spl-token transfer <MINT> 10 <DESTINATION_WALLET> --fund-recipient --allow-unfunded-recipient
spl-token accounts --owner <DESTINATION_WALLET>

A transfer moves balance between token accounts; it doesn't change the supply. To take units out of circulation, the holder burns them with spl-token burn <ACCOUNT> <AMOUNT>, which lowers both their balance and the supply. What each step costs in SOL, with the formula, is in how much it costs to create a token on Solana.

Step 4: decide the authorities (and revoke them when needed)

Authorities matter most to an issuer, and token generators explain them least. Every change is signed by the current authority, and setting one to "none" removes it for good.

• Fixed supply. If you remove the mint authority, nobody can create more units. This is irreversible.
• Freezing. The freeze authority can lock a specific account. While it's frozen, nothing can be transferred or burned from it, and it can't receive either.
• Multisig. Any authority on a mint or account can be an SPL multisig account, with up to 11 signers and an M-of-N threshold. Signers can be hardware wallets.

# mint controlled by 2 of 3 signers
spl-token create-multisig 2 <KEY_A> <KEY_B> <KEY_C>
spl-token authorize <MINT> mint <MULTISIG_ADDRESS>
spl-token mint <MINT> 1 --owner <MULTISIG_ADDRESS> 
  --multisig-signer signer-a.json --multisig-signer signer-b.json

# then: supply closed for good (2 of the 3 sign)
spl-token authorize <MINT> mint --disable --owner <MULTISIG_ADDRESS> 
  --multisig-signer signer-a.json --multisig-signer signer-b.json
spl-token display <MINT>

With a single multisig signature, minting fails; with two, it goes through. spl-token display shows the mint's actual state: supply, decimals and authorities. After --disable you'll see "Mint authority: (not set)". It's the first thing to check on any token before you integrate it.

Step 5: create the token with Token-2022 and issuer extensions

Token-2022 uses the same CLI; you name its program when you create the mint. After that, the CLI detects the program by itself. Extensions don't always combine: for example, a non-transferable token can't have transfer fees. This example combines three extensions for an issuer that only wants verified holders:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token 
  --decimals 0 
  --enable-metadata 
  --enable-freeze 
  --default-account-state frozen 
  --enable-permanent-delegate

spl-token initialize-metadata <MINT_2022> "Example Bond 2027" "EXB27" "https://example.com/exb27.json"
spl-token display <MINT_2022>

• Metadata on the mint (--enable-metadata). A token on the original program stores no name or symbol: it needs a separate account from Metaplex's Token Metadata program. In Token-2022, the name, symbol and URI live on the mint itself, and the CLI adds a "metadata pointer" that points to the mint. The URI should return a public JSON document. Anyone integrating your token should check that the mint and the metadata point to each other, so they don't accept a fake mint posing as another.
• Accounts frozen by default (--enable-freeze --default-account-state frozen). Every new account starts frozen and only works once the freeze authority thaws it. It fits onboarding each investor after KYC. If you want to relax it later, spl-token update-default-account-state <MINT_2022> initialized changes the starting state of new accounts.
• Permanent delegate (--enable-permanent-delegate). An authority that can transfer or burn from any account of the token without the holder's signature, and that the holder can't revoke. The CLI assigns it to the mint authority; you change it with spl-token authorize <MINT_2022> permanent-delegate <NEW_ADDRESS>.

This is how you onboard an investor. Minting into a frozen account fails with "Account is frozen": thaw it first.

spl-token create-account <MINT_2022>
spl-token thaw <YOUR_ACCOUNT>
spl-token mint <MINT_2022> 100

# onboard the investor after verifying their identity
spl-token create-account <MINT_2022> --owner <INVESTOR_WALLET> --fee-payer ~/.config/solana/id.json
spl-token thaw <INVESTOR_ACCOUNT>
spl-token transfer <MINT_2022> 10 <INVESTOR_WALLET> --allow-unfunded-recipient

To create another wallet's account, spl-token-cli 5.6.1 asks for --fee-payer explicitly. And if someone displays an account of a token with a permanent delegate in the CLI, the CLI itself warns them that the mint may withdraw all their funds at any time. Your documentation needs to explain that before they read it there.

With the permanent delegate, the authority burns or moves balance from the investor's account. If that account is frozen, not even the delegate can move it:

spl-token burn <INVESTOR_ACCOUNT> 1
spl-token transfer --from <INVESTOR_ACCOUNT> <MINT_2022> 2 <YOUR_ACCOUNT>   # the destination must already be thawed
spl-token freeze <INVESTOR_ACCOUNT>

Two more extensions issuers tend to weigh:

• Pausable (--enable-pause, set when the mint is created; the example mint doesn't have it). spl-token pause <PAUSABLE_MINT> halts transfers, mints and burns for the whole token; spl-token resume restarts them.
• Transfer hook (--transfer-hook <PROGRAM_ID>). Runs a program of yours on every transfer, for example to accept only allowlisted recipients. It's the most flexible option and the most expensive: you have to write, deploy and audit that program, which implements the transfer hook interface and receives the transfer's accounts as read-only, without the sender's signing privileges. It doesn't run when an account transfers to itself. If your rule is "verified investors only", accounts frozen by default already cover it with no program of your own, because a frozen account can neither send nor receive.

SPL or Token-2022: the differences that matter to an issuer

Rule of thumb: if the token needs no control beyond freezing, the original program is simpler and widely used. If you need metadata on the mint, controlled onboarding or the ability to correct balances, Token-2022 gives you that without a program of your own. The extension-by-extension comparison with the ERC-3643 standard is in Token-2022 for regulated tokens.

If the token is a security: Spain's Law 6/2023, the ERIR and MiFID II

Everything above creates a token. It doesn't decide what the token is legally. Before minting on mainnet, classify it; the MiCA / MiFID classifier gives you a first steer.

• If it's a financial instrument, MiCA doesn't apply (Art. 2(4)(a) of Regulation (EU) 2023/1114). Securities law governs: MiFID II for investment services and, in Spain, Law 6/2023. We explain it in MiCA vs MiFID II.
• Law 6/2023 allows transferable securities to be represented with distributed ledger technology (Art. 6.1), without naming any network. The law doesn't rule Solana out, but it requires the system to guarantee the integrity and immutability of the issue and to identify holders (Art. 6.5), and the network doesn't supply that on its own.
• Issue document and ERIR. The issuer prepares an issue document that identifies the entity responsible for the register (Art. 7) and appoints one or more ERIRs (Art. 8.4). It must be an entity authorized for the safekeeping and administration of financial instruments (Art. 126.a), and its duties include identifying holders and handling corporate events.
• Prospectus. A public offer of securities requires a prospectus under Regulation (EU) 2017/1129, unless an exemption applies (Art. 35.1 of Law 6/2023).
• If it's an e-money token (EMT), the issuer must be authorized as a credit institution or an electronic money institution (Art. 48 of MiCA).

Token-2022 supplies the tool, not the license. Accounts frozen by default fit a rule that only identified holders can operate, the permanent delegate is a mechanism to carry out a correction of the register, and pausing allows a suspension. Who uses them and when is set by the issue documentation, and for the investor they are a counterparty risk that must be disclosed there. Deploying on Solana doesn't make an issuance comply with Law 6/2023: the law applies to the security, the issuer and the ERIR, not to the network. We cover it in Law 6/2023 and the tokenization of securities.

How we approach it at Unknown Gravity

Unknown Gravity is a Spanish tokenization technology and blockchain infrastructure company. On a Solana token, we first review what can't be changed later: the token program, the extensions, who holds each authority and under which multisig. Then we test it on devnet and integrate it with KYC, the ERIR the issuer appoints and the issuer's platform. If the token needs custom logic, that program is audited before it reaches mainnet.

Frequently asked questions

What is Solana's token?

SOL is the network's native token: it pays fees and account deposits, and it splits into lamports (1 lamport = 0.000000001 SOL). Tokens that anyone creates with the token programs are called SPL tokens.

How much does it cost to create a token on Solana?

Very little on the network. As of October 16, 2026, the mint of an SPL token requires a deposit of 1,066,800 lamports (0.0010668 SOL) plus a 10,000-lamport fee, because the transaction carries two signatures. On the original program you don't get that deposit back, because the mint can't be closed. The real costs are development, the audit and, if it's a security, the legal work.

Can I create a Solana token for free or without coding?

On devnet, yes: test SOL is free and has no value. On mainnet you need SOL for deposits and fees. A no-code generator saves you the commands, but it doesn't decide who holds the authorities, under which multisig, or what the token is legally. For an issuer, those decisions are the work.

Can Token-2022 extensions be added to an existing token?

Generally, no. Most extensions are initialized when the mint is created and can't be added later. That's why the token's design is closed before the first command on mainnet.

How do you burn tokens on Solana?

With spl-token burn <ACCOUNT> <AMOUNT>, signed by the account holder. It lowers their balance and the mint's supply. In Token-2022, the permanent delegate can also burn from any account. A frozen account can't be burned from.

How do you create a memecoin on Solana?

With the same commands; it isn't the use case of this guide. Offering it to the public in the EU requires, unless an exemption applies, being a legal person and drawing up, notifying and publishing a white paper under MiCA (Art. 4).

Sources

• Local installation of the Solana toolchain (solana.com)
• Installing the Solana CLI and dependencies (solana.com)
• Solana CLI basics: wallets, clusters and airdrops (solana.com)
• Tokens on Solana: token programs, mints and token accounts (solana.com)
• Quickstart: create a token with the CLI (solana.com)
• Set Authority: change or revoke authorities (solana.com)
• Metaplex metadata for SPL tokens (solana.com)
• Token Extensions (Token-2022) (solana.com)
• Metadata Pointer and Token Metadata (solana.com)
• Default Account State (solana.com)
• Permanent Delegate (solana.com)
• Transfer Hook (solana.com)
• Token Program: CLI and multisig accounts (solana-program.com)
• Token-2022: extensions from the CLI (solana-program.com)
• Spain's Law 6/2023 on Securities Markets and Investment Services, consolidated text (BOE, in Spanish)
• Regulation (EU) 2023/1114 (MiCA) (EUR-Lex)

Framework verified as of October 16, 2026. Planning to issue a token on Solana and want its design reviewed before mainnet? Talk to us.