What Is the Solana Virtual Machine (SVM) and How Does It Work?

Written by Usman Asim

Published on December 18, 202516 min read

---

Solana has emerged as one of the most actively used blockchains in crypto, consistently ranking in the top five by daily active addresses and transaction volume. In October 2025 alone, the Solana network processed approximately 70 million daily transactions and facilitated $143 billion in DEX volume with throughput at peak periods that would bring most other chains to a halt.

What makes this possible isn't just fast consensus or beefy hardware requirements but instead at the core of Solana's performance sits a fundamentally different execution engine: the Solana Virtual Machine (SVM).

The Solana Virtual Machine is a register-based runtime built on eBPF bytecode that executes transactions in parallel by requiring upfront declaration of all state dependencies. Unlike the Ethereum Virtual Machine's sequential transaction model, the SVM was designed from first principles around parallel execution, processing thousands of transactions concurrently across CPU cores rather than one by one.

This architectural choice ripples through everything: how programs store state, how transactions are constructed, how fees are calculated, and how developers think about building on-chain applications.

This guide breaks down the SVM from first principles. We'll start with the core components, explain how they work individually, then show how they combine to enable Solana's performance. By the end, you'll understand not just what the SVM does, but why it's built this way.

What Is a Virtual Machine?

Before diving into the SVM specifically, let's establish what a virtual machine actually is and why blockchains need them.

A virtual machine (VM) is a software-based computer that runs inside another computer. It provides a controlled environment where code can execute without directly accessing the host system's resources. VMs are everywhere: the Java Virtual Machine runs Java bytecode, your browser runs JavaScript in a VM, and cloud servers often run inside VMs.

Blockchains need VMs for a specific reason: deterministic execution of untrusted code. When you deploy a smart contract, thousands of validators around the world need to run that code and arrive at exactly the same result. The VM provides:

• Sandboxing: Untrusted code can't access the host system or other programs' memory

• Determinism: Same inputs always produce same outputs, regardless of hardware

• Metering: Execution can be measured and limited (gas/compute units) to prevent abuse

• Portability: Code runs identically across different machines and operating systems

The Ethereum Virtual Machine (EVM) was the first widely-adopted blockchain VM. It uses a stack-based architecture, executes transactions sequentially, and stores both code and state together in contracts. It works, but its design choices create fundamental throughput limitations.

The Solana Virtual Machine (SVM) takes a different approach. It uses a register-based architecture (more similar to physical CPUs), separates code from state, and, most importantly, executes transactions in parallel.

What Is the Solana Virtual Machine (SVM)?

At its core, the SVM is Solana's execution engine, the system responsible for running program logic, processing transactions, and updating state. If you're coming from Ethereum, think of it as Solana's answer to the EVM, but architecturally distinct in ways that matter.

To understand the SVM, you first need to understand what it operates on:

• Accounts: Solana's universal data structure. Everything is an account: user wallets, token balances, program state, even programs themselves. Accounts hold data and have an owner (the program allowed to modify them). Unlike EVM contracts that bundle code and storage together, Solana separates them completely, all state lives in accounts.

• Programs: This is Solana's term for smart contracts. Programs are stateless: they contain only executable code, compiled to a bytecode format called sBPF. Most Solana programs are written in Rust (though C and C++ are also supported). When a program runs, it reads and writes to accounts passed into it, but stores nothing internally.

• Transactions: A bundle of one or more instructions, each targeting a program and specifying which accounts it needs to read or write. This upfront declaration of state dependencies is the key to everything. It's what makes parallel execution possible.

With that foundation, here's the simplest way to understand the SVM: it's a sandboxed runtime environment that takes compiled program bytecode, executes it against a set of accounts, and determines the resulting state changes. Every transaction on Solana flows through the SVM.

What makes the SVM different from the EVM isn't just implementation details—it's the foundational design. The SVM was built around parallel execution from day one. Transactions declare their state dependencies upfront, allowing the runtime to identify non-conflicting work and process it concurrently across CPU cores. The EVM processes transactions sequentially; the SVM processes thousands simultaneously.

A note on terminology: The term "SVM" carries different meanings depending on context. The narrow definition refers specifically to the bytecode interpreter and JIT compiler that executes program code (we'll cover sBPF, the bytecode format, later). The broader definition, which teams like Anza (Solana's core validator team) use officially, encompasses the entire transaction execution pipeline: scheduling, compute budgeting, program loading, execution, and state updates. When developers say "the SVM," they usually mean this broader system. This guide covers both, and we'll be clear about which we mean as we go.

Understanding the SVM Architecture

Now that we know what the SVM is and how it differs from other blockchain VMs, let's understand how it actually works. This section walks through the complete architecture, from the moment a transaction arrives to the final state change.

We'll cover four interconnected pieces:

1. How transactions flow through the system (the pipeline)

2. The execution engine that runs your code (eBPF, compilation, the VM itself)

3. The data model programs operate on (accounts, PDAs, rent, CPIs)

4. Parallel execution and how Sealevel makes it possible

Each piece builds on the last. By the end, you'll understand not just the individual components, but how they fit together to enable Solana's performance characteristics.

Part 1: How Transactions Flow Through the SVM

The first step in understanding the SVM is tracing the journey of a transaction, from the moment you hit "send" to the block confirmation. This pipeline explains why Solana programs are structured the way they are, why you must declare accounts upfront, and where the parallelism actually happens.

When you submit a transaction to Solana, it doesn't simply enter a queue and wait its turn. It flows through a series of specialized subsystems, each solving a specific problem:

Let's walk through each stage:

The Banking Stage: Where Parallelism Happens

This is the traffic controller. When verified transactions arrive, the Banking Stage analyzes each one: which accounts does it need to read? Which does it need to write?

With this information, it determines which transactions can safely run at the same time:

• Transactions touching completely different accounts → run in parallel

• Transactions both reading the same account → run in parallel (reads don't conflict)

• Transactions both writing to the same account → must run sequentially

The scheduler uses account-level locking to enforce these rules. Worker threads process batches of non-conflicting transactions simultaneously. This is the heart of Solana's parallel execution model, called Sealevel (we'll dive deeper into Sealevel in Part 4).

The Bank: State at a Moment in Time

While the Banking Stage handles scheduling, the Bank handles state. Think of it as a snapshot of Solana's entire state at a specific slot (Solana's unit of time, roughly 400ms).

The Bank manages account data, coordinates execution, and tracks which version of state is canonical. Each Bank progresses through three lifecycle stages:

When the Banking Stage executes transactions, it operates against a specific Bank, a specific version of the world. This is how Solana maintains consistency while processing thousands of transactions in parallel.

BPF Loaders: Spinning Up Program Execution

When a transaction invokes a program, something needs to actually run that program's code. That's the BPF Loader's job.

The BPF Loader handles the full program lifecycle:

• Deployment: Uploading new program bytecode to the network

• JIT compilation: Converting bytecode to native machine code for faster execution

• Upgrades: Pushing new versions of existing programs

• Execution: Provisioning isolated VM instances when programs are invoked

Each program invocation gets its own sandboxed sBPF VM instance with:

• Dedicated memory regions

• A compute budget (similar to gas limits)

• Strict isolation from other programs

If the program exceeds its compute budget? Execution halts. Tries to access memory it shouldn't? Execution halts. The isolation is strict by design. This is how Solana safely runs untrusted code from thousands of developers.

A Typical Transaction Flow

Here's the complete flow for a typical transaction:

1. You submit a transaction specifying which program to call and which accounts it needs

2. The Banking Stage receives it, checks for conflicts with other pending transactions, and schedules it appropriately

3. The Bank provides the current state snapshot for this slot

4. The BPF Loader provisions an sBPF VM instance for the target program

5. The program executes, reading from and writing to the specified accounts

6. State changes commit to the Bank

7. Eventually, the Bank freezes and roots, making the changes permanent

Each component solves a specific problem: the Banking Stage enables parallelism, the Bank provides consistent state, and the BPF Loader ensures safe execution. Together, they form the "SVM" in its broader sense.

Want to dive deeper into transactions? Check out these resources:

• Transaction lifecycle: How transactions are structured and processed

• Fees on Solana: Compute units, priority fees, and budgeting

• Clusters & endpoints: Understanding Solana's network architecture

Part 2: The Execution Engine

The BPF Loader provisions VM instances to run program code. But what actually happens inside that VM instance?

Most blockchain VMs were designed from scratch. Solana went a different direction: it adopted eBPF (extended Berkeley Packet Filter), a technology originally built for the Linux kernel.

BPF originated in 1992 at Lawrence Berkeley Laboratory for efficient network packet filtering. Over time, it evolved into eBPF, a general-purpose, sandboxed VM that runs safely inside the Linux kernel. If you've used observability tools like bpftrace or worked with eBPF-based networking, you've already encountered this technology. It's battle-tested infrastructure powering critical systems at massive scale.

The founder of Solana, Anatoly Yakovenko's background in operating systems (13+ years at Qualcomm) led him to a key insight: why build a new VM from scratch when an existing one already solves the hard problems?

eBPF offered exactly what Solana needed:

• Safety without overhead: eBPF programs run in a restricted environment that cannot crash the host or corrupt memory. Bytecode is statically verified before loading—no invalid memory access, no out-of-bounds jumps, no unauthorized operations. This safety comes without runtime overhead, unlike managed runtimes that need garbage collection.

• Near-native performance: The register-based architecture (unlike the EVM's stack-based design) enables JIT compilation to native machine code. Programs run at near-native speed.

• Mature toolchain: LLVM already includes an eBPF backend. Rust, C, C++, and other LLVM-supported languages compile directly to eBPF bytecode. You write in a language you know; the toolchain handles the rest.

sBPF: Solana's Customized Variant

Solana doesn't use vanilla eBPF. It couldn't as standard eBPF was designed for kernel-space operations with tight constraints that don't map to blockchain execution. So Solana forked it.

The result is sBPF (Solana Bytecode Format), a modified variant tailored for onchain program execution:

The constraints that make eBPF safe in kernel-space, tiny stack, no loops, would cripple smart contract development on Solana. sBPF relaxes these while maintaining safety through compute unit budgets: you can loop, but you'll eventually run out of compute.

The custom syscalls matter too. Programs need to log messages, invoke other programs (Cross-Program Invocation), and perform cryptographic operations. Standard eBPF has no concept of these, and sBPF adds them as first-class primitives.

If you're compiling Solana programs, you'll see the target triple sbf-solana-solana in your toolchain. That's the identifier for this Solana-specific variant.

From Rust to Bytecode: The Compilation Pipeline

When you run cargo build-sbf, your Rust code goes through a multi-stage compilation pipeline:

1. Rust frontend: The compiler parses your code, expands macros, performs type checking, and runs the borrow checker to validate memory safety. By the time code leaves this stage, Rust has eliminated entire classes of bugs (use-after-free, data races, null pointers) that plague other systems languages. This is one of Solana's under-appreciated advantages: memory safety enforced at compile time, before your program ever touches the chain.

2. LLVM optimization: The code transforms to LLVM IR, a platform-agnostic representation where serious optimization happens: constant folding, function inlining, dead code elimination, loop unrolling. These optimizations matter because compute units cost money. Smaller, tighter bytecode means cheaper transactions.

3. sBPF backend: Solana's custom fork of LLVM's BPF backend converts the optimized IR into sBPF bytecode, packaged as an ELF file (.so). This is what you deploy to the network—and what the BPF Loader provisions into a VM instance when your program gets invoked.

Inside the sBPF VM

Now we're at the lowest level: the actual virtual machine that executes your bytecode.

The sBPF instruction set uses 64-bit instructions (8 bytes each) with a RISC-like design and approximately 100 opcodes. Programs have access to 11 64-bit registers:

Memory Layout

The VM organizes memory into fixed regions, each starting at a specific address:

This rigid layout lets the VM enforce strict boundaries, so your program can't accidentally (or maliciously) access memory it shouldn't.

JIT Compilation and Security

The sBPF VM supports two execution modes:

• Interpreter: Walks each instruction one-by-one. Quick to start, slower to run. Useful for local testing and debugging.

• JIT compilation: Transforms sBPF bytecode to native x86_64 machine code before execution. Slower startup, dramatically faster runtime. This is what validators use in production.

The Agave validator caches JIT-compiled programs in ProgramCacheForTxBatch for reuse. Frequently-used programs like the Token Program don't recompile on every transaction. They're already in the cache.

Security enforcement happens at two levels:

1. Static verification (before execution):

   • Rejects malformed or invalid instructions

   • Validates all memory access patterns

   • Ensures jump targets land on valid instruction boundaries

   • Catches unreachable code paths

If your program fails verification, it won't deploy. Period.

1. Runtime metering (during execution):

   • Every instruction consumes compute unit

   • The VM checks the budget after each step

   • Exceeding the budget halts execution immediately

This two-layer approach prevents infinite loops, resource exhaustion attacks, and runaway programs. Even if malicious bytecode somehow passed static verification, it can't run forever. It'll hit its compute limit and halt.

If you want to learn more about the execution engine, check out these resources:

• Programs overview: How Solana programs work

• Developing programs in Rust: Official Rust development guide

Part 3: The Data Model

We've traced how transactions flow through the SVM and how bytecode executes inside the sBPF VM, now lets take a look at what programs operate on.

In most programming environments, you have variables, databases, file systems, various ways to store and retrieve data. Blockchains need something similar: a way to persist state between transactions. The EVM solved this by giving each contract its own storage, a key-value store baked into the contract itself.

Solana takes a radically different approach and understanding this difference is essential, because it shapes everything about how you build on the platform.

Everything on Solana Is an Account

Think of Solana as a giant key-value database:

• Key: A 32-byte address (typically a public key or derived address)

• Value: An account (data structure holding bytes, a balance, and metadata)

This uniformity might seem strange at first, but it's what enables Solana's performance characteristics. Every piece of state has an explicit address, an explicit owner, and explicit rules about who can modify it. The runtime doesn't need to trace through nested contract calls to figure out what state might change, it knows upfront from the transaction's account list.

Let's look at what's actually inside an account, each one contains the same five fields:

The owner field is crucial. Only the owning program can modify an account's data field or debit its lamports. Anyone can read any account (all state is public on Solana), and anyone can credit lamports to any account. But writes are gated by ownership.

This ownership model is what makes parallel execution possible. The runtime knows exactly which program can modify which accounts, so it can safely run non-conflicting transactions simultaneously.

Programs: Stateless by Design

A Solana program is an executable account containing compiled sBPF bytecode. But here's the key insight: programs cannot store state internally. They're pure functions that process instructions and modify the accounts passed to them.

Every Solana program shares the same entry point signature:

When your program runs, it receives:

1. Its own address (so it can verify PDAs it derives)

2. An array of accounts it's allowed to read/write

3. Instruction data containing whatever parameters the caller passed

The program does its logic, modifies the accounts it's allowed to modify, and returns success or an error. It stores nothing internally between calls.

Why stateless? Because it enables clean ownership boundaries. If programs stored their own state, you'd need complex rules about which programs could access which storage. By forcing all state into accounts with explicit owners, the model stays simple and parallelization stays possible.

Design note: Unlike EVM contracts that are immutable by default, Solana programs are upgradeable by default. The upgrade authority can push new bytecode at any time. Developers can revoke upgrade authority to make programs immutable, but this is an explicit choice. This reflects Solana's practical approach—most programs need bug fixes and feature updates.

Program Derived Addresses (PDAs)

If programs are stateless and all data lives in accounts, how do programs create and manage their own accounts? They can't hold private keys. That’s where Program Derived Addresses (PDAs) come into play.

PDAs are special addresses that fall off the Ed25519 elliptic curve, meaning no valid private key exists for them. This cryptographic property allows programs to "sign" for these addresses without holding private keys, the runtime verifies the derivation internally.

PDA derivation works by hashing seeds plus program ID plus a "bump seed":

The algorithm tries bump values from 255 downward until finding one that produces an off-curve address. This first valid bump is the "canonical bump."

Why PDAs matter

• Deterministic addressing: Given the same seeds, you always get the same address. No need to store addresses separately.

• Program-controlled accounts: Programs can create accounts at PDAs they derive, and only they can sign for those PDAs.

• Key-value patterns: Seeds can encode relationships (user + token type → balance account), enabling mapping-like data structures.

Rent: Paying for State

Blockchain state isn't free. Every account takes up space on validators' disks, and that space has real costs. Different chains handle this differently. Ethereum charges gas for storage operations, but state persists forever once written, contributing to ever-growing state bloat.

Solana takes a different approach. There is something called “rent” where the network charges approximately 3,480 lamports per byte per year to keep data on-chain. In practice, all mainnet accounts must be "rent-exempt", holding at least two years of rent upfront:

For a typical token account (165 bytes), this works out to roughly 0.002 SOL.

But here's the key difference from other chains: closing an account returns the full rent deposit. This creates economic incentive to clean up unused state, something that doesn't exist in models where storage persists forever.

Cross-Program Invocations (CPIs)

Programs don't exist in isolation. A DeFi protocol might call the Token Program to transfer tokens, which might call the Associated Token Account Program. These Cross-Program Invocations are how Solana's ecosystem composes.

Two functions enable CPIs:

When you call invoke_signed with PDA seeds, the runtime verifies the derivation matches the expected address and grants signing authority for that call. This is how programs can control assets without holding private keys.

Important constraints:

• Maximum call depth of 5 (4 nested CPIs from the initial transaction)

• Signer privileges cascade through the call chain

• Compute budget is shared across all CPIs in a transaction

To learn more about accounts, check out the following:

• Accounts Overview: Complete guide to Solana accounts

• PDAs: Program Derived Addresses explained

• CPIs: Cross-Program Invocations guide

Part 4: Parallel Execution (Sealevel)

We've now covered all the foundational pieces: how transactions flow through the pipeline, how the sBPF VM executes bytecode, and how the accounts model stores state with explicit ownership.

Now we can finally answer the question we've been building toward: how does Solana actually achieve parallel execution?

We've hinted at it throughout: the Banking Stage scheduling non-conflicting transactions, accounts declaring owners upfront, transactions specifying which accounts they'll touch. These aren't separate features. They're all pieces of a single system called Sealevel.

Sealevel is Solana's parallel smart contracts runtime, and it's the core innovation that enables the SVM's throughput. Everything we've covered, the accounts model, the ownership rules, the upfront account declarations, exists to make Sealevel possible.

The fundamental insight is deceptively simple:

If transactions declare which accounts they read from and write to before execution begins, the runtime can identify non-overlapping transactions and execute them concurrently.

That's it. That's the entire trick. But making it work in practice required designing every other part of the system around this constraint.

The Rules of Parallel Execution

Sealevel's scheduling follows straightforward rules:

That's it. Reads don't conflict with reads. Writes conflict with everything.

This is why you must declare all accounts upfront in Solana transactions. It's not bureaucracy: it's the information the runtime needs to parallelize your transaction.

The Scheduling Algorithm

The Banking Stage implements Sealevel through account-level locking:

1. Transaction arrives specifying accounts with read/write flags

2. For each writable account: acquire exclusive lock

3. For each readable account: acquire shared lock (multiple readers OK)

4. If all locks acquired: schedule for execution

5. If any lock blocked: re-queue and try later

The current implementation uses 6 threads: 4 for non-vote transactions and 2 for vote transactions. Each thread maintains a queue ordered by priority fee (fee per compute unit) and arrival time.

A newer Central Scheduler architecture uses a single scheduling thread with a Prio-Graph algorithm, a lazily populated dependency graph that identifies conflicts through a look-ahead window. This improves scheduling efficiency for high-contention workloads.

Performance in Practice

Real-world throughput depends heavily on transaction mix. Simple transfers that touch unique accounts parallelize perfectly. Complex DeFi transactions that all hit the same liquidity pool create contention and serialize.

This is actually a feature: contention is localized. A surge in volume on one decentralized exchange doesn't slow down token transfers on a neobank, because they touch different accounts. This is fundamentally different from chains where all transactions compete for the same global throughput.

Why Sequential VMs Can't Simply Adopt This

You might wonder: why can't the EVM just add parallel execution?

The fundamental problem is that EVM state access is determined at execution time, not before. When you call a Solidity contract, there's no way to know which storage slots it will read or write until you actually run it. The contract might call another contract, which calls another, each accessing unpredictable state.

This "read-write oblivious" model makes safe parallelization impossible without speculation. Some newer chains implement "optimistic parallel execution", execute speculatively assuming no conflicts, then detect conflicts and re-execute sequentially when they occur. This works but adds complexity and overhead.

Solana's approach is different: conflicts are avoided, not resolved. By requiring upfront declaration, the runtime knows exactly what each transaction needs before execution begins. The constraint enables the optimization.

EIP-2930 introduced optional "access lists" to Ethereum for gas discounts, but they're not mandatory. Solana makes declaration mandatory and universal, that's the key difference.

The SVM Ecosystem: Beyond Solana Mainnet

The SVM isn't just Solana anymore. In June 2024, Anza introduced the SVM API, decoupling the execution engine from Solana's validator client. This modularization enabled entirely new use cases.

Eclipse: SVM on Ethereum

Eclipse launched in November 2024 as the first production SVM rollup on Ethereum:

Over 60 apps deployed at launch, including Orca. Eclipse raised $65 million to build this bridge, validating that the SVM has value independent of Solana's consensus layer.

SOON Network

SOON (Solana Optimistic Network) achieved alpha mainnet in early 2025 as the first "decoupled SVM" rollup. Unlike simple forks, SOON separates execution from consensus cleanly, implementing Merkle Patricia Tries for state management (different from Solana's AccountsDB). Target: 5K–600K TPS with Firedancer integration.

Sonic SVM

Sonic launched January 2025 as the first atomic SVM Layer-2 for gaming on Solana. Built by Mirror World Labs, it includes the HyperGrid Framework for spinning up custom SVM chains per game. Testnet processed 600+ million transactions from 2+ million monthly active wallets.

MagicBlock: Ephemeral Rollups

MagicBlock introduced "ephemeral rollups", temporary, on-demand SVM execution environments. Deploy contracts normally on Solana, then delegate specific accounts to MagicBlock when needing sub-50ms latency. Writes occur in the ephemeral session, then commit back to Solana.

Perfect for gaming and real-time applications where 400ms blocks are still too slow.

Firedancer: The Performance Breakthrough

Jump Crypto's Firedancer client may be the most significant SVM development. Written entirely in C with zero shared Agave components, it uses a tile-based architecture where each function runs on a dedicated CPU core with kernel-bypass networking.

These are synthetic benchmarks, but they suggest massive headroom beyond current mainnet performance.

Timeline:

• September 2024: Frankendancer (hybrid) on mainnet

• Breakpoint 2024: Full Firedancer in non-voting mode

• 2025: Full production release projected

Building on the SVM

We've covered the architecture, now let's get practical. If you want to start building on Solana, what do you actually need?

The Toolchain at a Glance

For most developers, the path is: Solana CLI + Anchor + Bankrun. That combination covers 90% of use cases.

Getting Started: The 5-Minute Setup

That's it. You now have a working Solana development environment, a starter program, test suite, and local validator integration ready to go.

From here, the Anchor Book walks you through building your first real program, and the Solana Cookbook provides recipes for common patterns you'll encounter.

Where to go deeper:

• Solana Developer Docs: Official documentation

• Anchor Book: Complete framework guide

• Solana Cookbook: Practical recipes and patterns

• Alchemy Solana APIs: RPC infrastructure and developer tools

Conclusion: The Architectural Bet

The SVM represents a coherent architectural vision: accept upfront constraints (explicit account declarations, stateless programs, complex transaction construction) to unlock parallelism, throughput, and localized fee markets. These constraints aren't incidental—they're the mechanism that enables the performance.

If you want to explore what's possible, Alchemy's Solana APIs give you access to Solana mainnet, devnet, and the broader SVM ecosystem from one platform. Start building and see for yourself.