Solana is a public blockchain for transferring assets and running programs that share account state. SOL pays network fees and participates in staking. Wallets provide access, validators operate the network, and applications use its programs to offer payments, markets and other services.
A shared network for assets and applications
Imagine receiving USDC from a customer, exchanging some of it for SOL and delegating part of that SOL to a validator. These are different products and actions, but compatible applications can use the same underlying assets and account system. Solana provides the shared network on which their program instructions execute.
Solana is a layer-1 blockchain: it has its own validators, consensus and native asset. An application deployed on it can define additional rules, such as how a pool quotes a trade or how a lending position records debt. Other applications can read the resulting public state and build compatible services.
The network is accessible through software interfaces. You might use a browser wallet, a mobile payment app or code that calls RPC. Each is an entry point into the same selected cluster. Mainnet holds production assets; devnet is a separate environment used for development. Selecting devnet does not reveal a test copy of your mainnet funds.
The distinction between network and interface is practical. If one site is unavailable, the program's state may still be accessible through another compatible client. A product that relies on a private server can have additional dependencies, so inspect the whole workflow when choosing how to use it.
SOL pays for network activity and supports staking
SOL is the native asset. Solana records its smallest units as lamports: 1 SOL equals 1,000,000,000 lamports. A wallet normally converts those integer amounts into a readable decimal balance.
Every transaction names a fee payer. That payer provides the SOL for the network fee. An application can sponsor this cost, so the person approving an action and the person paying its fee can be different parties. If you hold USDC but an ordinary transfer reports insufficient SOL, the missing amount can be the fee or funding for a required account.
Some new accounts need a minimum balance to support stored data. That balance remains associated with the account and differs from a fee paid for processing a transaction. The account's program determines when and how it can close and where remaining lamports go.
Native staking assigns SOL held in a stake account to a validator. Effective delegated stake participates in the network's proof-of-stake system and can earn rewards. The stake account's authorities control management and withdrawal. Delegating does not send those authorities to the validator.
These mechanisms explain why SOL is used. Its market price is a separate exchange rate determined by markets. Receiving more SOL through rewards and gaining value in a national currency are different calculations.
Meet the participants behind one action
The user and wallet choose and authorise an action. The wallet prepares or receives a transaction, displays relevant information and asks the signing system to approve its message.
The application and program define the requested operation. A swap website might request a call to a trading program. The program checks its supplied accounts and runs the relevant rules. Mutable balances and positions live in accounts.
An RPC service provides reads, simulations and transaction submission. An indexer can organise raw network activity into a searchable history or an asset view. These services help the application observe the network; their responses have coverage and freshness properties.
Validators process network work and participate in consensus. Delegators assign stake through stake accounts. Validator operators maintain the infrastructure, while client developers maintain implementations of the protocol.
Follow the flow rather than assuming one company operates every part. An error in a website, a delayed data response and a failed program instruction occur at different layers and call for different fixes.
Receiving and using an asset
Walk through a first token payment
Suppose a friend sends you 20 USDC on Solana. You first provide the receiving details for the correct network. Your wallet helps identify or create the token account that holds that mint under your authority. Somebody pays the sending transaction's network fee and any required setup costs.
After execution, the relevant token account contains the received amount. The wallet reads that account and displays USDC. The asset's identity comes from its mint, not from the displayed ticker. A transaction signature lets you inspect what actually moved.
Next, you request a swap of 5 USDC for SOL. The trading interface obtains a quote, constructs the intended action and asks you to approve. Its program instructions debit and credit the appropriate accounts under the signed conditions. The remaining USDC and resulting SOL can then appear in your wallet.
You have used a payment and a market without moving between separate blockchain networks. The products can still have different fees and rules. Read the USDC transfer walkthrough and the swap guide for the complete operational steps.
Where people use the network
Payments move assets between accounts. Stablecoins can give a business a familiar unit of account, while payment software links a transfer to an invoice and decides when to fulfil an order. Converting receipts into bank money is a later step in that business's route.
Markets and DeFi use programs to exchange tokens, supply liquidity or manage collateral and loans. An automated market maker calculates an exchange from its pool state. A lending market applies collateral and interest rules. The program model lets these actions be composed into larger transactions.
Digital assets record ownership and selected properties of collectibles, memberships or game items. Media and the service that gives an item its use can live outside the blockchain. The token's standard tells a compatible application how to interpret its onchain representation.
Infrastructure projects can use Solana for payments, assets and reward accounting around a physical service. A wireless network still uses radios to carry traffic; a blockchain can account for related rights and distributions. Our real-world applications guide traces specific workflows.
How Solana approaches performance
A transaction declares the accounts it reads and writes. The runtime can schedule work with compatible access in parallel. Two transfers involving different state may proceed independently; two trades that write the same pool state need an ordering. This makes account design important to application performance.
Consensus performs another job: agreeing on the accepted history. The Foundation's current migration guide reports Alpenglow's Votor active on mainnet since 21 October 2026. Rotor is a separate later propagation phase. The guide also changes how developers interpret finality and block streams.
For a user, performance has several stages: signing, delivery, execution, consensus and receiving a fresh result from a service. A short protocol finality target describes one part of this path. Exchange credit or an application's own processing can add time.
For a builder, the useful starting point is the account-and-program execution model. It explains which work can run independently and what a transaction must supply. You can then choose infrastructure and measure the actual path your application uses.
Mainnet, devnet and a local validator have separate state
Mainnet is the live production network. Devnet supports application experiments with test assets. Testnet serves network and validator testing. A local validator gives a developer a separate environment on their own machine. These environments can expose similar account and RPC interfaces while keeping different records.
The same public address can therefore show one balance on mainnet and another on devnet. A token you created in a local exercise does not become the issuer's mainnet asset because you give it the same symbol. The network and mint together establish the context of the holding.
For a first experiment, use a development-only wallet and the intended test environment. Obtain test funding through its supported route, run one action and inspect the signature on an explorer configured for the same cluster. Test faucets have limits, and public test environments can reset; their funds should not be treated as a purchased mainnet balance.
Changing a wallet's network selector changes where it looks or submits. It does not bridge assets or copy programs into another environment. To move actual value between independent networks, use a supported route and follow its separate completion stages. The bridge guide explains that boundary.
Choose a first task and follow its evidence
For a first payment, learn the wallet's recovery method, obtain the recipient's network-specific instructions and understand the fee. Send the intended asset, save the signature and inspect the result. The explorer guide shows which fields establish execution and received balances.
For staking, begin with the stake account lifecycle. For DeFi, learn a swap before adding liquidity or opening debt. This gives you a concrete reference for token movement, quotes and execution.
For development, use devnet or a local environment, then read accounts, programs and transaction structure. Build one small action and inspect its resulting account state. A reproducible operation teaches more than a diagram of unrelated network names.
For analysis, keep each metric's definition and source with its number. Our library separates user instructions, technical explanations and measurement guides so you can move from the overview to the level your task needs.
Common questions
How is Solana different from an exchange?
Solana is a network on which transactions execute. A centralised exchange runs customer accounts, trading and custody. It can use Solana to receive deposits or send withdrawals while keeping its own internal records.
Can I use the same wallet in several Solana applications?
A compatible wallet can interact with several applications using the same public accounts. Each application asks for its own actions and permissions. Read the request before signing.
Do I have to buy SOL before receiving USDC?
The transaction needs a fee payer and may require a receiving token account. The sender or an application can pay those costs. Whether you personally need SOL depends on that flow; later unsponsored actions can require it.
Can I learn without using production funds?
Yes. Devnet and local environments let developers use test funding and separate state. The first-program and RPC articles give development-oriented starting points.
Sources and documentation
- Solana introduction
- Solana account model
- Solana programs
- Solana transactions
- Solana transaction fees
- Solana wallet concepts
- Solana RPC overview
- Solana stake accounts
- Solana Foundation: Alpenglow status and migration
- Account modification rules
- Solana SDK AccountMeta contract
- Solana: clusters and public endpoints
Found an error or an outdated detail? Send a correction.
