7. Tokens, NFTs, and DeFi

Tokens are where Solana’s account model becomes concrete. A token is not just a number beside a wallet address. It is a relationship among a Token Program, a mint account, and one or more token accounts.

Build the token picture

Token Program = rules for mint, transfer, burn, freeze, and authority
Mint Account   = identity and global configuration of one token
Token Account  = balance of one mint under one authority
ATA            = canonical token account derived for authority + mint

This differs from the typical ERC-20 model. A new Solana token normally uses a shared Token Program rather than deploying a new custom program for each mint.

Mint account: what asset is this?

A mint account records properties such as:

• total supply;
• decimal precision;
• mint authority, if additional units can be created;
• freeze authority, if configured;
• initialization and extension data.

The mint address is the identifier users commonly call a token address. Two tokens with the same display name can have different mint addresses. Applications must verify the expected mint, not the symbol alone.

Token account: who controls this balance?

A token account records one balance for one mint. It includes the mint, token authority, raw integer amount, and optional delegate or state information.

A token account has two ownership ideas:

base account owner -> Token Program
inside token data authority -> wallet or PDA allowed to act

The distinction explains how an application vault works. The Token Program owns the account data format, while an application PDA authorizes transfers under program rules.

Associated Token Account

An ATA is a deterministic token account derived from an authority and mint under the relevant token-program rules. It gives wallets a conventional receiving address.

A wallet can still control multiple token accounts for one mint. Indexers and portfolio applications may need to aggregate balances instead of assuming exactly one account.

Raw amount and decimals

On-chain balances are integers.

raw amount: 1,234,567
decimals: 6
display amount: 1.234567

Never use ordinary binary floating point for financial accounting. Keep raw integer units or use a decimal/big-number library. Read decimals from the verified mint.

Follow a token transfer

Alice sends Bob 5 units of a six-decimal token.

1. The client verifies the expected mint and Token Program.
2. The client finds Alice’s source token account.
3. The client derives or creates Bob’s ATA if needed.
4. The transaction adds a Token Program transfer instruction for 5_000_000 raw units.
5. Alice signs as the source authority and possibly fee payer.
6. The Token Program verifies mint, authority, balances, account state, and amount.
7. Source and destination token-account balances change atomically.

No token object moves. Two account amounts are updated under Token Program rules.

Token-2022 changes the assumptions

Solana has the original Token Program and a Token Extension Program commonly called Token-2022. Extensions can add behavior and account data.

An integration must identify:

• which Token Program owns the mint;
• which extensions are active;
• whether transfers require additional accounts or behavior;
• whether the wallet, DEX, custody system, and indexer support them.

Do not treat every token as basic

Fail closed when a mint uses an extension the application does not understand. Silent compatibility assumptions are dangerous in payments and DeFi.

NFTs add metadata and authenticity questions

An NFT commonly combines a mint, a holder token account, metadata accounts under an ecosystem standard, collection information, and off-chain JSON or media.

A mint with supply one is not sufficient proof of authenticity. Verify:

• exact mint address;
• metadata program and account derivation;
• verified collection relationship;
• current authorities and programmable rules;
• off-chain content integrity and availability.

An image URL is display data, not ownership proof.

Compressed assets separate proof from indexing

Compressed asset designs commit many assets into compact cryptographic structures. Indexers make those assets searchable, while proofs connect an indexed record to the on-chain commitment.

Keep two questions separate:

1. What does the indexer report?
2. What proof can the application verify against on-chain state?

DeFi is account composition

A swap is a useful example:

Alice source token account
  ↓
Swap Program validates pool, mints, price, and slippage
  ↓ CPI
Token Program moves input to pool vault PDA
  ↓
Swap Program computes output
  ↓ CPI
Token Program moves output from vault to Alice destination account

The transaction may include pool state, vaults, mint accounts, token accounts, oracle data, programs, and lookup tables. Every writable account affects scheduling, and every external program adds trust and failure assumptions.

Oracle data requires policy

An on-chain number is not automatically a safe price. Verify:

• expected oracle program and feed address;
• asset pair and denomination;
• publication slot or timestamp freshness;
• confidence interval and status;
• fallback behavior;
• suitability for the value at risk.

A spot AMM price can be moved during a short window. Financial protocols need an explicit manipulation-resistance model.

Integration risk checklist

• fake mint with a familiar symbol;
• wrong Token Program;
• unsupported Token-2022 extension;
• stale or manipulated oracle;
• decimal and rounding error;
• slippage beyond user approval;
• malicious or substituted CPI program;
• incorrect PDA vault authority;
• shared writable-state congestion;
• upgrade-authority risk in dependencies;
• stale RPC or indexer data;
• duplicate off-chain fulfillment.

Finish the mental model

Return to the opening sentence:

A signed transaction asks programs to read or change accounts. Validators execute the request and agree on the resulting state.

For a token transfer:

• the signature belongs to the token authority;
• the transaction contains a Token Program instruction;
• the program supplies token rules;
• the accounts store the mint and balances;
• the runtime enforces privileges and compute limits;
• the validators agree to keep the resulting state.

If you can explain that flow, you understand the foundation of Solana.

Continue from here

Build one Devnet project that creates a user PDA, stores a bounded profile, and reads it from a TypeScript client. Then add a token account only after the ownership and authority checks are clear.

Return to Solana, from first principles to review the full learning path.