If you have used a Solana wallet, swapped tokens on a decentralised exchange or minted an NFT, you have already interacted with a Solana smart contract – even if the word “smart contract” never appeared on the screen. On Solana, smart contracts are called programs. The name is different, and so is the architecture. Understanding what smart contracts on Solana are, how they store data and why they work differently from contracts on other blockchains answers a lot of questions that come up when using the network day to day: why you need a small SOL balance to hold tokens, why a transaction sometimes fails with a compute error, and how DeFi protocols on Solana can execute multiple operations in a single click.
What a smart contract actually is
A smart contract is a program that lives on a blockchain and runs automatically when specific conditions are met. There is no company, server or third party in the middle. The code executes on the network itself, and the result is recorded on-chain. When you approve a trade on a decentralised exchange, a smart contract checks your balance, performs the swap and credits the output token to your wallet – all without anyone manually processing the transaction.
Every major smart contract platform – Ethereum, Solana, Avalanche – uses this same basic idea. What differs is the architecture: how the program stores data, how it handles multiple transactions arriving at the same time, and what language developers use to write it. Solana made a set of architectural choices that are fundamentally different from Ethereum, and those choices are the reason the two networks behave differently under load.
Why Solana calls them programs, not smart contracts
Solana uses the word program rather than smart contract, and the distinction is not just branding. On Ethereum, a smart contract bundles together two things in a single deployed unit: the executable code and the data that code works with. The contract stores its own state – account balances, positions, counters – inside itself. On Solana, those two things are separated entirely. A Solana program contains only the logic. The data it operates on lives in separate accounts that are passed into the program when it is called.
The official Solana documentation describes it plainly: programs are stateless. All mutable state lives in separate data accounts, passed in via instructions. This separation is not a limitation – it is the design decision that makes parallel processing possible, and it is why a single Token Program on Solana handles every SPL token on the network rather than requiring a fresh contract deployment for each one.
What stateless means in practice
A stateless program has no memory between calls. When you call a Solana program, you provide it with all the accounts it needs to do its job. The program reads from those accounts, performs its logic and writes results back. When the call ends, the program retains nothing. The next time someone calls the same program, they pass in accounts again.
Think of it like a recipe in a cookbook. The recipe contains instructions but holds no ingredients and remembers nothing about the last time it was used. The ingredients – the actual data – live in the kitchen, in separate containers. The recipe works on whatever you bring to it. Two people can follow the same recipe at the same time using different ingredients without any conflict. That is how Solana programs behave.
How an Ethereum contract differs from a Solana program
The table below shows the core architectural differences. These are not minor variations – they affect how developers write code, how users pay fees and how the network handles congestion.
| Aspect | Ethereum smart contract | Solana program |
|---|---|---|
| Code and data | Stored together in one contract | Separated: program holds code, accounts hold data |
| State model | Stateful (contract stores its own state) | Stateless (data passed in via accounts) |
| Execution | Sequential (EVM processes one at a time) | Parallel (Sealevel runs non-conflicting transactions simultaneously) |
| Primary language | Solidity | Rust |
| Token standard | Each token needs its own contract (ERC-20) | One Token Program handles all SPL tokens |
| Bytecode format | EVM bytecode | sBPF (Solana Bytecode Format) |
| Avg transaction fee | $0.50 to $50+ (varies with gas) | Under $0.001 |
The most consequential difference for everyday users is the token standard row. The Solana vs Ethereum gap on token deployment is stark: on Ethereum, launching a new ERC-20 token means deploying a new contract that contains all the transfer and approval logic again from scratch. The same logic gets rewritten and redeployed thousands of times across thousands of tokens, each with its own potential for bugs. Smart contracts on Solana work differently – every token uses the same Token Program. Developers do not redeploy the logic. They create a new mint account that points to the existing Token Program. The result is lower deployment cost, fewer bugs from repeated code and a consistent interface across every token on the network.
The Solana account model: where programs store their data
Everything on Solana is an account. Your wallet is an account. A token balance is an account. A deployed program is an account. A DeFi position is an account. The Solana account model is a key-value store where each key is a 32-byte address and each value is an account containing a SOL balance, an owner field and a data field. Understanding the account model explains almost every quirk users encounter on the network.
Executable accounts and data accounts
Accounts on Solana fall into two categories. Executable accounts hold compiled program code and have their executable flag set to true. When a transaction calls a program, Solana loads the executable account into memory and runs its bytecode. Executable accounts do not store user data. They store only the program logic.
Data accounts hold all persistent information: token balances, user positions, NFT metadata, liquidity pool state. A data account is owned by the program that created it, and only that program can modify its data field. Any program can read a data account, but only the owner program can write to it. This ownership rule is what prevents one protocol from arbitrarily modifying another protocol’s state.
The Chainstack blog describes the model clearly: if Ethereum’s equivalent is a contract with internal storage slots, Solana’s model externalises that – each slot becomes its own addressable account on-chain. The structure is more granular and more explicit, which is why Solana transactions must list every account they will touch before execution begins.
Account ownership: who can write what
Every account has an owner field that identifies which program controls it. The rules are straightforward. Only the owning program can change an account’s data bytes. The System Program can change an account’s owner or transfer SOL between accounts. Any program can read any account.
Your wallet – what Solana calls a system account – is owned by the System Program. When you send SOL, the System Program transfers lamports from your account to the recipient. When you hold USDC, your USDC balance lives in a token account owned by the Token Program. The Token Program processes transfers. Your wallet program cannot directly modify your token account’s data because it is not the owner – only the Token Program is.
This explicit ownership model is also what makes Solana’s parallel execution practical. Because every transaction declares its accounts upfront and ownership rules prevent conflicts, the runtime can identify which transactions touch completely different sets of accounts and run them simultaneously.
Rent and the minimum SOL balance every account needs
Storing data on Solana costs SOL. Every account must maintain a minimum balance proportional to the amount of data it stores. This is called rent exemption. SOL balances at the account level are measured in lamports – one lamport equals 0.000000001 SOL. An account that holds the minimum 128 bytes of data requires approximately 0.00089088 SOL (890,880 lamports) to stay rent-exempt. A token account requires roughly 0.00203928 SOL. These balances are not fees – they are deposits. If you close a token account, that SOL comes back to your wallet.
This is why opening a new token account in Phantom or Solflare costs a small amount of SOL even before any tokens are transferred. The network charges the rent-exempt deposit to create the data account that holds your balance. The same logic applies to NFTs, DeFi positions and any other on-chain state. An account whose balance drops below the rent-exempt threshold can be reclaimed by the network, which removes it from the active ledger and reduces state bloat.
How a Solana program processes a transaction
When a user initiates any action on Solana – a transfer, a swap, an NFT purchase – the wallet software builds a transaction and sends it to the network. That transaction contains one or more instructions, and each instruction specifies a program to call, the accounts that program will need and any additional data the program requires to do its job.
Instructions: the smallest unit of execution
An instruction on Solana is the atomic unit of on-chain action. Each instruction contains three things: a program ID identifying which program to invoke, a list of accounts the program will read from or write to, and instruction data – a byte array carrying parameters such as the amount to transfer or the operation to perform.
The runtime validates the instruction before execution: it checks that all required signers have signed, that accounts are owned by the right programs and that the fee payer has enough SOL to cover the transaction cost. If any check fails, the entire transaction fails before any state changes occur.
Why Solana transactions can contain multiple instructions
A single Solana transaction can bundle multiple instructions together and execute them atomically – either all instructions succeed or none of them do. When you use a DeFi aggregator that routes a swap through three pools and rebalances a position in one click, that entire sequence may execute as a single transaction. If the third step fails, the first two are rolled back automatically. No partial execution, no stuck funds in intermediate states.
This composability at the transaction level is one of the practical advantages of Solana’s single-chain architecture over multi-layer approaches, where cross-chain operations require bridging and cannot be made atomic.
Compute units and why transactions sometimes fail
Every operation a program performs on Solana consumes compute units. Reading an account, performing arithmetic, calling another program – each action has a cost measured in compute units. The default compute budget for a transaction is 200,000 compute units. Complex DeFi transactions – multi-hop swaps, transactions that call several programs in sequence – can exceed this limit, and when they do, the transaction fails with a compute budget error.
Users can attach a Compute Budget instruction to increase the limit up to a maximum of 1,400,000 compute units per transaction. Most wallets and DeFi frontends do this automatically for complex operations. The compute unit system serves as a safeguard against programs that loop indefinitely or consume disproportionate network resources, similar to how gas limits function on Ethereum but with a different fee structure.
Sealevel: how Solana programs run in parallel
The account model and the instruction system are what make Sealevel – Solana’s smart contract runtime – possible. Because every transaction declares its accounts upfront and specifies exactly which are read-only and which are writable, the Sealevel runtime can analyse all pending transactions and identify groups that touch completely different accounts.
Those groups can run simultaneously across multiple CPU cores. Two users swapping different token pairs on different pools have no account overlap. Sealevel runs both swaps at the same time. A token transfer and an NFT listing have no shared accounts. They execute in parallel. The throughput gains are significant: where Ethereum’s EVM processes one transaction at a time regardless of how many cores the validator has, Sealevel uses all available cores for transactions that can safely run concurrently.
The stateless design of Solana programs is the prerequisite for this. A stateful contract that stores data internally cannot safely run in parallel with another call to the same contract, because both calls might try to modify the same storage slot. A stateless program that reads and writes only to explicitly listed accounts has no hidden shared state to conflict over. For a full breakdown of how Proof of History, Tower BFT and Sealevel work together at the network level, see how Solana works.
The Solana Program Library: programs that already exist on-chain
The Solana Program Library (SPL) is a collection of on-chain programs maintained by Solana Labs that developers can call without deploying their own implementations. Rather than every token project writing token transfer logic from scratch, they all use the same audited Token Program. Rather than every NFT marketplace writing its own metadata standard, they use the Metaplex programs from the SPL-adjacent toolset. This reuse is one of the architectural advantages of stateless programs – the same program can serve thousands of different projects without modification.
Native programs: the programs built into Solana
Native programs are the core programs integrated directly into the Solana runtime. They handle the most fundamental network operations and cannot be upgraded except through network-wide software updates.
The most important native program for everyday users is the System Program. Every SOL transfer goes through the System Program. Every new wallet creation goes through the System Program. It is the program whose address is the owner of all standard wallet accounts. The Stake Program manages SOL staking and delegation. The Vote Program handles validator voting. The BPF Loader is the program responsible for deploying and managing upgradeable custom programs.
The Token Program and SPL tokens
The Token Program is the most-used program on Solana by transaction volume. It handles every operation involving SPL tokens: minting new tokens, transferring balances between accounts, burning tokens and approving delegations. When you hold USDC, your balance is stored in a token account owned by the Token Program. When you transfer USDC to another wallet, the Token Program checks both token accounts, verifies signatures and updates balances.
Each SPL token has a mint account that stores the token’s metadata: total supply, number of decimal places and who has permission to mint new tokens. Each holder has a separate token account that stores their balance. When you open a new position in a token you have never held before, a new token account is created for you and the rent-exempt deposit of roughly 0.002 SOL is charged. When you close the position and empty the token account, that deposit returns to your wallet.
For a detailed breakdown of how SOL and SPL tokens relate to each other on the network, see what Solana is and how the token model works.
Token-2022 and Token Extensions
Token-2022, also called Token Extensions, is a newer version of the Token Program deployed at a separate address. It is backward-compatible with the original Token Program to a degree but adds capabilities that the original design could not support. For users, Token-2022 enables tokens with features that were previously impossible on Solana: transfer fees that automatically route a percentage of each transfer to a specified account, non-transferable tokens that cannot be moved from their initial holder, confidential transfers that keep amounts private and interest-bearing tokens whose displayed balance grows over time.
These extensions matter for users because they change what a token can do in your wallet. A token built on Token-2022 with a transfer fee will deduct a small amount on every send. A non-transferable token cannot be sold or moved. DeFi protocols must explicitly support Token-2022 tokens, and not all do yet, which is why some newer tokens behave differently across wallets and exchanges.
Cross-Program Invocation: when programs call other programs
Solana programs can call other programs directly during execution. This is called Cross-Program Invocation, or CPI. When a DeFi protocol needs to transfer tokens on behalf of a user, it does not implement its own transfer logic – it calls the Token Program via CPI. When a lending protocol needs to check a price, it calls an oracle program via CPI. Multiple programs can be composed together in a single transaction, each calling the next in a chain.
From the user’s perspective, CPI is why a single DeFi transaction can do so much. When you click “swap and stake” on an aggregator, the aggregator program may call a routing program, which calls a liquidity pool program, which calls the Token Program twice – all within one atomic transaction. If anything in that chain fails, everything reverts. No partial execution and no need to manually track intermediate steps.
Composability through CPI is a structural feature of Solana that is harder to replicate on multi-layer architectures. On Ethereum, composing actions across different protocols still happens within one transaction on L1, but once assets move to different Layer 2 networks, atomic composition across those layers requires specialised bridge infrastructure. On Solana, every program on the same chain can call every other program atomically by design.
Program Derived Addresses: accounts that programs control without private keys
Most accounts on Solana are controlled by a keypair – a public address and a private key. Program Derived Addresses (PDAs) are different. A PDA is an account address that falls off the elliptic curve, meaning no private key corresponds to it. It is generated deterministically from a program ID and a set of seed values. Only the program that generated the PDA can sign transactions involving that account.
PDAs are what allow DeFi protocols to hold user funds securely on-chain. When you deposit into a lending protocol, your tokens move into a PDA controlled by the lending program. No developer, founder or employee holds the private key to that account because no private key exists. Only the program’s own logic can move those funds – specifically, it will release them when the conditions defined in the program code are satisfied.
This is also why PDAs matter for the security analysis of any DeFi protocol. A protocol whose treasury lives in a PDA with immutable program logic is structurally different from one where the funds are in a wallet controlled by a multisig that three team members hold. Both designs exist on Solana. Understanding which one a protocol uses tells you something important about the trust assumptions involved.
PDAs also serve a practical role in making programs reusable. Because a PDA address is deterministic – derived from the same seeds, it always produces the same address – any user or program can independently calculate where an account should be without querying the chain first. This predictability reduces the communication overhead required to interact with complex protocols.
Rust, Anchor and the languages used to write Solana programs
Most Solana programs are written in Rust. C and C++ are also supported, and the broader SVM toolchain includes clients for Python, Go and TypeScript, but Rust is the standard for on-chain program development. The choice of Rust shapes the security characteristics of the programs users interact with every day.
Why Rust and not Solidity
Rust enforces memory safety at compile time. The compiler rejects code with buffer overflows, null pointer dereferences and data races before it ever runs. This means entire categories of bugs common in other languages cannot exist in a correctly compiled Rust program. For blockchain programs that handle real value, that compile-time safety is meaningful – a class of vulnerabilities that has led to hundreds of millions of dollars in losses on EVM chains simply cannot occur in Rust programs for the same reason.
The trade-off is difficulty. Rust requires developers to understand ownership, borrowing and lifetimes – concepts absent from most other languages. The learning curve is steeper than Solidity. This is one of the reasons Solana’s developer pool is smaller than Ethereum’s, and why audited, battle-tested programs from the Solana Program Library are reused so heavily rather than reimplemented.
Anchor: the framework that simplifies Solana development
Writing a Solana program in raw Rust requires a significant amount of boilerplate code: manually deserialising account data, validating account ownership, checking signatures. Anchor is a framework that handles this boilerplate automatically. Developers define their account structures and instruction handlers, and Anchor generates the validation and serialisation code.
The practical effect is that Anchor reduces development time substantially and makes code easier to audit. Most production Solana programs deployed after 2022 use Anchor. When you see a Solana program audited by a security firm, the audit report will typically note whether Anchor was used and how the program handles account validation – because missing or incorrect account checks are the most common vulnerability class in Solana programs regardless of framework.
Upgradeable programs: what it means when a program can change
Most Solana programs are deployed using the BPF Upgradeable Loader, which means the code can be changed after deployment as long as the deployer controls the upgrade authority. This is the default for new programs. An upgradeable program can have bugs patched and features added after launch, which is useful during early development. The risk is that the same upgrade authority can also change the program’s logic in ways that affect user funds.
Upgradeable vs immutable: the security trade-off
An immutable program has had its upgrade authority revoked. No one can change its code under any circumstances. For users, this is the strongest available guarantee that the program behaves exactly as audited. The Serum DEX, for example, moved its core programs to immutable after the FTX collapse specifically because the upgrade authority had previously been held by FTX-affiliated accounts – a lesson in why upgrade authority matters.
Many protocols take a middle path: the upgrade authority is held not by a single wallet but by a multisig – an account that requires M of N signatures from different keyholders before any upgrade can proceed. A 3-of-5 multisig with signers from different organisations is meaningfully more resistant to unilateral changes than a single developer key.
Before interacting with any Solana DeFi protocol, users can check the program’s upgrade authority on Solana Explorer or Solana.fm. If the authority is the zero address, the program is immutable. If it is a wallet address, a single person controls upgrades. If it is a multisig program address, the governance structure determines what changes are possible.
Verified builds: how to check what a program actually does
An open-source repository on GitHub does not prove that the deployed on-chain program matches the published code. A developer could deploy different code than what appears in the public repository. Verified builds solve this by cryptographically linking the on-chain bytecode to a specific commit in a public repository. When a program has a verified build, any user can independently compile the source code and confirm that the resulting bytecode matches what is deployed on-chain.
Solana.fm and the Solana Explorer both display whether a program has a verified build. An audit without a verified build tells you the audited code is safe – but not necessarily that the deployed program is the audited code. For high-value protocols, both an audit and a verified build are the standard a careful user should look for.
Solana smart contract security: what users need to know
Rust prevents memory safety bugs, but Solana programs introduce a different category of vulnerabilities that are specific to the account model. The most common is missing signer checks: a program that fails to verify that a required account has actually signed the transaction can be tricked into executing operations on behalf of accounts that did not authorise them.
Owner validation failures occur when a program accepts an account without verifying that it is owned by the expected owner program. An attacker can pass a maliciously crafted account that looks like a legitimate token account but is owned by a different program and contains manipulated data. Account substitution is a related attack where a valid account is replaced with a different valid account of the same type – for example, swapping one user’s token account for another’s in a transaction.
These vulnerabilities are Solana-specific. A security firm with deep Solana expertise will check for them systematically. A general smart contract auditor more familiar with EVM patterns may miss them. For users, the practical implication is straightforward: Solana smart contracts that have been audited by firms with documented Solana experience, that use Anchor’s built-in account validation, that have verified builds and that hold their upgrade authority in a multisig offer a meaningfully different risk profile from those that do not.
Solana smart contract audit costs range from around $15,000 for simple programs to $60,000 or more for complex DeFi protocols. The cost is not a reliable proxy for quality – what matters is the auditor’s specific familiarity with Solana’s account model vulnerabilities. For more on how Solana Labs and the founding team approached security in the network’s architecture, the history of network-level decisions provides useful context.
What Solana programs power today
The programs described above are not abstract infrastructure. They process more daily transactions than most other public blockchains combined. In October 2025, the Solana network processed approximately 70 million daily transactions and facilitated $143 billion in DEX volume for that month alone.
Decentralised exchanges like Raydium and Orca run entirely on Solana programs. Their liquidity pools, swap routers and yield farming vaults are all programs that hold user funds in PDAs and execute trades through CPI chains involving the Token Program. The on-chain order book model – which Ethereum could not support at scale because sequential execution made it too slow – is viable on Solana because Sealevel processes non-conflicting orders in parallel.
NFT marketplaces like Magic Eden and Tensor use programs for listing, escrow and settlement. When a user lists an NFT for sale, the NFT moves into a PDA controlled by the marketplace program. When a buyer purchases it, a single atomic transaction transfers SOL to the seller, pays royalties to the creator and moves the NFT to the buyer’s wallet. No intermediate custody by the marketplace team and no multi-step settlement.
DePIN networks – decentralised physical infrastructure – use Solana programs for micropayment settlement. Helium migrated to Solana specifically because its model requires hundreds of thousands of small reward payments per day to hotspot operators. At Ethereum fees, those micropayments would cost more in gas than the rewards themselves. At Solana’s sub-cent fees with Sealevel throughput, the economics work.
Stablecoins on Solana – USDC, USDT and PayPal’s PYUSD – are all SPL tokens using the Token Program. Visa and Western Union use Solana for stablecoin settlement because the combination of low fees, fast finality and atomic composability makes it practical for real payment flows rather than just speculative trading.
Frequently asked questions
What is the difference between a Solana program and a smart contract?
They refer to the same concept – executable on-chain code that runs automatically when called. Solana uses the term “program” because its architecture differs from Ethereum’s smart contracts. A Solana program is stateless: it contains only logic and stores no data internally. Data lives in separate accounts that are passed to the program when it is called. An Ethereum smart contract bundles code and state together in a single deployed unit.
Why does opening a new token account cost SOL?
Every account on Solana must maintain a minimum SOL balance to remain rent-exempt. A token account storing your balance requires approximately 0.002 SOL as a deposit. This is not a fee – it is returned to your wallet when you close the token account. The deposit covers the cost of storing the account’s data on validators’ hardware for as long as the account exists.
What is the Solana Program Library?
The Solana Program Library (SPL) is a collection of on-chain programs maintained by Solana Labs. The most important is the Token Program, which handles every SPL token on the network – transfers, minting and burning. Rather than each project deploying its own token logic, all SPL tokens share the same audited program. This reduces deployment cost and creates a consistent interface across the entire network.
What is a Program Derived Address (PDA)?
A PDA is an account address that has no corresponding private key. It is generated deterministically from a program ID and seed values. Only the program that generated the PDA can sign transactions involving it. DeFi protocols use PDAs to hold user deposits – no person or team member holds the key to these accounts because no key exists. The program’s own logic determines when funds can move.
What is Cross-Program Invocation (CPI)?
CPI is the mechanism by which one Solana program calls another during execution. When a DeFi protocol needs to transfer tokens, it calls the Token Program via CPI rather than reimplementing transfer logic. Multiple CPI calls can be chained in a single transaction, allowing complex operations – swap, stake and collect fees in one click – to execute atomically. If any step fails, all steps revert.
What is the difference between an upgradeable and an immutable Solana program?
An upgradeable program has an upgrade authority – an account that can push new code to the deployed program after launch. An immutable program has had the upgrade authority revoked, and its code cannot change under any circumstances. Immutable programs offer stronger guarantees to users because the audited code is permanently fixed. The upgrade authority is visible on Solana Explorer and Solana.fm for any deployed program.
What is Token-2022?
Token-2022, also called Token Extensions, is a newer version of the Solana Token Program. It adds capabilities the original program did not support: transfer fees, non-transferable tokens, confidential transfers and interest-bearing tokens. Tokens built on Token-2022 may behave differently in wallets and DeFi protocols compared to standard SPL tokens, because not all protocols have added support for the new extensions yet.
What language are Solana smart contracts written in?
Most Solana programs are written in Rust. C and C++ are also supported. Rust’s compile-time memory safety prevents buffer overflows, null pointer dereferences and data races before the code ever runs. The Anchor framework simplifies Rust development by handling boilerplate account validation automatically. Solidity, the language used for Ethereum smart contracts, is not supported on Solana.
What is Sealevel?
Sealevel is Solana’s smart contract runtime – the execution engine that runs programs. Because every Solana transaction must declare its accounts upfront, Sealevel can identify transactions that touch different accounts and run them simultaneously across multiple CPU cores. This parallel execution is a primary reason for Solana’s transaction throughput advantage over sequential execution models used by Ethereum’s EVM.
Are Solana programs secure?
Rust prevents memory-safety bugs common on other platforms. However, Solana introduces specific vulnerabilities tied to its account model: missing signer checks, owner validation failures and account substitution attacks. These require Solana-specific audit expertise to detect. Programs that have been audited by Solana-focused firms, use Anchor’s account validation, have verified builds and hold upgrade authority in a multisig carry meaningfully lower risk than those without these measures.
What is a verified build on Solana?
A verified build cryptographically links a deployed on-chain program to a specific commit in a public source code repository. It allows any user to independently compile the published code and confirm that the resulting bytecode matches what is actually running on-chain. An open-source repository alone does not prove the deployed code matches. Verified builds, visible on Solana.fm and Solana Explorer, close that gap.
What is the compute budget on Solana?
Every Solana transaction has a compute budget measured in compute units. The default limit is 200,000 compute units. Each operation a program performs – reading an account, doing arithmetic, calling another program via CPI – consumes compute units. Complex DeFi transactions can exceed the default limit and fail. Users and applications can attach a Compute Budget instruction to increase the limit up to 1,400,000 compute units per transaction. Most modern DeFi frontends set this automatically for complex operations.
