Write-Lock Contention in Solana Trading Programs: Measuring Real Sealevel Parallelism

Abstract Solana markets its throughput on parallel execution: the Sealevel runtime declares every account a transaction will touch, builds a dependency graph across the pending pool, and dispatches non-conflicting transactions onto parallel worker threads. On paper, a 16-core validator can settle 16 independent transaction streams per 400 ms slot. In practice, a single hot account — a popular AMM pool, a token mint, the wrapping program, a SYSVAR — silently forces those streams back into a serial chain. We model Sealevel's account-lock scheduler as a greedy graph-coloring problem and derive the realized parallelism ceiling Ceff = min(T, 1/p), where T is the thread count and p is the fraction of transactions writing a contended account. A Monte Carlo simulation validates this closed form to within 1%, and a shard-count sweep confirms that splitting a hot account into H ≥ p·T sub-accounts restores near-full parallelism. The implication for trading-program designers: Sealevel's theoretical parallelism is real but fragile, and it is destroyed by the most ordinary design choice — one shared mutable account. Hypotheses - H1 (high confidence): A single write-contended account collapses realized parallelism far below the core count, following Ceff = min(T, 1/p). - H2 (high confidence): State-sharding the hot account restores parallelism, with full recovery at shard count H ≥ p·T. - H3 (medium confidence): The collapse is order-independent at the batch level — FIFO and greedy-maximum packing yield the same makespan, because the serial chain on the hot account is unavoidable regardless of selection order. Data Provenance | Quantity | Source | Type | Reliability | |---|---|---|---| | Realized concurrency, makespan, shard recovery | Monte Carlo simulation (this study) | Simulated | UNRELIABLE (model output, not mainnet measurement) | | Core count T=16, slot=400 ms, M=512 txs/slot | Public Solana architecture documentation | Parameterized | UNRELIABLE (varies by validator & load) | | Write-fraction per tx, account-population shape | Modeling assumption | Assumption | UNIDENTIFIABLE (no per-tx lock log in our data) | | Closed form Ceff = min(T, 1/p) | Derivation (Section: Analysis) | Analytical | RELIABLE (exact given the scheduler model) | | Operational latency motivation | Vex Capital trading logs (Hyperliquid/Binance) | Live trades | N/A — motivational only; does not measure Solana contention | Collection method statement: All quantitative results in this study are produced by simulation (Monte Carlo modeling in Python), not from real-time feeds, API queries, or a backtest on live data. No on-chain measurement was performed. Critical caveat: No measurement in this study comes from a Solana validator. The analysis is a first-principles scheduling model parameterized with publicly documented architecture constants. The Vex trading system executes on centralized venues (Hyperliquid, Binance) and is cited only as a latency-sensitivity motivation; its funding and spread observations are not Solana lock data and should not be generalized to on-chain venue economics without separate validation. Where the literature gives divergent numbers, we treat the closed form — not the simulation's absolute TPS — as the load-bearing result. Background: Sealevel's Declarative Lock Model Sealevel inverts the EVM's execution contract. An Ethereum transaction discovers the state it touches dynamically, mid-execution; the EVM runs serially because the next transaction's input state cannot be known until the current one finishes. Solana requires every transaction to declare, at submission, the complete list of accounts it will read or write. The runtime reads that declaration before any computation begins, constructs a conflict graph, and routes independent transactions onto parallel threads. Any access to an undeclared account fails the transaction — the contract is binding. This is the source of both Solana's throughput and its fragility: - A read lock is shared: many transactions can read the same account concurrently. - A write lock is exclusive: two transactions writing the same account — or one writing while another reads — must serialize. They cannot share a thread in the same pass. The honest failure mode is not that parallelism is absent, but that it is concentratable. If 512 transactions all need to write account 0xHOT, no scheduler, however clever, can execute more than one of them per pass. The dependency graph has a clique of size 512 on that single node. Analysis The realized-parallelism ceiling Consider a slot of M transactions on T threads. Let p be the fraction of transactions that write a single contended account. Those p·M transactions form a serial chain: exactly one settles per pass, because each holds an exclusive lock the next needs. The remaining (1−p)·M non-contending transactions fill the leftover thread capacity. The makespan (number of passes) is therefore the larger of two terms: - The serial hot-account chain: p·