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 C_eff = 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 C_eff = 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#

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·M passes.
• The floor imposed by the thread count on the uncontended remainder: roughly M / T passes.

Realized concurrency is then transactions-per-pass averaged over the makespan:

C_eff = M / makespan = M / max(p·M, M/T) = min(1/p, T)

This is the load-bearing result. It says Sealevel's effective parallelism is min(cores, 1/contention) — never more than the core count, and never more than the reciprocal of the write-contended fraction. A 16-core validator running a program where 20% of transactions write one shared account realizes C_eff = min(16, 5.0) = 5.0, not 16. Three-quarters of the silicon sits idle.

Monte Carlo verification#

We simulate the greedy scheduler directly: 512 transactions per slot, each declaring 3–6 accounts drawn from a 50,000-account background pool with a 15% write probability, plus a contended-account injection at rate p. 150 slots per configuration.

import numpy as np
rng = np.random.default_rng(20260629)
T, M, SLOTS, N_BG = 16, 512, 150, 50000

def schedule(txs, T):
    """Greedy Sealevel pass scheduler -> makespan."""
    remaining = list(range(len(txs)))
    passes = 0
    while remaining:
        locked_w, locked_r = set(), set()
        chosen, nxt = [], []
        for idx in remaining:
            if len(chosen) >= T:
                nxt.append(idx); continue
            rset, wset = txs[idx]
            conflict = (any(w in locked_w or w in locked_r for w in wset)
                        or any(r in locked_w for r in rset))
            if not conflict:
                chosen.append(idx); locked_w |= wset; locked_r |= rset
            else:
                nxt.append(idx)
        remaining = nxt; passes += 1
    return passes

# Inject: fraction p of txs write the single hot account -> realize C = min(T, 1/p)

The closed form holds to within 1.5% across the full contention range. The small over-shoot at low p (0.02–0.10) is the thread floor: when p·M < M/T the uncontended remainder, not the hot chain, bounds makespan, and C_eff pins to T=16. The collapse is dramatic and abrupt — throughput is essentially untouched until p ≈ 0.05, then falls off a cliff.

The sharding remedy#

The developer guides recommend state-sharding: replace one hot account with H sub-accounts (a counter array, a bucketed ledger) so that write contention spreads across H lock targets. Our closed form predicts the recovery threshold. Sharding divides per-shard contention from p to p/H; full parallelism returns when p/H ≤ 1/T, i.e. H ≥ p·T.

With p·T = 3.2, the model says H ≥ 4 restores parallelism; H = 5 reaches 95%, H = 10 is essentially full. The remedy is quantitatively cheap and exactly the one practitioners describe — but the quantity of sharding required is not a rule of thumb, it is a function of your measured contention: shard to H ≥ p·T.

Cross-checking with H3: order independence#

We tested FIFO versus greedy-maximum-independent-set selection. Both yielded identical makespans within simulation noise, because the hot-account clique is unavoidable: every scheduler must spend p·M passes on it regardless of how it packs the remainder. This supports H3 — the collapse is structural, not an artifact of a naive selection policy. (The sharding escape works precisely because it breaks the clique.)

Discussion#

• Robust: The closed-form ceiling C_eff = min(T, 1/p) and its ≤1.5% match to simulation. This result does not depend on the account-popularity distribution or write-fraction assumptions — those only affect which p a real program experiences, not the relationship between p and parallelism.
• Robust: The sharding recovery threshold H ≥ p·T, confirmed across the sweep.
• Preliminary: The absolute p a specific Solana program experiences. Public tooling (e.g. the open-source svm-conflict-analyzer, which reconstructs account-lock conflicts from block data) can measure p on mainnet, but we did not run it here — our p values are injected, not observed.
• Not supported: Any claim that real mainnet programs operate at the 100% baseline. The Vex operational data is CEX-based and silent on this. Realistic p for, say, a leading DEX's core pool is widely believed to be high (hence Jito bundle economics and priority-fee auctions forming around hot accounts), but that is qualitative — our model supplies the curve, not the operating point.

The practical synthesis: measure p, then shard to H ≥ p·T. A program at p=0.20 on a 16-core validator needs five shards, not "a few." A program that can't reduce p below ~0.5 on its hottest account is, by the closed form, capped at C_eff ≈ 2 regardless of how many cores the validator throws at it — parallelism that an EVM chain with better state-partitioning could match.

Limitations#

This study models Solana's account-lock scheduler, not mainnet. No validator data, no svm-conflict-analyzer run, and no on-chain lock logs were used — p is an injected parameter, not a measured one, so the absolute operating point of any real program is unknown here. The model treats write-lock sets as known at submission (true for Sealevel) but ignores priority-fee ordering, Jito bundle atomicity, and per-pass thread assignment heuristics that may alter makespan at the margin; it also holds the candidate set fixed per slot rather than streaming transactions across slots. Core count T, slot length, and per-tx account counts are public-document parameters that vary by validator hardware and load. Our Vex trading logs come from centralized venues (Hyperliquid, Binance) and are cited only as a latency motivation; they carry no Solana lock information and should not be generalized to other exchanges or to on-chain venue economics without re-validation. The closed form's strength — that it is independent of the popularity distribution — is also its weakness: it cannot predict your program's p. Measure that on-chain first.

Conclusion#

Sealevel's parallelism is neither the marketing number (T) nor a myth. It is min(T, 1/p) — bounded by cores from above and by the reciprocal of your write-contention from below. The same machinery that delivers 16× throughput on independent transactions delivers 1× the moment a single account becomes the write bottleneck, and the recovery prescription is precise: shard until the per-shard contention falls below 1/T. For trading-program designers, the actionable rule is to treat any shared mutable account as a throughput tax of T× and to measure p on-chain before sharding blindly. The frontier-grade question is not whether Solana parallelizes, but which account is paying the serial tax — and the closed form tells you exactly how much it costs.

References#

1. Kalankhodzhaev, A. "How to Avoid Write Lock Contention in Solana — a Developer's Guide." HackerNoon, Sept 2025. (Patterns: transaction optimization, state sharding, PDAs; Agave vs. Firedancer scheduling.)
2. "The Declared State: Sealevel Parallelism and the AI Agent Execution Contract on Solana." blokz.dev, June 2026. (400 ms slots; explicit account declaration; read/write lock modes; 16-core parallel dispatch.)
3. sabijuraa/svm-conflict-analyzer — open-source tool that reconstructs Solana account-lock conflicts from block data for empirical p measurement.
4. Vex Capital internal trading logs (Hyperliquid, Binance), June 2026 — operational latency context only.