Solana's SIMD-0649 Died in Review. The Batch Boundary Is Still Open.

On September 25, a pull request carrying SIMD-0649 was closed without merging. No announcement. No thread. No governance theater. Just a closed PR in a repository most SOL holders will never open.

That is the entire news event, and most people will read it backwards.

Signal over noise. Always. The story isn't that Solana's transaction-ordering reform died. The story is that the reform, as drafted, would not have solved the problem its own name implied. SIMD-0649 proposed a non-increasing priority rule inside entry batches. What it delivered — on paper — was an ordering audit. Not a fairness guarantee. Not an anti-MEV mechanism. Not a slot-level priority queue.

That gap is where the next year of Solana MEV debate will live. And the gap is documented, because the reviewers who killed it wrote down precisely why.

Solana has no public mempool in the Ethereum sense. No visible queue where searchers watch pending transactions and bid for position. The leader — the validator scheduled to produce a given slot — receives transactions, orders them, and packs them into entries, which group into entry batches, which chunk into FEC sets of shreds. Roughly 400 milliseconds of absolute scheduling discretion per slot, repeated indefinitely.

For years the defense was speed. Solana is fast, fees are low, and there is no mempool to front-run because there is no observable ordering layer. That defense held commercially. It did not hold under scrutiny. By 2025, DEX aggregators were publishing slippage attribution, searchers were comparing realized execution against theoretical execution, and the question stopped being 'is Solana fair?' and became 'who decides the sequence, and can anyone verify it?'

SIMD-0649 was the answer attempt. The version circulating on social media was not the version in the repository. The improvement document track — SIMD — is Solana's off-chain governance channel. Proposals move from draft to discussion to client implementation to mainnet behavior. That last step is the one that matters, and the one that almost never arrives on schedule.

Here is the rule in plain terms. Inside one entry batch, every non-exempt transaction must appear in non-increasing priority order. Priority isn't a mystery number — it's a ratio: the reward the leader receives for including the transaction, divided by the transaction's requested cost under the pre-execution cost model. The reward bundles the priority fee with the non-burned portion of the base fee. The burned portion still counts as cost. That is the entire scoring function.

Enforcement is where it gets interesting. Validators already replay blocks. SIMD-0649 would have them compare ordering during replay, and if the batch violates the rule, mark the block invalid. Real teeth. Code doesn't care about your roadmap deck; it cares about whether the state transition validates.

That is also where the teeth end.

The proposal is explicit about its non-goals. It does not decide which transactions enter the block. It does not build a single priority queue spanning the slot. It does not prevent preferential treatment, MEV, or slippage. Three sentences that most coverage will quietly omit.

Which leaves the leader holding four distinct powers. Selection: which transactions enter at all. Partitioning: how those transactions are grouped into batches. Boundary placement: where each batch ends. Deferral: pushing a transaction into a later batch. The rule constrains none of the four.

Concrete case. Batch A holds a low-priority transaction. Batch B holds a high-priority transaction. Both batches satisfy non-increasing order internally. The rule is satisfied. The high-priority transaction in batch B is not promoted ahead of the low-priority transaction in batch A merely because its score is higher — cross-batch ordering sits outside the scope entirely. A leader wanting to advantage one transaction over another achieves it by placing them in different batches. Cost of that maneuver: near zero.

Worth stating plainly: batch boundaries are chosen by the leader, at the leader's discretion, with no protocol-level constraint on where they fall. A batch containing one transaction satisfies the rule trivially. A batch containing one transaction also makes the rule meaningless.

The draft anticipated the obvious counterattack. Shrink batches to minimum size and the rule becomes decorative, so the proposal requires at least two FEC sets per batch — roughly 64 shreds — except for the final batch. Reasonable instinct. Unmeasured execution. Neither the proposal nor the review published a distribution of how often current leaders actually produce batches smaller than that. No breakdown by scheduler, no breakdown by client, no breakdown by market condition. No sensitivity testing across different minimum sizes. On a surveillance desk, that omission is the whole question: the constraint may bind on almost no blocks, or on a meaningful share of them. Nobody in the thread knows which. Neither does the proposal.

Then the client problem. The draft targets roughly two-FEC-set batches on both Agave and Firedancer. Agave is the incumbent mainnet client. Firedancer is Jump's high-performance challenger, and its entire engineering identity is latency. Waiting for a complete batch before evaluating order is friction. Back in August, the discussion surfaced exactly that concern — replay latency on partially received data. The revised approach lets validators compare transactions as they arrive and invalidate the block later if the batch ultimately fails. Elegant. Also unmeasured under low throughput, where waiting for two FEC sets may add broadcast latency. No latency number appears in the source material. That isn't a footnote. It's the difference between a rule that ships and one that dies in review a second time.

One detail deserves attention, because it reveals how brittle consensus-side rules are. Cross-client agreement requires integer arithmetic to produce identical results, so the draft leans on a one-unit guard to keep Agave and Firedancer computing the same priority value. If two clients disagree by a single unit, they disagree about block validity, and that is a consensus split, not a bug report. Ordering rules are consensus rules wearing a market-structure costume.

Then the self-payment hole. Priority fees return to the leader. A leader can pay itself a priority fee to advantage its own transactions. The burned base fee remains a genuine cost, but the ordering test does not police self-dealing, and the draft acknowledges as much. The honest framing, then, is auditable ordering — not fair ordering.

A rule that actually bounded ordering would need to reach across batch boundaries, or constrain batch formation itself. Neither appears in the draft. The reviewers asked for precisely that insight, plus the batch-size data that would have justified a minimum threshold. What came back, per the record, was not enough.

I have seen this exact texture before. In early 2017 I spent three weeks reversed into 0x's exchange contracts, because the ICO noise was drowning out the code and someone had to read the state transitions. I found a re-entrancy vulnerability in the token swap logic before public launch. The documentation said one thing; the execution path said another. SIMD-0649 has the same anatomy. The headline says priority ordering. The specification says priority ordering within a batch. Those are not the same promise.

Uniswap V2 taught me the second half of the lesson in 2020. Two weeks on the bonding curve mechanics, and the finding wasn't that impermanent loss existed — everyone knew that. It was that nobody had modeled it in real time for the LPs actually providing liquidity. The gap between the primitive and the practitioner is where risk accumulates, quietly.

Terra taught me the third version, across 72 hours of tracing the UST de-peg minute by minute in May 2022. The algorithm didn't fail because it was naive. It failed because it assumed stress would arrive in a shape the design had rehearsed. Ordering rules fail the same way. They assume competition arrives in a shape the rule can see. Sleep is for those who can.

The contrarian read isn't that SIMD-0649 failed. It's that it succeeded — as a governance document. It forced four facts into the public record that the Solana MEV conversation has spent years avoiding. First, leader discretion is structural, and it can now be named precisely. Second, batch boundaries are a first-class arbitrage surface, not an implementation detail. Third, Firedancer's latency targets function as an effective veto over ordering rules. Fourth, priority fees are leader revenue, and self-payment cannot be fixed inside this design.

Compare Ethereum and the contrast sharpens. Ethereum externalized ordering to builders through PBS and MEV-Boost, then spent years learning that builders can collude. Solana kept ordering inside the leader and is now learning that the leader can arbitrage its own batch boundaries. Neither architecture solved MEV. Both localized the trust. The only real difference is which party you are required to believe.

What the closed PR actually tells you is that Solana's governance process worked — slowly, and at the cost of a narrative bump. The chart is a symptom, not the cause. SOL pricing carries no meaningful signal here, because nothing changed at the protocol level. The price reaction, or absence of one, is noise around a repository event.

The real market question is downstream and unsolved. If searchers migrate from intra-batch front-running to cross-batch and batch-boundary strategies, DEX users get no measurable slippage improvement while the ecosystem advertises an ordering win it did not deliver. That mismatch between narrative and mechanism is where reputational damage accumulates. Not in the validator set. In the expectations.

Watch three signals. Whether a revised SIMD constrains batch boundaries or introduces cross-batch ordering — that determines whether the rule has substance. Whether empirical batch-size distributions arrive, broken down by scheduler, client, and market condition. And whether Firedancer commits publicly to the check. Until all three land, treat 'Solana is fixing MEV' the way you'd treat any unmerged specification: as a draft, not a product.