FAQs

Everything is an account; programs execute against accounts named in atomic transactions, funded in lamports, authorized by signatures or PDAs, on one cluster, until your chosen commitment says you can trust the result.

It unifies wallets, programs, mints, and data under one load/store and ownership model, so fees, rent, locks, and RPC reads all use the same vocabulary.

A program account is marked executable and holds bytecode the loader runs; a data account holds application bytes interpreted by its owner program and is not executed as code.

Only the program that owns the account may modify its data (subject to runtime rules); other programs need CPI into the owner or must hold lamports/signers for operations the system allows.

All of its instructions succeed or none of their effects commit; there is no partial application of a failed transaction's instruction list.

The runtime uses the list for locking, signature checks, and Sealevel scheduling; undeclared accounts cannot be loaded mid-flight the way some VMs allow implicit storage access.

Transactions that do not share conflicting account locks - especially overlapping writable accounts - can execute concurrently; conflicting ones are ordered so writes stay consistent.

A lamport is the base integer unit (1 SOL = 1e9 lamports); the chain and APIs speak integers so amounts never depend on floating-point rounding.

A data-size-based minimum lamport balance that keeps an account alive without ongoing rent collection under current economics - fund it at creation via the rent-exempt minimum.

Keypairs prove human or server authority with Ed25519 signatures; PDAs are program-controlled addresses without secrets, authorized only when the owning program supplies the correct seeds at CPI time.

Almost always a cluster mismatch - CLI on devnet, explorer on mainnet-beta, or an RPC URL pointing at a different network than the wallet.

Many product actions use confirmed for responsive UX; use finalized before irreversible external effects, and treat processed as optimistic only.

This page is the full builder model (accounts through confirmation); the EVM page is a focused porting contrast for engineers who already think in contracts-with-storage.

No - Anchor 0.32.1 and @solana/kit 7.0.0 are ergonomic layers over the same accounts, instructions, metas, and RPC/commitment surfaces described here.

Skim Solana Basics for concrete examples, then deepen currency, keys, clusters, and transaction flow via the Related links below as you build.

1,000,000,000 (10^9). This is fixed and never changes.

Deterministic execution across all validators requires exact arithmetic. Floating point varies by hardware; u64 integers do not.

1 lamport. In practice, transaction fees (5,000 lamports per signature by default) make sub-lamport transfers meaningless.

Lamports. Divide by 1e9 only for display - never for on-chain instructions.

1 microlamport = 0.000001 lamports. Priority fees are priced in microlamports per compute unit via the Compute Budget Program.

Theoretically at ~18.4 billion SOL total supply it is not a practical concern, but program logic should still use checked arithmetic.

Based on account data size in bytes. RPC getMinimumBalanceForRentExemption(dataSize) returns the exact lamport deposit required.

Store lamports as integers (or strings for very large values). Convert to SOL only in the presentation layer.

The System Program rejects zero-lamport transfers. Use a meaningful minimum or skip the instruction.

No. SPL tokens use the mint's decimals field. A USDC amount of 1_000_000 means 1 USDC (6 decimals), not lamports.

Divide bigint lamports into whole and fractional parts with string math, or use a library. Avoid Number(lamports) for values you will re-submit on-chain.

Devnet is for application developers. Testnet is for validator and protocol testing. Devnet is more stable for day-to-day app work.

Yes - keypairs are cluster-agnostic. But account state (balances, programs) is per-cluster.

solana airdrop 2

Limited to a few SOL per request. Use web faucets if rate-limited.

Public: https://api.mainnet-beta.solana.com. Production apps should use a dedicated provider (Helius, Triton, QuickNode, etc.).

Only if you omit --reset. With --reset, the ledger starts fresh each time.

Yes, with solana-test-validator --clone <PUBKEY>. Useful for testing against real program deployments.

Recent blockhashes are cluster-specific. Fetch a new blockhash from the target cluster's RPC.

No. It has no market value and can be minted freely via airdrops.

Public clusters track stable Agave releases. Pin your local tooling to Agave 4.1.1 to match this documentation.

Localnet (Surfpool or solana-test-validator) is faster and free of rate limits. Use devnet only for occasional integration smoke tests.

Pass ?cluster=devnet or ?cluster=mainnet-beta in the URL. Default is mainnet-beta.

Just not for production. api.devnet.solana.com is a legitimate, free way to learn and prototype. The problem is only that it's shared by everyone and has no uptime guarantee - fine for a tutorial, risky for anything real users depend on.

No. Both offer free tiers that are more generous than the public endpoint and are enough for development and small projects. You only need to pay once your traffic outgrows the free tier.

Remote Procedure Call. It's a general programming pattern - not Solana-specific - for calling a function that runs on a different machine as if it were local.

You can mix providers freely per cluster or per environment. Nothing in the Solana protocol ties you to a single provider - you're just choosing which company's servers answer your RPC calls.

It's functionality a provider adds on top of raw Solana RPC - Helius's DAS API for NFT/token data is one example. You don't need one for basic reads and transactions; they matter once you're building features raw RPC makes slow or awkward, like querying every NFT a wallet owns.

Because they're different clusters with different data. A devnet URL only ever sees devnet accounts and transactions; you need a mainnet-beta URL (and usually a separate key) once you deploy for real.

Related but distinct. The HTTPS RPC endpoint handles one-off requests (get a balance, send a transaction). The websocket endpoint (wss://...) handles subscriptions - your code stays connected and receives pushed updates, like "this account just changed."

Requests start returning errors (commonly HTTP 429) instead of data. Most SDKs don't retry automatically, so your application code needs to handle that failure - back off and retry, or surface an error to the user.

Only if the URL and key are meant to be public-facing - check your provider's docs, since some plans support domain-restricted keys specifically for this. Otherwise, keep the URL server-side and have your backend proxy RPC calls, the same way you'd protect any other API key.

Yes - Triton and others also serve the Solana ecosystem. Helius and QuickNode are covered here because they're the two most commonly reached for by developers new to choosing a provider, not because they're the only options.

No, as long as you're reading the URL from configuration rather than hardcoding it (Step 5 above). Swapping providers becomes a one-line change to an environment variable.

A slot is a time window (~400 ms target) during which one validator is designated leader and may produce a block.

Approximately 2 days. An epoch contains ~432,000 slots at the target 400 ms slot time.

No block is produced for that slot. The slot number still advances. Transactions wait for the next available leader.

No. Slot increments every ~400 ms regardless of blocks. Block height increments only when a block is actually produced.

TowerBFT requires a supermajority of stake to vote on a fork. This typically takes ~32 slots of voting.

Yes, via the Clock sysvar: Clock::get()?.slot.

At each epoch boundary. The new schedule is computed from the stake distribution at that point.

Same target (400 ms), but devnet has fewer validators and more skips. Do not use devnet for timing benchmarks.

Rewards are credited per epoch based on stake weight and inflation rate. New delegations have a warmup period measured in epochs.

The number of slots elapsed since the current epoch started. Range: 0 to slotsPerEpoch - 1.

Only for rough estimates. Use confirmed/finalized commitment for user-facing "transaction complete" states.

Ed25519. Public keys are 32 bytes, base58-encoded for display.

A JSON array of 64 bytes: the 32-byte secret seed concatenated with the 32-byte public key.

Yes. The terms are interchangeable - the base58-encoded 32-byte Ed25519 public key.

No. Each valid keypair maps to exactly one public key/address.

An address derived from seeds and a program ID. It has no private key - the program signs for it via invoke_signed.

Up to 16 signatures per transaction in the current format. The fee payer is always one of them.

No. Only the source account's authority (and fee payer) must sign.

No. The secret key cannot be derived from the public key (one-way function).

11111111111111111111111111111111 - handles account creation and SOL transfers.

No. Use dedicated service keypairs with minimal funded balances and strict access controls.

The private key never leaves the device. The app sends the transaction message; the device returns the signature.

In separate accounts that your program owns. The program itself holds only executable bytecode.

PDAs derived from seeds (e.g., [b"user", user_pubkey]). Each entry is its own account.

The signer account passed to your instruction. Validate it with Signer<'info> or has_one constraints.

Only the owner program can write data. Other programs can read if the account is passed and marked writable by the owner program via CPI.

Sealevel uses the account list to schedule parallel execution and enforce lock rules before execution begins.

Program accounts hold lamports for rent but application token/SOL balances live in user/token accounts, not in the program.

Solana uses the BPF Upgradeable Loader - a program buffer and program data account. Authority can deploy new bytecode.

SPL Token program with mint and token accounts. Not a per-token contract.

Similar concept. CU measures on-chain compute. Fees include base signature cost plus priority fee for CU price.

Technically yes but wasteful. Use one program with many data accounts (PDAs) per user instead.

Programs emit logs via msg! and Anchor emit!. Clients parse transaction logs - there is no persistent log store on-chain.

No. Use an init instruction that creates and configures accounts on first use.

The RPC forwards your transaction to leaders via Gulf Stream. It is not yet confirmed - only submitted.

Approximately 60-90 seconds (about 150 slots). After expiry, the transaction is rejected even if re-submitted.

Dropped: never executed in a block. Rejected: executed but the program returned an error - it is on-chain with a failed status.

TowerBFT requires sufficient validator votes across multiple slots to root a block. This takes roughly 32 slots.

Priority fees increase scheduling priority. Jito bundles help during MEV-heavy periods. You cannot skip the voting process.

The RPC executes your transaction against current state before broadcasting. Catches most errors early.

It returns a signature immediately. Confirmation is asynchronous - poll or subscribe separately.

A protocol that forwards transactions directly to upcoming block leaders instead of using a traditional mempool.

Yes. If any instruction fails, the entire transaction is rolled back (unless a program catches and handles CPI errors).

No. All instructions succeed or none of the state changes commit.

confirmed for most payments. finalized for high-value or irreversible actions.

Use https://explorer.solana.com/tx/<SIGNATURE>?cluster=devnet and inspect logs, CU, and instruction breakdown.

Many wallets span categories - Phantom, Solflare, and Backpack all ship as both a browser extension and a mobile app. The categories describe capability, not a requirement to install five different products.

Neither is inherently safer - both store a private key on a general-purpose, internet-connected computer. A CLI keypair file is arguably more exposed since it has no popup confirmation step; either one is unsuitable for large amounts compared to a hardware wallet.

Hardware wallets are the most common form of cold wallet - a dedicated device that never exposes the private key to your computer. "Cold" more broadly just means offline; a well-managed paper wallet is also cold, just without a device's convenience.

An on-chain account that requires signatures from multiple approved keys, not just one, before any transaction it controls is considered valid.

Because trusting one person's wallet means trusting that their device is never compromised, they never leave the project, and they never make a mistake alone. A multisig spreads that risk across several independent signers.

It's the most widely used Solana-native option, but not the only approach - SPL Governance/Realms handles treasury control through DAO voting, and the SPL Token program supports setting a token's mint or freeze authority to a multisig account directly without any third-party product.

Yes - this is one of the most common uses. Setting a program's upgrade authority to a multisig vault means no single team member can push an upgrade unilaterally.

Nothing breaks immediately as long as the remaining signers still meet the threshold (e.g. 2 of 3 still available in a 2-of-3 setup). Losing enough signers to fall below the threshold, however, can permanently lock the account - choose the threshold and signer count carefully.

No. Multisigs add real friction to every transaction and exist specifically to remove a single point of failure across multiple people. For funds only you control, a well-secured hardware wallet is the appropriate step up from a hot wallet.

Not really - this guide focuses on non-custodial wallets, where you hold the key. A custodial exchange balance is controlled by the exchange's own infrastructure, which may include its own internal multisig, but you never hold a private key for it yourself.

Solscan is the most common day-to-day default, similar to how Etherscan is used on Ethereum. The official Explorer is a good ground-truth fallback since the Solana Foundation runs it directly.

Explorers run independent indexers with different processing speeds and, sometimes, different retention windows. A short delay or an older transaction can appear on one before (or instead of) another.

Not for browsing the website. Several - Solscan and Orb among them - offer optional paid or free-tier APIs if you want to query their indexed data programmatically instead of using raw RPC.

An RPC provider (see RPC Providers) is infrastructure your code talks to directly. An explorer is a website built on top of RPC data for humans to browse - you don't call an explorer from your application code.

Solscan and similar general-purpose explorers do show basic NFT metadata and history. For deep rarity traits and marketplace listings, a dedicated NFT marketplace or analytics tool is often more thorough.

Transactions Per Second - a network-level throughput metric. General-purpose explorers like SolanaFM surface it on their network stats dashboards.

Orb is a block explorer product built by Helius, the RPC provider covered in RPC Providers. They're related products from the same company, not the same tool.

It means a validator has stopped voting on the chain - a health signal for stakers and node operators, surfaced on tools like Solana Beach.

Treat it as a helpful starting point, not a verified fact - AI summaries (like Orb's) are generated from the same decoded data you could read yourself, and can still misinterpret an unusual instruction.

No. Public explorers only index public clusters (mainnet-beta, devnet, testnet). For solana-test-validator, use CLI tools like solana confirm -v and solana logs instead, as covered in Wallets & Explorers.

Use a specialized tool like the Jito MEV Explorer, which is built specifically for bundle and searcher activity that general-purpose explorers don't surface in detail.

https://explorer.solana.com - maintained by the Solana Foundation. Supports mainnet-beta, devnet, and testnet.

https://explorer.solana.com/tx/<SIGNATURE>?cluster=devnet

solana airdrop 2

Or use https://faucet.solana.com when CLI is rate-limited.

Phantom, Solflare, Backpack, Ledger (hardware), and CLI keypair files for development.

Open the transaction, scroll to Program Logs. Each msg! and emit! line appears in execution order.

Yes. Open an address page and view the raw data tab. Anchor programs show Borsh-encoded bytes unless an IDL is verified.

Total CU used by all instructions. Compare against your requested CU limit to spot budget issues.

On the program's explorer page, check Program Account → Upgrade Authority field.

No. Use CLI (solana logs, solana confirm -v) or a local block explorer setup.

Use @wallet-ui/react or wallet-adapter patterns with @solana/kit 7.0.0 for transaction building. Match RPC to wallet network.

The transaction landed but a program returned an error. Read the logs for the exact error code and line.

If published on-chain or verified via Anchor's IDL account, explorer may decode instruction names. Otherwise you see raw bytes.

State lives in accounts, not inside programs. Design account layouts before writing instruction logic.

Localnet. Surfpool 0.12.0 or solana-test-validator avoids rate limits and cluster instability.

JavaScript number cannot represent all lamport values exactly. Use bigint end-to-end.

confirmed for display. Consider finalized before releasing funds from escrow.

Explorer link with ?cluster= param matching the network where the tx was sent.

Before designing any "one contract stores everything" pattern. Solana needs account-per-entity design.

Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, @solana/kit 7.0.0 per this site's manifest.

No. Transactions can be dropped or reordered at processed. Wait for confirmed minimum.

solana config get, solana balance, solana airdrop 1, send 0.001 SOL, confirm in explorer with correct cluster param.

No. Use @solana/kit 7.0.0 for new TypeScript clients. web3.js v1 is legacy.

Slots (~400 ms) drive block production. User confirmation should track commitment levels, not slot counts.