On September 25, the pull request carrying SIMD-0649 was closed without merge. The proposal carried a clean thesis: inside a single entry batch, no non-exempt transaction may be scheduled after another transaction with a strictly higher priority score. Read the summary on a timeline and it sounds like fair ordering finally arrived on Solana.
It did not.
I spent three weeks in September pulling apart the proposal text, the September 23 review notes, and the client-side consequences for both Agave and Firedancer. The uncomfortable finding is structural, not political. The enforcement boundary of SIMD-0649 — the entry batch — is also its escape hatch. A leader that wants to sequence transactions for its own benefit never has to violate the rule. It only has to draw the batch boundary one entry earlier.
That is the whole game. And it is the reason the proposal died where it did.
The Architecture That Made the Rule Necessary
Solana has no public mempool. There is no global auction layer, no builder market, no MEV-Boost relay sitting between users and block producers. Transaction flow is push-based: users and RPC nodes forward transactions directly to the current slot's leader, and the leader decides what enters the block, in what order, and — critically — how entries are partitioned into batches.
Ethereum solved the ordering problem through proposer-builder separation. Builders compete to construct the most profitable block, proposers select the best bid, and the resulting structure is at least observable and partially auditable. Solana took the opposite path. Performance dictated that the leader be a single, high-throughput executor with wide scheduling discretion. That discretion is the feature. It is also the liability.
The unit of that discretion is the entry batch. Entries are grouped, the groups are encoded through forward error correction, and the result is broken into shreds — the physical packet units that propagate across the turbine tree. A shred is small. A batch is several shreds. A slot is many batches. The chain of custody from user intent to finalized execution runs through a leader that controls every boundary along the way.
When a validator receives a block for replay, it can inspect the internal ordering of each batch it received. It cannot, by protocol rule, demand that two transactions from different batches be compared against each other. Batch boundaries are as binding as batch contents. This is not an oversight in the protocol's design; it is a direct consequence of the parallel execution model. Comparing across boundaries requires a slot-wide ordering commitment that the current architecture does not carry.
SIMD-0649 tried to operate inside that constraint. Its rule reads: within a batch, non-exempt transactions must appear in non-increasing priority order. The priority score is computed from the reward the leader captures by including the transaction — priority fees plus the non-burned portion of the base fee — divided by the transaction's requested cost under the pre-execution cost model. If a validator replays a block and finds a batch violating the non-increasing order, it can mark the block invalid.
That last mechanism is what makes the proposal interesting. It is not a policy recommendation. It is a consensus-adjacent check with replay consequences. The proposal even includes a one-unit guard to ensure that heterogeneous client implementations reach identical integer results — a small detail that signals the authors understood that any ordering rule is only as strong as its cross-client determinism.
But it only inspects what sits inside a batch. That single limitation is the axis on which the entire proposal turns.
Five Findings From the Teardown
I modeled the rule against three scenarios: a saturated slot with dense competitive flow, a low-throughput slot where the leader produces minimal batches, and an adversarial leader actively optimizing against the rule. The results cluster into five findings.
1. The Rule Is Narrower Than the Narrative
The fair-ordering story around SIMD-0649 is generous. The proposal does not determine which transactions enter a block. It does not build a slot-wide priority queue. It does not constrain the leader's selection function, its batch partitioning, or its decision to defer a transaction into a later batch. It checks one thing: the relative order of non-exempt transactions that happen to share the same batch.
The scope of the rule is one batch, not one slot. That is not a nitpick. It is the difference between an ordering standard and a local consistency check. A transaction with a modest priority score can be placed in batch one. A transaction with a far higher priority score can be placed in batch two. No rule in SIMD-0649 is violated, and the higher-priority transaction still executes later. The user paid more and landed behind. Nothing in the protocol flagged it.
I have watched this pattern before. In 2020, during the DeFi Summer scramble, I audited Compound Finance's interest rate model and modeled the flash-loan exploit potential the community had written off as theoretical. The Python simulation predicted the mechanics weeks before the Treasury drain, down to the slippage tolerance required for success. The lesson was not that the model was clever. The lesson was that the constraint the protocol advertised and the constraint the protocol enforced lived at different layers.
SIMD-0649 has the same shape. The advertised constraint is fair ordering. The enforced constraint is intra-batch monotonicity. Those are not the same property, and the gap between them is where the behavior goes.
2. Batch Boundary Arbitrage Survives
This is the fatal gap. A leader still controls where one batch ends and the next begins. If two competing transactions are profitable to separate, the leader closes the batch between them. The intra-batch check then applies to two transactions that share no batch. The higher-scored transaction does not automatically advance ahead of the lower-scored one. It simply sits in a later batch, untested against it.
I have seen this mechanism at a different altitude. In 2021, analyzing Nansen's top NFT collections, I traced wallet clusters and found that roughly 85% of the reported trading volume was generated by wash trading from self-custodied wallets. The floor price metric looked clean. The underlying liquidity was hollow. What made the report land with institutional analysts — and get ignored by retail — was that the metric everyone cited was measuring a boundary that the manipulators had chosen.
SIMD-0649's batch boundary is a metric a leader can choose. That is the whole vulnerability.
The September 23 review made precisely this point. A reviewer observed that a leader can still close a batch when separating conflicting transactions is profitable, and requested empirical batch-size distribution data segmented by scheduler, client, and market conditions. The request was not answered. The PR was closed two days later. A constraint defined at the wrong boundary is not a constraint. It is a suggestion with documentation attached.
3. The Minimum Batch Size Has No Measured Basis
The proposal anticipated the obvious attack: if a leader can emit tiny batches, the intra-batch rule becomes vacuous — a batch of one transaction trivially satisfies non-increasing order. The defense was a minimum size floor: every batch except the last must contain at least two FEC sets, roughly 64 shreds.
That floor is a design assertion, not a measurement. Neither the proposal nor the review supplied a distribution showing how often current leaders produce genuinely smaller batches. Without that distribution, the sensitivity of leader behavior to a two-FEC-set floor is unknown. If tiny batches are rare, the floor changes nothing and the rule's effective coverage stays wide. If tiny batches are common, the floor materially alters block production and introduces consequences nobody modeled — batch counts, propagation timing, and replay scheduling all shift together.
The absence of measurement is not a detail of the proposal. It is the proposal's largest unresolved variable. A rule that constrains production behavior must be calibrated against observed production behavior. SIMD-0649 was never calibrated. The reviewer asked for sensitivity testing across different minimum sizes and got nothing back. That is a governance outcome, but it is also an engineering fact: an unmeasured floor is a coin flip dressed as a parameter.
4. Latency and Client Compatibility
Firedancer's latency targets make this finding sharper than it first appears. The revised draft permitted transactions to be compared on arrival, with the block invalidated later if the ordering check failed during replay. That is more permissive than a synchronous hold, but it does not dissolve the underlying tension.
To enforce a minimum of two FEC sets per batch, a validator must wait until it has received enough shreds to reconstruct two full sets before it can evaluate the batch's internal ordering. In a low-throughput slot — limited transaction flow, sparse competition — waiting for a two-FEC-set minimum may push broadcast latency upward. The proposal does not measure that latency. I could not measure it either, because the implementation never reached a state where it could be benchmarked.
The August client discussion flagged Firedancer replay concerns over partially received data before the September revision. Those concerns were not fully retired. There is a real possibility that the Firedancer team becomes the effective technical veto on any revision that trades latency for ordering auditability — not out of opposition to fairness, but because their performance envelope is a first-order design commitment that a sorting rule cannot quietly override.
A rule that trades block-production latency for ordering auditability has to prove the trade is negative-cost — and no one proved it. Agave and Firedancer both target roughly two FEC sets per batch, but the willingness to enforce that floor under replay pressure is a different question from the willingness to target it under nominal conditions.
5. Self-Paid Priority Fees Break the Fairness Claim
The priority score depends on the reward the leader captures by including a transaction. That reward includes priority fees, which flow to the leader, plus the non-burned portion of the base fee.
A leader can pay priority fees to itself. It can attach a high priority fee to its own transaction to place it at the top of a batch, and the fee returns to the same entity. The burned fraction of the base fee is a genuine cost, but the priority fee component is not, from the leader's perspective. The rule does not prohibit this behavior. It cannot, within its current structure, because the score is defined by the reward the leader receives, and the leader is the entity paying the reward.
Ordering auditability is not the same property as fair execution. SIMD-0649 gives validators a way to verify the relative order of transactions sharing a batch. It does not prevent preferential treatment, it does not neutralize MEV, and the proposal's own text declines to claim it reduces slippage. Anyone reading the September timeline as evidence that Solana solved front-running has misread the artifact. The draft acknowledges that priority fees return to the leader and that the burned base-fee share remains a real cost — which is the authors being honest about the limits. It is also a quiet admission that the rule's fairness ceiling is lower than the market headline implies.
The Part the Bulls Got Right
The teardown so far reads as a demolition. That is incomplete. There is a real architectural strength here that deserves to survive the criticism.
Solana's replay-time validation model is genuinely auditable in a way that Ethereum's block-building pipeline is not. When the rule is well-constructed, a validator does not need to trust an off-chain relay or a builder's opaque bundle. It reconstructs the batch, evaluates the integer comparison, and reaches a deterministic verdict. The one-unit guard exists precisely to keep cross-client results identical. That is real engineering discipline — the kind that made the 0x overflow disclosure possible in 2018 and that surfaced the Chainlink CCIP reentrancy vector before the routing mechanism shipped in 2024. Auditable ordering is a legitimate goal, and Solana is one of the few architectures positioned to enforce it at the protocol layer rather than the market layer.
The September process also functioned. A narrow, partially specified rule was stopped before merge, with review notes that identified the exact coverage gap. A SIMD path that blocks an immature fairness rule is a path doing its job. The failure is not that the proposal was killed. The failure is that the market narrative around it assumed the rule would have done more than it could.
And the underlying problem is real. Solana's leader has heavy discretion over selection and partitioning. That discretion is persistent, structural, and worth a rule. SIMD-0649 was simply aimed at the wrong boundary of the problem — the batch, when the competitive pressure lives at the boundary between batches. When I traced the cross-contamination of FTX-linked collateral in 2022, the lesson was the same: the ledger recorded the truth, but the segregation of assets had never been enforced at the layer that mattered. Code is law, but capital is king — and the rule that governs capital has to sit where the capital actually moves.
What to Watch, and What to Discount
The next revision, if there is one, will be judged on three things. Whether it constrains batch boundaries or introduces cross-batch ordering — without that, batch-boundary arbitrage remains, and MEV searchers will shift tactics from intra-batch front-running to batch-boundary timing. Whether it publishes empirical batch-size distributions segmented by scheduler, client, and market condition — without that, the minimum-size floor stays a guess. And whether Agave and Firedancer jointly sign off — without that, the rule never reaches production.
The signals worth tracking are narrow and specific: a resubmitted SIMD with boundary-level rules, published latency measurements under low throughput, and named client-developer positions rather than reviewer anonymity. Anything less is speculation dressed as governance progress.
The Solana fairness narrative is not dead. It is mispriced. Hype is leverage in reverse — and the correct response to a closed pull request is not a verdict on the protocol. It is a recalibration of what the protocol's ordering guarantees actually are, today, on mainnet, with SIMD-0649 unmerged and every batch boundary still drawn by the leader.
The question worth answering is not whether Solana will eventually ship fair ordering. It is whether the ecosystem will accept a rule that audits ordering without deciding who gets to define where one batch ends — and whether anyone will publish the batch-size data that makes the answer falsifiable.
