What is the Solana Virtual Machine (SVM)? Explained for beginners

The Solana Virtual Machine is the software layer that reads incoming transactions, figures out which programs to run and in what order, executes those programs against the relevant accounts, and writes the results back to the blockchain. Every token swap, NFT purchase, staking delegation and DeFi interaction on Solana passes through it. The abbreviation SVM appears frequently in discussions about Solana scaling, rollups and developer tooling, often without a clear explanation of what it actually is. This article covers what the SVM does, how it differs from the Ethereum Virtual Machine, why its architecture enables higher throughput than sequential systems, and how it has moved beyond the Solana blockchain itself.

What a virtual machine does on a blockchain

A virtual machine on a blockchain is the runtime environment responsible for executing smart contract code. When a developer writes a program and deploys it to a blockchain, that program does not run directly on the operating system of any single computer. Instead, it runs inside the virtual machine, which provides a controlled environment with defined rules about what programs can and cannot do, how much computation they can consume, and how they interact with the blockchain’s shared state.

The virtual machine translates compiled program bytecode into instructions the validator hardware can execute. It enforces resource limits so no single program can consume all available compute. It tracks which accounts a transaction reads from and writes to. And it applies the resulting state changes only if execution completes successfully – if any step fails, the entire transaction is rolled back as if it never happened.

Ethereum introduced the concept with the Ethereum Virtual Machine (EVM) in 2015. The EVM became the standard reference for blockchain virtual machines and has since been adopted or replicated by dozens of networks. Solana built its own alternative from scratch, designed around different priorities, primarily the ability to execute many transactions simultaneously rather than one at a time.

What the Solana Virtual Machine is

The term Solana Virtual Machine has two overlapping definitions that most articles conflate without acknowledging the difference. Understanding both gives a clearer picture of what people mean when they use the term.

The narrow definition: the sBPF bytecode interpreter

In the strict technical sense, the SVM is the bytecode interpreter that executes compiled Solana programs. Programs written in Rust, C or C++ are compiled into sBPF – Solana Bytecode Format, a derivative of Linux eBPF that Solana adapted for its specific requirements. The sBPF interpreter reads this bytecode instruction by instruction and carries out the corresponding operations on the validator’s hardware.

sBPF is a register-based virtual machine, meaning it works directly with named registers – similar to how a physical CPU operates. The EVM, by contrast, is stack-based, pushing and popping values from a stack to perform operations. Register-based architectures are generally faster to interpret and easier to optimise with just-in-time (JIT) compilation, which translates bytecode to native machine code at runtime for additional speed gains.

The broad definition: the full transaction execution pipeline

In the way most articles and developers use the term, SVM refers to the complete transaction execution pipeline – everything from the moment a transaction arrives at a validator to the moment the resulting state changes are written to the ledger. This includes transaction scheduling, conflict detection, parallel assignment to CPU cores, the sBPF bytecode interpreter itself, and the state commitment process.

The broader definition is more useful for understanding why Solana processes transactions the way it does. The sBPF interpreter is one component. The scheduling and parallelisation logic – primarily Sealevel – is another. Together they form what most people mean when they say “the SVM”. For a more detailed look at how Solana’s full architecture works, including Proof of History and Tower BFT, the complete breakdown covers each layer.

How the SVM processes a transaction step by step

When a user approves a transaction in a Solana wallet, a specific sequence of events takes place before that transaction is finalised. Understanding this sequence explains why parallel execution is possible and where the speed advantage actually comes from.

Step 1: transaction arrives at the Banking Stage

Transactions submitted to the network reach the current slot leader through Gulf Stream’s forwarding mechanism. The slot leader passes incoming transactions to a component called the Banking Stage, which is responsible for scheduling. The Banking Stage reads the account access lists that every Solana transaction must declare upfront – which accounts it will read, which it will write – and uses this information to identify which transactions are independent of each other. All validator nodes on the network run their own isolated instance of the SVM, maintaining consistent state across the blockchain through the consensus process.

Transactions that write to completely different accounts have no data dependency. They can execute at the same time without any risk of conflicting results. The Banking Stage groups independent transactions and assigns them to separate execution threads. Transactions that share a writable account are placed in a sequential queue for that account.

Step 2: non-conflicting transactions run in parallel via Sealevel

Sealevel is the parallel execution engine that acts on the Banking Stage’s scheduling decisions. Once independent transaction groups have been identified, Sealevel distributes them across available CPU cores on the validator machine. Each core processes its assigned group concurrently with every other core. A validator with 32 cores can theoretically process 32 separate transaction groups simultaneously, and across the network’s roughly 1,900 active validators, the combined throughput adds up quickly.

The key design requirement that makes this possible is the mandatory account declaration. Because every Solana transaction specifies its read and write accounts before execution begins, Sealevel can determine conflicts without running any code. Two transactions touching entirely different accounts are guaranteed not to interfere, regardless of what those transactions actually do. This static analysis of dependencies is what separates the SVM’s scheduling approach from systems that discover conflicts only during execution.

Step 3: the sBPF runtime executes the program

For each transaction assigned to a thread, the SVM loads the relevant program account – the compiled sBPF bytecode of the Solana program being called. The sBPF runtime executes the bytecode against the accounts passed into the transaction. Each operation consumes compute units from the transaction’s compute budget. If execution completes within the budget, the resulting state changes are staged for commitment. If the budget is exhausted, execution halts, the transaction fails, and the state changes are discarded – though the base fee is still charged.

Programs can call other programs during execution through Cross-Program Invocation (CPI). The runtime handles these nested calls within the same transaction context, maintaining a single atomic boundary across all instructions in the transaction.

Step 4: state changes are committed and propagated

Once execution completes, the validator applies the resulting state changes to its local copy of the blockchain. The updated state is included in the block produced for that slot. Turbine broadcasts the block as shreds across the validator network, and Tower BFT consensus finalises the block once sufficient stake has voted for it. At that point, the state changes become part of the permanent record and are reflected in every validator’s copy of the ledger.

Sealevel: why the SVM runs thousands of transactions at the same time

Sealevel is the component that most distinguishes the Solana Virtual Machine from the EVM and from most other blockchain execution environments. Its name comes from the idea of sea-level parallelism – processing many things at the same depth simultaneously rather than stacking them sequentially.

Why transactions must declare their accounts upfront

Every Solana transaction contains a list of all accounts it will access before a single line of program code runs. Each account in the list is marked as either read-only or read-write. Programs can only read from read-only accounts and can only write to accounts explicitly listed as writable.

This requirement exists specifically to enable scheduling. Without upfront declarations, the system would have to either run transactions sequentially and detect conflicts as they occur, or run them in parallel and roll back conflicting results retroactively. Both approaches are slower and more complex than simply knowing the access pattern before execution begins. The account model – where programs are stateless and all state lives in separate accounts – is what makes upfront declarations practical. Each transaction brings its accounts with it explicitly rather than referencing internal contract storage. For a detailed explanation of how Solana programs and the account model work, including how data accounts and program accounts differ, the full guide covers the architecture in depth.

How Sealevel schedules independent transactions in parallel

The Banking Stage builds a dependency graph from the declared account lists of all pending transactions. Transactions that share no writable accounts are placed in the same parallel execution group. Transactions that share a writable account are placed in a sequential chain relative to each other. Sealevel then processes each parallel group on a separate CPU thread.

A concrete example: if one transaction involves Alice sending USDC to Bob, and another involves Carol buying an NFT from David, these two transactions share no accounts. Sealevel runs both at the same time on separate cores. The final blockchain state reflects both outcomes as if they happened simultaneously, because they did. Squads describes it as the SVM allowing programs that do not interact with the same data to run concurrently, which reduces congestion and keeps fees low.

What happens when two transactions need the same account

When two transactions both need to write to the same account, they cannot run in parallel without risking inconsistent results. If two swap transactions both try to update the same liquidity pool simultaneously, the second one might read a stale balance that the first transaction has already modified.

The SVM handles this by processing conflicting transactions sequentially in the order they were received. The first transaction completes, the account state updates, and then the second transaction executes against the updated state. This sequential handling is limited only to the specific accounts in conflict – every other transaction continues to run in parallel on other cores. The EVM, by contrast, processes all transactions sequentially regardless of whether they share any accounts.

The account model: the foundation that makes parallelism possible

The SVM’s ability to parallelise execution depends entirely on one architectural decision: separating program code from program state. On Ethereum, a smart contract contains both its executable logic and its storage slots in a single deployed unit. The contract owns its data internally. This design makes parallel execution risky because two concurrent calls to the same contract might both try to modify the same storage slot at the same time.

Solana splits these two things apart. A Solana program (smart contract) is stateless – it contains only the executable bytecode and holds no data between calls. All persistent data lives in separate data accounts owned by the program. When a transaction calls a program, it passes in the relevant accounts explicitly. The program reads from and writes to those accounts, and when the call ends, the program retains nothing.

Because programs are stateless and accounts are passed in explicitly, the system always knows which data a given transaction will touch before it runs. Two transactions calling the same program but operating on different user accounts do not conflict. The same Token Program handles millions of token transfers daily, and the vast majority of them run in parallel because each transfer involves different source and destination accounts. Every validator on the network runs its own copy of the SVM and arrives at the same result independently, which is how validators maintain consensus without sharing computation.

This is why the account model is not just a design preference – it is a prerequisite for Sealevel. Without stateless programs and explicit account declarations, the kind of dependency analysis Sealevel performs would not be possible. For more on how SOL and the token model fit into this architecture, the SOL overview covers how the native token interacts with accounts and fees.

SVM vs EVM: the key differences

The SVM and the EVM perform the same fundamental job – executing smart contract code on a blockchain – but their architectures reflect different design choices about what matters most. The table below covers the main differences.

The SVM vs EVM fee market difference is worth highlighting because it affects users directly. The EVM uses a global fee market: when one popular application floods the network with transactions, fees rise for everyone. A busy NFT mint on Ethereum raises the cost of an unrelated token transfer. The SVM uses localized fee markets: congestion and fee pressure are isolated to the specific accounts being contested. A popular token launch raises priority fees for that launch’s transactions and leaves everything else unaffected.

The register-based vs stack-based distinction matters for performance at a lower level. Stack-based VMs push inputs onto a stack and pop the result after each operation. Register-based VMs address values in named registers directly, which is how physical CPUs work. Register-based execution is faster to run natively and easier to optimise with JIT compilation – the technique that converts bytecode to native machine code at runtime. The EVM has historically been harder to JIT-compile efficiently, though recent work on EVM clients has narrowed this gap. Validators running the SVM benefit from this because JIT-compiled programs execute faster, leaving more CPU capacity for the parallel scheduling work that Sealevel performs.

What the SVM is built on: Rust, sBPF and compilation

Understanding how code gets from a developer’s editor to the SVM runtime explains why Solana programs behave the way they do and why Rust is the language of choice.

Why Rust is the primary language for SVM programs

Rust enforces memory safety at compile time. Its ownership and borrowing system prevents buffer overflows, null pointer dereferences and data races – entire categories of security vulnerabilities that have caused significant losses in other smart contract environments – before the code ever runs. For programs that handle real user funds, this compile-time safety matters.

Rust is also fast. It compiles to native machine code with minimal runtime overhead, which makes sBPF programs efficient to execute. The trade-off is that Rust has a steeper learning curve than Solidity. Concepts like ownership, borrowing and lifetimes do not exist in most languages and take time to master. This is one reason the Solana developer pool is smaller than Ethereum’s despite Solana’s technical advantages. The Anchor framework reduces this friction substantially by handling much of the boilerplate validation code automatically, letting developers focus on business logic rather than low-level account management.

How Rust code becomes sBPF bytecode

Rust programs are compiled through LLVM to produce sBPF bytecode. LLVM is the same compiler infrastructure used by Clang and many production-grade compilers. The resulting sBPF bytecode is a binary file that gets deployed to a program account on the Solana blockchain. When a transaction calls that program, the SVM loads the bytecode, passes in the declared accounts, and either interprets the bytecode directly or runs a JIT-compiled native version for speed.

The sBPF format itself is derived from Linux eBPF but modified for Solana’s requirements. It uses 64-bit registers, has a limited instruction set designed for verifiability, and enforces strict resource limits through the compute unit metering system. Every sBPF instruction has a defined compute unit cost, and a transaction that exceeds its compute budget is terminated – preventing any program from consuming unbounded resources.

Decoupled SVM: how the SVM moved beyond the Solana blockchain

For most of Solana’s history, using the SVM meant building on the Solana blockchain. The SVM was tightly coupled to the Agave validator client – the software that validator nodes run to participate in the network. If you wanted Sealevel parallel processing, you needed the full Solana stack: Proof of History, Tower BFT, Turbine, and all the rest.

In July 2024, Anza – the team that maintains the Agave validator client – released the SVM API, a set of interfaces that decouple the transaction execution layer from the rest of the validator software. The SVM API allows developers to use Sealevel and the sBPF runtime in isolation, without the full Solana consensus stack. This is what the term Decoupled SVM refers to.

What the SVM API made possible

Before the SVM API, building a chain or rollup that used Solana’s execution environment required forking the entire validator codebase. After the SVM API, the execution layer became a composable component that could be plugged into other settlement layers, consensus mechanisms and data availability systems.

The practical effect was a significant increase in projects building with SVM as their execution environment while settling on different networks. These projects wanted Sealevel’s parallelism and Rust’s performance without being tied to Solana’s specific consensus or settlement choices. The SVM API gave them a clean way to do that.

SVM chains and rollups in 2025 and 2026

The SVM rollup space grew significantly through 2024 and 2025. Several distinct projects use the SVM as their execution environment with different settlement and consensus arrangements:

• Eclipse is an Ethereum Layer 2 that uses the SVM for execution and Ethereum for settlement. Users interact with it using Solana-style programs and wallets, but final settlement security comes from Ethereum’s validator set. Eclipse launched its mainnet in late 2024.
• SOON (Solana Optimistic Open Network) is a decentralised SVM L2 designed to bring SVM execution to multiple settlement layers. SOON Mainnet launched in early 2025.
• Termina (formerly known as Nitro) is an SVM scaling solution focused on high-performance applications requiring dedicated throughput.
• Sonic is an SVM chain oriented toward gaming applications, leveraging Sealevel’s throughput for on-chain game state and in-game economies.

These projects collectively demonstrate that the SVM’s value proposition – parallel execution, low fees, stateless programs – is seen as useful beyond the Solana blockchain itself. EVM has had a similar expansion through rollups and EVM-compatible chains. The SVM rollup space is earlier in that trajectory but following a similar pattern. The original Sealevel blog post from Solana Labs describes the parallel execution model that all these SVM rollups inherit. For more context on how the Solana network sits relative to these SVM extensions, the full Solana overview covers the broader landscape.

Challenges of the SVM

The SVM’s parallel architecture delivers real performance advantages, but those advantages come with trade-offs that users, developers and validators all encounter.

The Rust learning curve is the most frequently cited barrier for developers. Solidity is approachable for anyone with JavaScript or Python experience. Rust requires learning ownership semantics that have no equivalent in most other languages. The Anchor framework lowers this barrier substantially, but the underlying language still demands more upfront investment than Solidity.

Hardware requirements for running a competitive Solana validator are high because Sealevel is designed to use all available CPU cores effectively. The compute unit budget system – which caps how much work any single transaction can perform – helps prevent runaway programs from consuming all available resources, but setting appropriate compute units per transaction requires developer attention that EVM developers do not need to think about. A validator that cannot keep up with the network’s processing rate loses its slots and earns fewer rewards, creating pressure toward high-end server hardware that limits who can participate as a validator and contributes to Solana’s relatively small validator count of around 1,900 compared to Ethereum’s roughly one million.

The complexity of parallel scheduling also creates operational challenges. When transactions compete for the same accounts during high-demand periods – popular token launches, large liquidations – the sequential fallback for conflicting transactions can create queues that reduce effective throughput precisely when demand is highest. Local fee markets help manage this by letting priority fees rise for the contested accounts while leaving unrelated transactions unaffected, but the queuing behavior still exists.

Finally, the SVM specification is not as formally standardised as the EVM. The EVM has a detailed yellow paper and multiple independent client implementations. The SVM’s specification lives primarily in the Agave codebase, which means SVM-compatible chains depend on tracking Anza’s implementation decisions rather than a published standard. Work toward a more formal SVM specification is ongoing.

Frequently asked questions

What is the Solana Virtual Machine?

The Solana Virtual Machine (SVM) is the execution environment that processes transactions and runs programs on the Solana blockchain. It reads compiled sBPF bytecode, executes programs against the accounts declared in each transaction, and writes the resulting state changes to the ledger. In its broader usage, SVM refers to the complete transaction execution pipeline including the Banking Stage scheduler, Sealevel parallel execution engine, sBPF bytecode interpreter and state commitment process.

How is the SVM different from the EVM?

The most significant difference is execution model. The EVM processes transactions sequentially – one at a time, in order, using a single CPU core. The SVM uses Sealevel to process non-conflicting transactions in parallel across multiple CPU cores. This enables Solana to handle thousands of transactions per second at the L1 level while Ethereum L1 manages 15 to 30. The SVM also uses a register-based bytecode architecture (sBPF) compared to the EVM’s stack-based design, and uses localized fee markets instead of a global fee market.

What is Sealevel?

Sealevel is Solana’s parallel transaction execution engine. Because every Solana transaction declares upfront which accounts it will read and write, the system can identify transactions with no shared writable accounts and run them simultaneously on separate CPU cores. Transactions that do share writable accounts are processed sequentially only relative to each other. Sealevel is the component responsible for this scheduling and parallel dispatch.

What is sBPF?

sBPF stands for Solana Bytecode Format. It is the bytecode format that Solana programs compile to from Rust, C or C++. The SVM’s bytecode interpreter executes sBPF instructions directly. sBPF is derived from Linux eBPF but modified for Solana’s requirements, including 64-bit registers, a fixed instruction set and compute unit metering. It is a register-based format, which makes it faster to execute and easier to JIT-compile than stack-based bytecode formats like the EVM’s.

Why does the SVM use Rust?

Rust enforces memory safety at compile time, preventing buffer overflows, null pointer dereferences and data races before the program ever runs. For programs handling real user funds, this level of compile-time safety reduces the risk of exploits. Rust also compiles to efficient native code, which suits the SVM’s performance requirements. The trade-off is that Rust has a steeper learning curve than Solidity, limiting the size of the developer pool relative to Ethereum.

What is the Banking Stage?

The Banking Stage is the transaction scheduling component within the SVM pipeline. When transactions arrive at the slot leader, the Banking Stage reads their declared account access lists, builds a dependency graph identifying which transactions share writable accounts, and schedules independent groups for parallel execution. Transactions with no shared writable accounts are dispatched to Sealevel for parallel processing. Transactions sharing a writable account are ordered sequentially for that account.

What are localized fee markets on Solana?

Localized fee markets mean that fee pressure from high transaction volume is isolated to the specific program accounts being contested, rather than affecting the entire network. If a popular token launch floods the network with transactions that all target the same accounts, priority fees rise for those specific transactions. An unrelated USDC transfer or staking delegation is not affected. This contrasts with the EVM’s global fee market, where high demand from any source raises fees for all transactions network-wide. For a full breakdown of how Solana transaction fees work – base fee, priority fee, Jito tips and compute units – the fee guide covers each component in detail.

What is the Decoupled SVM?

The Decoupled SVM refers to the ability to use the SVM’s execution environment – Sealevel parallelism and the sBPF runtime – without the full Solana validator stack. In July 2024, Anza released the SVM API, a set of interfaces that separates the execution layer from the consensus, networking and storage layers. This allows other chains, rollups and application-specific networks to use SVM execution while settling on different networks such as Ethereum or Celestia.

What are SVM rollups?

SVM rollups are chains or Layer 2 networks that use the Solana Virtual Machine for transaction execution but settle on a different base layer. Eclipse is the most prominent example – it uses SVM execution with Ethereum for settlement, combining Sealevel’s parallel processing throughput with Ethereum’s security for finality. SOON, Termina and Sonic are other examples following similar models with different settlement choices and application focuses.

Is the SVM better than the EVM?

The SVM offers higher throughput, lower fees and a more scalable architecture at L1. The EVM has a larger developer base, more battle-tested tooling, a more formal specification and a more decentralised validator set due to lower hardware requirements. Neither is strictly better for all use cases. The SVM’s advantages are most pronounced for high-frequency applications, payments and anything where transaction cost or confirmation speed directly affects user experience. The EVM’s advantages are most pronounced for high-value settlement, institutional DeFi and applications where developer availability and tooling maturity matter more than raw performance.

How many transactions per second can the SVM handle?

The Solana network processes 2,000 to 4,000 transactions per second on its live network, with a theoretical maximum approaching 65,000 TPS under optimal hardware conditions. This is significantly higher than Ethereum L1’s 15 to 30 TPS. The practical figure includes validator vote transactions, which consume a portion of block space. User transactions make up a variable share of the total depending on network activity levels.

What programming languages work with the SVM?

Rust is the primary and most widely supported language for writing Solana programs. C and C++ are also supported natively. The Anchor framework provides a higher-level Rust development experience that handles much of the boilerplate account validation automatically. Neon EVM provides Solidity compatibility by running an EVM interpreter on top of the SVM, allowing Ethereum-style contracts to run on Solana. Tools supporting Move and other languages have been explored for SVM-compatible chains.