The Solana Virtual Machine (SVM) is the execution environment of the Solana blockchain: the part of the software that loads on-chain programs, runs them and updates the network's state when transactions arrive. Developers use it to deploy what other chains call smart contracts (Solana calls them programs), and validators use it to process every transaction in each block. Its defining feature is parallel execution, which lets many transactions run at the same time as long as they do not touch the same data.
The term is used in two ways. Narrowly, it means the runtime inside Solana's validator software, including its parallel scheduler, known as Sealevel. More broadly, it has become a label for a family of chains and rollups that reuse Solana's execution layer outside the Solana network, much as the Ethereum Virtual Machine (EVM) is used by many chains besides Ethereum. The SVM is the main technical alternative to the EVM in the smart contract market.
The SVM in plain terms
Imagine a large post office. In one design, a single clerk handles every customer in a queue, one after another, even if the next person wants a different service at a different counter. In another, customers state up front which counters they need, and the office opens many counters at once, serving everyone in parallel unless two people need the same counter.
The SVM works like the second post office. Each transaction lists in advance the pieces of data it will read and change. The system can then see which transactions do not overlap and run them side by side on different processor cores. Only those that touch the same data have to wait their turn. The result is more work done in the same amount of time.
How the SVM works
The SVM is built around an account model in which code and data are kept apart. Programs are stateless: they hold logic but store no balances or records themselves. All state, from token balances to the settings of a lending market, lives in separate accounts that programs are allowed to read or modify. Every transaction must declare which accounts it will read and which it will write.
- Parallel scheduling. Because the account lists are known before execution, the runtime, called Sealevel, can group non-conflicting transactions and run them at once across many cores. Transactions that write to the same account are run one after the other.
- Compiled programs. Programs are usually written in Rust, often with the Anchor framework, and compiled to a bytecode format derived from Berkeley Packet Filter (eBPF), which validators run in a sandbox.
- Compute limits. Each transaction has a budget of compute units, a counterpart to gas on Ethereum, and users can pay a priority fee to be processed sooner.
- Shared standard programs. Common functions such as creating tokens are handled by shared system programs, including the token programs behind Solana token extensions, rather than each project deploying its own token contract.
The SVM works alongside Solana's other components, including proof of history, which orders events in time, and its proof-of-stake consensus among validators.
How the SVM differs from the EVM
The EVM executes transactions one at a time in a set order, and each contract stores its own data. That design is simple to reason about and became the industry default, but it limits how much one chain can process. The SVM trades some simplicity for throughput by making developers think about accounts and data access explicitly. The two use different languages, tools and address formats, so code cannot be moved between them without rewriting. The page on EVM versus non-EVM chains sets out the wider trade-offs. Other chains that pursue parallel execution, such as those using the Move language, take different routes to similar goals.
The SVM beyond Solana
From 2023 onwards, developers began to run the SVM outside Solana itself. Projects have used it as the execution layer of rollups that settle on other chains, and as the base for application-specific networks, arguing that its speed suits trading, payments and games. Engineering teams also worked to separate the SVM from the rest of Solana's validator code so it could be used as a standalone component. The term "SVM ecosystem" now covers Solana plus these related networks, though most activity and decentralized applications remain on Solana's main network, which uses SOL to pay fees.
Criticism and limitations
Parallel execution helps most when transactions are spread across many accounts. When activity piles onto a single popular account, such as one trading pool during a token launch, those transactions must still run in sequence, and congestion returns. Solana's high hardware requirements for validators, needed partly to exploit the SVM's speed, have drawn criticism for raising the cost of running a node and so affecting decentralization, a tension described by the blockchain trilemma. The network also suffered several outages in its early years, which critics linked to its performance-first design. Developers note that the account model has a steeper learning curve than the EVM, and the smaller pool of auditors and tooling can raise security risks for new programs. Supporters respond that the design has delivered high transactions per second at low fees for a layer 1 blockchain.