On September 25, a pull request closed on the Solana repository. No merge. No mainnet activation. The proposal was SIMD-0649, an attempt to constrain how Solana leaders order transactions inside their blocks. The public framing was "fair ordering." The diff was narrower. The rule checks one thing: within a single entry batch, non-exempt transactions must appear in non-increasing priority order. It does not decide which transactions enter the block. It does not build a slot-level queue. It does not touch the boundary between one batch and the next. Every exploit is a lesson paid for in real time, and this one was paid before a single byte of mainnet code shipped. That is the cheap way to learn it. Price barely moved. It shouldn't have. But if you route flow into Solana DEXs, the reason the PR closed matters more than the PR itself.
Start with the machine. Solana has no public mempool. Transactions arrive at the current leader, typically through a forwarding path, and the leader decides inclusion and position. The ledger is built from entries. Entries group into entry batches. Batches encode into shreds — the packet units validators gossip and reconstruct — and shreds organize into FEC sets, forward-error-correction groups that let a validator recover block data when pieces go missing. The batch is not an abstraction. It is a physical container with a defined byte structure. The seam between batches is where scheduling discretion lives.
Ethereum handled this differently. Proposer-builder separation and MEV-Boost split the roles: builders assemble, proposers select. Solana kept it inside the leader. That is the trade. Sub-second slots, low fees, high throughput, no public mempool — the whole stack depends on the leader holding wide scheduling latitude. Latitude is power. Power meets a fee market, and you get extractable value.
Priority fees are Solana's express lane. A user attaches extra payment to raise inclusion odds. SIMD-0649 defined a priority score: the reward the leader receives for including a transaction, divided by that transaction's requested cost under a pre-execution cost model. The reward includes the priority fee plus the non-burned share of the base fee. Burned base fee still costs the user and pays the leader nothing. Hold that thread.
The exemptions matter as much as the rule. Vote transactions and a defined set of system-level messages sit outside the ordering test, because enforcing priority order on consensus-critical traffic would break block production. That carve-out is correct. It also means the rule's coverage is smaller than its name by design, and any honest measurement of its effect starts by subtracting the exempt mass.
Two clients have to agree on all of this. Agave, the incumbent, and Firedancer, Jump's performance client, both target batches of roughly two FEC sets. Identical integer results across clients are not optional. A rounding disagreement between Agave and Firedancer is a fork, which is why the spec carries one-unit-guard style constraints.
Then the arithmetic. The requested cost of a transaction is computed before execution, and the score divides reward by that number. Pre-execution cost estimates are approximations. Two clients that approximate differently produce different scores, different orderings, and different validity verdicts on the same block. Consensus rules that depend on floating economic quantities live one rounding error away from a partition.
The mechanism itself is small. Replaying validators recompute priority scores and compare order within each batch. A block that violates non-increasing priority can be invalidated. Enforcement is retroactive and cheap to check. The interesting part is the non-goals.
First, inclusion. The leader still selects which transactions make the block. The rule is silent on that.
Second, batch boundaries. The leader decides where one batch ends and the next begins. A high-priority transaction in batch N+1 does not jump ahead of a low-priority transaction in batch N just because its score is higher. Batch-boundary arbitrage survives untouched. A searcher who wants to front-run doesn't have to beat a competitor inside one batch. It has to land in an earlier batch than its victim. That is a coarser instrument, and coarse instruments are easier to hit. The review caught it: a leader can still close a batch whenever separating conflicting transactions pays better than keeping them together.
What does that leave the searcher? A cheaper problem. If intra-batch front-running gets expensive, the same profit moves one batch earlier, where no rule applies. Strategies adapt faster than specs merge. The rule constrains only the case where two competing transactions share a batch — and the entire design bets that meaningful competition lands in one batch often enough to matter. That bet is unmeasured.
Third, minimum batch size. To stop a leader from gutting the rule with tiny batches, the draft requires at least two FEC sets — roughly 64 shreds — per batch, except the last. Sensible shape. No data. Neither the proposal nor the review published how often current leaders actually produce smaller batches. No sensitivity test across different minimum sizes. Nobody can say whether the requirement reshapes one percent of blocks or thirty.
Fourth, self-payment. The leader can pay itself priority fees to favor its own transactions. The rule doesn't stop it. Priority fees flow back to the leader, and the burned base fee remains a real cost, but that is an economic brake, not a wall. A rule that cannot govern leader self-dealing should not be sold as a fairness guarantee.
Latency is the other load-bearing beam. Checking order requires the whole batch. That can disturb Firedancer's replay path. August discussion already flagged replay latency when data arrives in fragments. The September revision loosened the timing: compare on arrival, invalidate later if the final order fails. That resolves part of the problem. It does not resolve low-throughput conditions, where waiting for two FEC sets to form adds broadcast delay to blocks that don't need the wait. Nobody measured the delta.
We trade the chart, but we survive the chaos. The chart here is the ordering rule. The chaos is everything the rule leaves outside its fence.
On September 23, a reviewer made the sharpest point in the thread. A leader can still close a batch whenever separating conflicting transactions is profitable. The reviewer asked for what the proposal lacked: batch-size distributions broken out by scheduler, client, and market condition, plus sensitivity tests at different minimum sizes. Two days later the PR closed. The note asked for more discussion and client developer support.
I price skew for a living, and the analogy is exact. A hedge that covers the middle of the distribution and stops at the boundary of the event is not a hedge. SIMD-0649 covered intra-batch ordering and stopped at the batch boundary. The exposure did not disappear. It relocated.
Here is where most coverage gets it wrong. The popular read is that Solana's fair-ordering push failed. The accurate read is that a narrow audit rule failed while wearing a broad label — and the label wasn't the proposal's fault. The draft said plainly that it does not prevent preferential treatment, MEV, or slippage. It said its check covered intra-batch non-increasing priority for non-exempt transactions. The gap sits between that sentence and the market's shorthand.
The load-bearing wall isn't fairness. It's cross-client agreement. The hard problem isn't "should fee payers go first." It's making Agave and Firedancer compute the same priority score, from the same cost model, in the same integer space, on the same partial data, inside the same latency budget. I spent the 2020 DeFi summer reading opcodes because the docs didn't match the yield math, and the lesson generalizes: complexity hides the fatal flaw, and the flaw usually lives in the seam between two systems that each believe they are correct. Firedancer may hold a de facto veto here — not from obstruction, but because its performance targets make extra ordering checks expensive. A client doing what it was built to do is not a saboteur.
The governance record is thinner than it looks. The review that buried the proposal is attributed to "a reviewer." No name. The demanded data was never published. Public SIMD channels, public PRs, and an anonymous evaluation add up to transparency with a hole in it. I audited shielded-pool code back in 2017 where the commit history was cleaner than the whitepaper; the instinct carries over. Read the artifact, not the announcement.
And closure is the process working. A SIMD that cannot produce measured batch distributions should not merge. Silence is the only edge left in the noise. The silence here is a merge that didn't happen, and that is information.
Watch four signals, not the headline. Any rewrite that limits batch-boundary discretion, or forces ordering across batch seams — that is the version that would actually bite. Published batch-size distributions segmented by scheduler, client, and market condition; without them, every minimum-size number is a guess. Explicit Agave and Firedancer positions, because client implementation is the real approval gate. Latency measurements under low throughput, where the two-FEC-set floor does its damage.
Solana's leader is not a neutral scheduler. It is a profit-maximizing block producer with discretion over inclusion, position, and boundary. Every ordering rule that fails to constrain all three is a partial fix, and partial fixes get priced as full ones right up until they aren't.
One market question is worth more than the rest. If search strategies migrate from intra-batch front-running to cross-batch front-running, the DEX user's fill barely changes. That means Solana's fairness premium may not be priceable at all. Position for the rule, not the label. The next revision tells you which one actually exists.