Creating a Solana Token Is Easy. Here's What I'd Check Before Doing It

Creating a token on Solana sounds like a bigger engineering task than it actually is.

If you're coming from Ethereum, you might assume you'll need to write a smart contract, configure Hardhat, deploy it, and verify everything afterward. That's how a lot of ERC-20 projects start.

Solana works a little differently.

For a basic fungible token, you don't need to deploy a custom smart contract. The SPL Token Program already handles most of the functionality. You're essentially creating a new mint account and configuring how that token should behave.

The creation part is fairly straightforward. The decisions you make before creating it are where things get interesting.

First, what kind of token are you creating?

Solana has two token programs worth knowing about.

The original SPL Token Program handles the usual stuff: token supply, transfers, minting, and account freezing. For a simple community token, app reward token, or experimental project, it's often all you need.

Then there's Token-2022, also called Token Extensions.

Token-2022 adds functionality such as transfer fees, non-transferable tokens, and other extensions. These can be useful, but they also introduce compatibility considerations.

Personally, I wouldn't choose Token-2022 just because it has more features. I'd start with the regular SPL Token Program unless the application actually needs an extension.

Not every wallet, DEX, or third-party integration supports every extension equally well. That's something you want to discover before launch, not afterward.

The three settings I'd pay attention to

Let's say you're creating a token for a small application. Maybe users earn points for contributing, and you eventually want those points to be transferable.

You need to decide on the supply, the decimal precision, and who controls the token.

Supply and decimals

Suppose you create a token with an initial supply of 1,000,000 and 9 decimals.

That means each token can be divided into a billion smaller units. It doesn't mean you've created one billion tokens.

This distinction matters when working with APIs, because token amounts are generally represented in base units rather than the human-readable values displayed in wallets.

Mint authority

This determines whether someone can create additional tokens after the initial supply is issued.

If your application distributes new rewards every month, keeping mint authority might make sense.

If you're creating a token with a fixed supply, you can revoke that authority once the intended supply has been minted.

The important detail: revoking mint authority is irreversible.

Freeze authority

A freeze authority can prevent individual token accounts from transferring their tokens.

There are legitimate use cases for it, but it also gives the authority holder significant control over token holders.

For a community token, I'd think carefully about whether that control is actually necessary.

There's also metadata update authority, which determines whether certain token information can be changed later.

I wouldn't revoke everything automatically. I'd decide what the application needs first, then remove permissions that have no reason to exist.

Do you actually need to write code to create the token?

Not necessarily.

If you're building a token creation service or need to generate tokens programmatically, using the Solana SDK or CLI makes sense. You get more control and can incorporate mint creation into your own workflow.

For a one-off token, though, I'm not convinced there's much value in writing and maintaining a deployment script unless you specifically want to learn how the instructions work.

A browser-based creator is another option.

For example, PandaTool's Solana token creator provides a wallet-connected interface for configuring and creating a token.

The basic workflow is simple: connect a wallet such as Phantom, enter the token name, symbol, decimals, initial supply, and logo, review the configuration and fees, then approve the transaction.

You get a mint address after creation.

That's useful when you need a standard token without turning token deployment into a separate development task. There are service fees involved, though, so I'd compare the cost with using the CLI directly.

And regardless of which method you choose, I'd still verify the result on-chain.

A successful-looking interface is not a substitute for checking what was actually created.

A quick way to verify your token with TypeScript

Once you have the mint address, you can inspect the token using @solana/web3.js and @solana/spl-token.

Install the dependencies:

npm install @solana/web3.js @solana/spl-token
npm install -D tsx

Then create a file called inspect-mint.ts:

import {
  Connection,
  PublicKey,
  clusterApiUrl,
} from "@solana/web3.js";

import {
  getMint,
  TOKEN_PROGRAM_ID,
  TOKEN_2022_PROGRAM_ID,
} from "@solana/spl-token";

const connection = new Connection(
  clusterApiUrl("mainnet-beta"),
  "confirmed"
);

async function inspectMint(address: string) {
  const mintAddress = new PublicKey(address);
  const account = await connection.getAccountInfo(mintAddress);

  if (!account) {
    throw new Error("Mint account not found");
  }

  const programId = account.owner;

  if (
    !programId.equals(TOKEN_PROGRAM_ID) &&
    !programId.equals(TOKEN_2022_PROGRAM_ID)
  ) {
    throw new Error("Not a supported SPL token mint");
  }

  const mint = await getMint(
    connection,
    mintAddress,
    "confirmed",
    programId
  );

  console.log({
    program: programId.equals(TOKEN_2022_PROGRAM_ID)
      ? "Token-2022"
      : "SPL Token",
    supplyBaseUnits: mint.supply.toString(),
    decimals: mint.decimals,
    mintAuthority: mint.mintAuthority?.toBase58() ?? null,
    freezeAuthority: mint.freezeAuthority?.toBase58() ?? null,
  });
}

inspectMint(process.argv[2]).catch(console.error);

Run it with:

npx tsx inspect-mint.ts YOUR_MINT_ADDRESS

This gives you a few things worth checking.

Does the token use the program you expected? Are the decimals correct? Is the supply what you intended, remembering that the value returned here is in base units?

More importantly, are the mint and freeze authorities still active?

If an authority is null, that authority has been removed.

You can also inspect the same mint address using Solana Explorer.

For production applications, I'd use a dedicated RPC endpoint rather than relying on the public endpoint for repeated requests.

Creating a token doesn't mean it's ready to trade

This is another distinction that's easy to miss.

Creating an SPL token doesn't automatically give it a market price, liquidity pool, or exchange listing.

If you want the token to be tradable on a DEX, you'll need to think about liquidity separately. You may also need to distribute tokens, configure application integrations, and verify that wallets display the token metadata correctly.

And if your token is purely an internal reward or access mechanism, you might not need a liquidity pool at all.

There's no reason every token has to become a trading pair.

What I'd do for a small project

If I were adding a token to a side project, I'd keep the first version pretty boring.

Start with the regular SPL Token Program. Decide whether the supply should ever increase. Choose the required authorities and make sure they're controlled by the right wallet.

Test the token's behavior in a development environment where possible. For a mainnet launch, review the wallet transaction and costs before signing.

Then verify the mint address and permissions independently.

Whether the mint was created with a script, the Solana CLI, or a tool like PandaTool wouldn't really change that checklist.

The deployment method is just one part of the process. The token's on-chain configuration is what matters afterward.

I'm curious how other Solana developers handle this. Do you usually create tokens directly through the SDK or CLI, or use an existing interface for simple deployments?

And for a small project, would you keep mint authority initially or revoke it from day one?