Sealevel is Solana’s parallel execution runtime: it runs many transactions at the same time on different CPU cores, because every Solana transaction lists in advance which accounts it will read and which it will write. Transactions that touch different accounts never wait for each other, while two transactions that write the same account run one after the other. On November 10, 2026, Solana’s public RPC showed about 428 non-vote transactions per slot, every 213 milliseconds on average, all scheduled this way.
Key Facts
- What it is: the execution layer of Solana validators, described by the Solana team on September 8, 2019 as processing “thousands of smart contracts” in parallel.
- Core rule: a transaction must declare every account up front, marked as read-only or writable.
- Locks: many transactions can read one account at once; only one at a time can write it.
- Account limit: up to 64 accounts per transaction (SIMD-0385 table of current limits).
- Block budget: about 50M compute units per 200ms block after SIMD-0525, with a separate cap for any single writable account.
- Default threads: Agave’s block-production stage runs 4 worker threads by default (Agave source, banking_stage).
How Sealevel Decides What Runs in Parallel
Ethereum’s EVM executes transactions one by one, because a contract can touch any storage it likes and nobody knows in advance what it will change. Solana flips this. A Solana program owns no state inside itself; state lives in separate accounts, and the transaction message names each of them. Before execution, the validator already knows the full read and write set.
With that list, the scheduler groups transactions so that no two in the same batch write the same account. A swap on one pool and a transfer between two wallets touch different accounts, so they run side by side. Two swaps on the same pool both write the pool’s accounts, so they queue. The split between programs and accounts is covered in Solana programs vs Ethereum smart contracts.
| Sealevel (Solana) | EVM (Ethereum) | |
|---|---|---|
| Accounts known before execution | Yes, required | No |
| Default execution | Parallel where accounts do not overlap | Sequential |
| What forces ordering | Two writes to the same account | Every transaction |
| Cost of a busy contract | Its accounts become a queue | Whole block is a queue |
Read Locks, Write Locks and Hot Accounts
A read lock is shared: a thousand transactions can read the SOL/USDC price account in the same moment. A write lock is exclusive: while one transaction writes an account, every other writer waits. This is where parallelism breaks down in practice. During a memecoin launch, thousands of buyers write the same bonding curve or pool account, and the runtime has to run those trades in a line.
Solana adds a second guard: a cap on how many compute units any single writable account can use per block, set below the block limit. When a hot pool hits that cap, extra trades on it wait for the next block even if the block still has room. That is why a busy launch can feel slow while the rest of the chain keeps moving. How compute units are counted is explained in Solana compute units explained.
Why Sealevel Matters to Traders
- Priority fees are local. Because congestion forms around specific accounts, you mostly compete with other traders on the same pool, not with the whole network. Details in Solana transaction fees and priority fees.
- Failed swaps cluster on hot tokens. The first minutes of a launch concentrate writes on a few accounts, so retries and slippage errors pile up there.
- Routers split work. Aggregators like Jupiter can route through several pools, which spreads writes and helps a large order fill.
Limits of Parallel Execution
Sealevel only helps when work is spread across accounts. A single popular program that keeps all users in one writable account turns into a sequential bottleneck, and developers have to shard state on purpose. Listing every account up front also makes transactions larger, which is one reason Solana added address lookup tables and, in September 2026, a bigger 4,096-byte transaction format. Finally, parallel execution does not mean unlimited speed: block compute limits, network bandwidth and the 64-account cap still set the ceiling. Real throughput is visible on Solscan block pages, where you can see how many transactions each block carried.
Sealevel and a $DOLAN Trade
DOLAN Duck ($DOLAN) is a fair-launch SPL token with a fixed 98.3M supply and about 10,700 holders. Sending $DOLAN between two wallets writes only those two token accounts, so it runs in parallel with almost everything else on Solana. A swap on a DOLAN pool writes that pool’s accounts and lines up behind other trades on the same pool. Liquidity spread across more than one pool reduces that queue; how pool depth works is in what liquidity means on a Solana DEX.
Sealevel is Solana's runtime for executing transactions in parallel. It works because every transaction lists the accounts it will read and write before it runs.
The scheduler places transactions that do not write the same account into the same batch and runs them on separate threads. Conflicting writers run in sequence.
Sealevel is one part of it. Ethereum executes transactions sequentially by default, while Solana executes non-overlapping ones at the same time.
Thousands of buyers write the same pool or bonding curve account. Write locks on that account force those trades into a single line.
Up to 64 accounts per transaction under the current limits listed in SIMD-0385.
Yes. They should spread state across many accounts, because one shared writable account removes the benefit of parallel execution.