How Solana Runs Transactions in Parallel (Sealevel)

Why this matters

Solana's runtime, Sealevel, executes non-conflicting transactions in parallel. Two txs that touch disjoint accounts run on different cores; two txs that touch the same account serialize. This is why Solana programs must declare account access in advance — Sealevel uses that declaration to compute the schedule. Protocol design on Solana is partly a parallelism game: protocols that fan out across many accounts can scale far beyond what serial execution allows.

Demo

Example: 1000 users swapping on 1000 different Orca pools execute in parallel. 1000 users swapping on the same Phoenix order book all serialize on the order book's accounts.

Try it yourself

1. Read the Sealevel design doc. Identify the parallel scheduler's input (account access lists) and output (execution schedule).
2. Compare two protocol designs: AMM with one shared account vs. AMM with per-pair accounts. Which parallelizes?
3. Discuss the cost of contention: when many users target the same hot account, throughput collapses to serial speed.

References

• Sealevel docs
• Solana runtime