Rust Data Types for Solana: u8, u64, bool, String

Rust eliminates an entire category of bugs before your program ever reaches a validator. The type checker enforces at compile time that a u8 field never holds a negative number and a Pubkey field never holds a float. No runtime exception, no silent corruption — the program simply does not compile if the types are wrong.

This matters more for Solana than for most other environments. A deployed Solana program processes thousands of transactions per second from users who may be trying to exploit it. A type error that slips through in a dynamically typed language could drain funds. Rust refuses to let it through at all.

The second reason types matter is determinism. Every validator runs the same program on the same inputs and must produce the same result. If a type choice could produce different results on different hardware — as floats can — the network treats the transaction as invalid. Rust's numeric types are defined to be deterministic on all platforms, provided you stay in the integer world.

use solana_program::pubkey::Pubkey;

// A realistic account struct showing common type choices
pub struct TokenMint {
    pub authority: Pubkey,    // 32 bytes — who controls the mint
    pub supply: u64,          // 8 bytes  — total tokens in circulation
    pub decimals: u8,         // 1 byte   — token precision (0-9 typical)
    pub is_initialized: bool, // 1 byte   — was this account set up?
    pub freeze_authority: Option<Pubkey>, // 1 + 32 bytes
}

Unsigned integers hold only non negative values. They are the right default for any numeric field in a Solana account struct. u8 fits in 1 byte and covers 0 to 255 — the right choice for version numbers, bump seeds, and token decimal places. u32 fits in 4 bytes and covers 0 to 4.29 billion, useful for array indices and medium sized counters. u64 fits in 8 bytes and covers 0 to 18.4 quintillion — the type you will reach for on almost every numeric field that matters.

Use u128 (16 bytes) when you need to multiply two u64 values before dividing — the intermediate result can exceed u64::MAX. DeFi protocols use u128 for price accumulators and reward calculations.

Signed integers mirror the unsigned set but allow negative values. i64 is the most common: the Solana Clock sysvar exposes unix_timestamp as i64, so any timestamp field in your account struct should match that type.

// Checked arithmetic — the right way to handle balances
let balance: u64 = 1_000_000_000; // 1 SOL in lamports
let fee: u64     =         5_000; // 5000 lamports base fee

// checked_sub returns None if the result would underflow
let after_fee = balance
    .checked_sub(fee)
    .ok_or(ProgramError::InsufficientFunds)?;

// Saturating — clamp instead of panicking (useful for caps)
let max_supply: u64 = 1_000_000_000_000; // 1 trillion tokens
let new_supply = current_supply.saturating_add(mint_amount);

A bool is exactly 1 byte on chain, serialised as 1 for true and 0 for false. It is the right type for any field that represents a binary state: whether an account has been initialised, whether a feature is active, whether a position is locked.

The is_initialized field is the canonical example. Programs that do not use Anchor's discriminator system check this field before processing an instruction, to prevent initialising the same account twice. Even with Anchor, you will see bool fields for flags like is_paused or is_frozen on token or governance accounts.

One rule to keep in mind: bool is not the right type for a counter, a version, or anything that might grow beyond two states. Use u8 for that. A bool field that you later need to extend to three values requires a schema migration, which is painful on chain.

The problem is not theoretical. IEEE 754 floating point allows compliant implementations to produce slightly different results depending on the processor's handling of denormal numbers and extended precision modes. A calculation that produces 1.00000000000001 on one processor might produce 0.99999999999999 on another. Both results are valid floats. The difference is a single bit.

For Solana, that single bit is catastrophic. The consensus mechanism requires every validator to produce the same output from the same input. A computation that diverges by even one bit between two validators is treated as a fault. Your transaction gets rejected on mainnet.

// Why f32/f64 is dangerous in Solana (do NOT use this pattern)
// pub fn bad_price_calc(amount: f64, price: f64) -> f64 {
//     amount * price  // Different CPUs may round differently!
//                     // Validators can disagree → runtime panic
// }

// The correct approach: integer math with explicit scale
pub fn price_in_lamports(amount_tokens: u64, price_per_token: u64) -> u64 {
    // Both values are already scaled integers (e.g. 1000 = $10.00 with 2 decimals)
    amount_tokens
        .checked_mul(price_per_token)
        .and_then(|v| v.checked_div(100)) // de-scale the price
        .unwrap_or(0)
}

String is heap allocated and owned — it carries its data with it wherever it goes and frees it when it goes out of scope. &str is a borrowed reference to a string slice that lives somewhere else, either inside a String or in program memory. Your account structs almost always use String; instruction handler functions often accept &str for parameters where you want to borrow without taking ownership.

On chain, both end up identical: Borsh writes a 4 byte little endian integer containing the string length, followed by the raw UTF-8 bytes. A 5 character string like hello occupies 9 bytes: 4 for the length prefix and 5 for the characters.

The critical constraint: you must cap string length before allocating the account. On chain, an account's data field has a fixed size set at creation time. A string that grows beyond the initial allocation would require closing and recreating the account, which is expensive. Anchor enforces the limit at the type level with #[max_len(N)]. If a user passes a string longer than N bytes, the instruction fails before any state changes.

For context on how strings and other fields combine inside a struct, the Rust Structs in Solana guide walks through the full space calculation step by step.

Pubkey is a newtype wrapper around [u8; 32]. Under the hood it is simply 32 bytes — the output of the Ed25519 elliptic curve algorithm that Solana uses for all signing. Import it from solana_program::pubkey::Pubkey (or from anchor_lang::prelude::* if you are using Anchor).

Because Pubkey implements Copy, you can assign it to variables and pass it to functions without calling .clone(). This is why you see ctx.accounts.user.key() passed directly into struct fields without any ownership ceremony — the value is copied.

Program Derived Addresses (PDAs) use Pubkey::find_program_address to derive a deterministic address from seeds and your program ID. PDAs are intentionally off the Ed25519 curve, which means no private key can sign for them — only your program can. This is the mechanism behind every vault, escrow, and treasury on Solana.

// Working with Pubkey
use solana_program::pubkey::Pubkey;
use std::str::FromStr;

// Hardcode a known address (e.g., USDC mint)
let usdc_mint = Pubkey::from_str("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v")
    .expect("valid base58");

// The zero address — all 1s (System Program)
let system_program = Pubkey::default();

// Derive a PDA using seeds
let seeds = &[b"vault", authority.as_ref()];
let (vault_pda, bump) = Pubkey::find_program_address(seeds, &program_id);

If you are still building intuition around ownership and why Copy types behave differently from String, the Rust Ownership for Solana Developers guide covers the ownership model with Solana examples throughout.

For the full picture of how these types fit inside an account struct, including how Anchor derives the total space, read the What Is Anchor? guide, which covers account initialisation and the InitSpace derive macro in detail.

If you are building a production Solana program and want an experienced team to review your account model and type choices, the blockchain development service covers program design, auditing, and mainnet deployment.