Samuel Akoji

Posted on May 19

Creating a Solana Token Is Like Building a Rewards System Except You Don't Write the Backend

#100daysofsolana #blockchain #web3

Every App Has a Credits System

Loyalty points. In-game currency. Reward tokens. Internal credits. If you've built any kind of consumer Web2 app, you've probably built some version of this: users accumulate a balance of something, they can spend it, and your database is the authoritative ledger.

Day 29 of 100 Days of Solana is about building the exact same thing except on Solana, you don't write the backend. It already exists. You just configure it and plug in.

Let me show you how the concepts map.

The Web2 Version

In a typical Web2 rewards system, you'd have something like:

-- The currency definition
CREATE TABLE token_types (
  id UUID PRIMARY KEY,
  name VARCHAR,
  symbol VARCHAR,
  decimals INT,
  total_supply BIGINT,
  issuer_id UUID REFERENCES users(id)
);

-- User balances
CREATE TABLE token_accounts (
  id UUID PRIMARY KEY,
  token_type_id UUID REFERENCES token_types(id),
  user_id UUID REFERENCES users(id),
  balance BIGINT
);

Your application server handles all the logic: validating that the issuer is authorized to mint, checking that balances don't go negative on transfers, enforcing the rules you define.

The Solana Version

On Solana, the same structure exists but it's all on-chain:

token_types → Token Mint Account

The mint account is your token definition. It stores:

Total supply
Decimal places
Mint authority (who can create more tokens)
Freeze authority (who can freeze accounts)

Create it with one CLI command:

spl-token create-token
# Returns: your mint address (the "id" of your token type)

token_accounts → Token Account

Each user's balance lives in a separate token account one per token type per wallet. It stores:

Which mint it belongs to
Which wallet owns it
The current balance

spl-token create-account <MINT_ADDRESS>
# Returns: your token account address

Your application server → The SPL Token Program

This is the key shift. In Web2, you write the business logic. On Solana, the Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) is a shared, audited, already-deployed program that handles all of it:

Only the mint authority can mint new tokens ✓
Balances can't go negative ✓
Only the account owner can transfer tokens ✓
Frozen accounts can't be transferred ✓

You don't write any of this. You invoke the Token Program's instructions, and it enforces the rules.

Minting Is Just a Database Insert

In Web2:

await db.query(
  'UPDATE token_accounts SET balance = balance + $1 WHERE id = $2',
  [100, tokenAccountId]
);
await db.query(
  'UPDATE token_types SET total_supply = total_supply + $1 WHERE id = $2',
  [100, tokenTypeId]
);

On Solana:

spl-token mint <MINT_ADDRESS> 100

One command. The Token Program handles both the balance update and the supply update atomically just like your database transaction would.

The difference: your Web2 database trusts your application server. Solana's on-chain accounts trust the Token Program. And the Token Program checks that whoever sent this transaction is actually the mint authority before allowing it.

The Separation That Changes Everything

The biggest mental shift from Web2 to Solana tokens is the separation between the token definition and the token balance.

In Web2, you might store both in the same table, or at least in the same database under the same access control. A user's "account" and their "balance" are tightly coupled.

On Solana, they're always separate:

The mint defines the token (one account, exists once)
Token accounts hold balances (one per wallet per token type)

This means:

The mint's rules can change (if you update the authority) without touching any user balances
User balances are visible to anyone the blockchain is public
Closing an empty token account returns the rent deposit to the user (about 0.002 SOL)

Why This Model Wins for Public Digital Assets

In Web2, your credits system is only as trustworthy as you are. Users have to trust that you won't manipulate the database, arbitrarily inflate supply, or freeze their accounts without notice.

On Solana, the rules are enforced by code that anyone can read and verify. If you renounce your mint authority (set it to null), no new tokens can ever be created and this is verifiable by anyone looking at the mint account in a block explorer. The supply is permanently capped by cryptographic enforcement, not by your promise.

For internal company credits, this might not matter. For a public token that real users hold real value in, it matters enormously.

What You Build in One CLI Session

# Create the token definition
spl-token create-token
# → returns MINT_ADDRESS

# Create your balance account  
spl-token create-account MINT_ADDRESS
# → returns TOKEN_ACCOUNT_ADDRESS

# Mint 100 tokens to yourself
spl-token mint MINT_ADDRESS 100

# Verify
spl-token balance MINT_ADDRESS
# → 100

Four commands. You now have a functioning token on a live blockchain. No smart contract written, no backend deployed, no database configured.

The infrastructure was already there. You just used it.

DEV Community