DEV Community: Suliman Mokhtar

Solana Shred Recovery: When Valid Shreds Form an Invalid Erasure Batch

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:21 +0000

Originally published on xroot.dev.

A Solana block reaches validators as shreds, in batches of 32 data shreds and 32 coding shreds tied together by one Merkle root that the leader signs. Every shred in a batch can carry a valid signature and a valid Merkle proof while the batch itself is wrong, because nothing in the signature says the coding shreds are the parity of the data.

SIMD-0504 says the rules for a batch apply to rebuilt shreds as much as to received ones, and between 24 October and 5 November Agave rebuilt its recovery path to enforce that: every validator now rebuilds every batch, so a batch like this fails everywhere. We modelled the old and new paths with the Reed–Solomon library Agave uses and ran four kinds of malformed batch past simulated validators losing packets. Under the old code, what a validator ended up doing depended on which shreds it happened to receive. Under the new code, every validator that collects 32 shreds rejects the batch: none of 800,000 rebuilds of a malformed batch passed.

How an erasure batch is built

The leader cuts its block into data shreds and, for every 32 of them, computes 32 coding shreds with a Reed–Solomon code. Any 32 of the 64 are enough to rebuild the other 32, so a validator can lose half of a batch to the network and still have the block. Then the leader hashes all 64 shreds into a Merkle tree, signs the root and attaches to each shred its path to that root. A validator checks each shred on arrival: the signature over the root, and the path from the shred to the root.

Shreds per batch — 32 data + 32 coding

Needed to rebuild the batch — any 32

Payload: data · coding shred — 1,203 · 1,228 bytes

Erasure-coded part of each — 987 bytes

Merkle tree — 64 leaves, 6 levels

What the signature does not cover

The Merkle root commits to the bytes of each of the 64 shreds. It says nothing about how they relate. A leader can compute its coding shreds from different data, or change one byte of a shred after encoding, then build the tree and sign. Each shred still verifies on its own. The batch is not a Reed–Solomon codeword: rebuilding it from different subsets of shreds gives different answers.

Until 29 October, Agave ran Reed–Solomon only when data shreds were missing and at least 32 shreds of the batch were present, tried again after every new insert of shreds, and logged a failed attempt at info level before moving on. The Merkle check made sure a rebuilt shred was byte-for-byte what the leader had signed, so a bad batch could never smuggle in different block data. But whether a validator noticed anything depended on which shreds it held. In our simulation of 2,000 validators per row, adding one shred per insert, each row counts the validators that completed the batch from data shreds alone · recovered without noticing the bad shred · were left waiting for repair:

First coding shred corrupted, 1% loss — 1,492 · 0 · 508

First coding shred corrupted, 5% loss — 379 · 0 · 1,621

Last coding shred corrupted, 1% loss — 62 · 1,934 · 4

Last coding shred corrupted, 5% loss — 29 · 1,895 · 76

Those in the first group never looked at a coding shred. With the first coding shred corrupted, every recovery that used it failed, about 31 failed attempts per validator even with no loss, and at 5% loss four validators in five could not complete the batch from Turbine. Repair fixes that, because it hands out the shreds the leader signed, but it takes longer. With the last coding shred corrupted, most recoveries never touched it and quietly succeeded. A corrupted data shred, or coding shreds computed from other data, behaved like the first case. Nothing in any row was rejected.

SIMD-0504: the batch is the unit of validity

SIMD-0504, written by Philip Taffet of Firedancer, replaces the shred rules each client inferred from Agave’s code with a written list. Sixteen checks apply to each shred: index ranges, the fixed 32:32 layout, a Merkle tree of exactly six levels, flag and size rules. A shred that fails them is dropped. Eight checks apply to the batch as a whole: one slot, one shred version, one chained Merkle root, one parent across the data shreds, padding only at the end. A block containing a batch that fails them is invalid. Under TowerBFT a validator must not vote for it, and under Alpenglow it must vote skip.

None of the sixteen or eight checks says the coding shreds must be the parity of the data. That follows from the proposal’s note on recovery: the batch checks apply to received and rebuilt shreds alike, so a validator that received all 32 data shreds must still check the coding shreds. The proposal says why: to eliminate any divergence based on whether a validator received or recovered a shred. A rule that only the validators who happened to need recovery could check would split the cluster the first time a leader broke it. Agave enforces the note by rebuilding every batch, and a batch whose coding shreds aren’t the parity of its data cannot be rebuilt to the root the leader signed.

“Always recover”: how Agave checks every batch

Agave landed the change in a series of pull requests: #16194 wired the rebuild into blockstore on 29 October, #16378 added the feature gate and enforcement a day later, and #16639 stopped retrying a batch that cannot be rebuilt once SIMD-0504 is active. In the code at the time of writing, a batch is rebuilt exactly once, in the insert that first brings it to 32 shreds, whether or not any data shred is missing:

received exactly 32:  reconstruct the other 32 shards
received more than 32: reconstruct missing data from 32 of them,
                       re-encode all 32 coding shards,
                       compare with the coding shards received
then:                  rebuild the Merkle tree from all 64 leaves,
                       compare with the signed root
fail either check:     with SIMD-0504 active, mark the slot dead
                       (unless it was already full before this insert)

The gate is stricter_shred_validation, key s5o4YoA9zUrw9j4v335ncdG5PpznDBsrgM6CvUGrasA. On 6 November at 03:18 UTC its feature account did not exist on mainnet, testnet or devnet. Until it is activated, Agave runs every check and reports failures to its metrics, but rejects nothing it did not reject before.

Same verdict, whatever arrived

Our model follows that code with the same library, version and features (reed-solomon-erasure 6.0.0 with simd-accel), 987-byte shards and Agave’s Merkle construction. We built four malformed batches, the first or last coding shred flipped by one bit after encoding, one data shred flipped, and all coding shreds computed from different data, and rebuilt each from 200,000 random subsets of every size from 32 to 64 shreds:

Honest batch, 200,000 subsets — all pass

Malformed batches, 800,000 subsets — 0 pass

…failed as Merkle mismatch — 629,095

…failed as wrong parity — 170,905

The reason is simple once written down. The rebuild produces one Reed–Solomon codeword from the shreds it used. For the batch to pass, that codeword must equal the signed shreds at every position the validator did not receive (or the Merkle root differs) and at every coding position it did receive (or the parity check fails). The positions it used to rebuild match by construction. So passing requires the codeword to match all 64 signed shreds, which only happens if the batch was a valid codeword to begin with.

In the packet-loss simulation every validator that reached 32 shreds flagged every malformed batch, at every loss rate from 0 to 45%, and passed the honest one. That held with one shred per insert, and again with inserts of a random 1 to 16 shreds, where about half the failures of the last-coding-shred batch came from the parity comparison rather than the Merkle root. The only validators without a verdict were those that never collected 32 shreds through Turbine, 16 to 19% of them at 45% loss and none at 20% or less; they run the same check when repair brings the batch to 32.

What rebuilding every batch costs

Less than it sounds. The old code already rebuilt a batch whenever a data shred was missing when it reached 32 shreds, and that is nearly always. The leader sends a batch’s data and coding shreds together, and Turbine routes each shred down its own tree. If they arrive in random order, the first 32 are exactly the 32 data shreds with probability 1 in C(64, 32), about 5.5 × 10⁻¹⁹, which fits the pull request’s estimate that the old code skipped recovery less than once in a trillion batches. What is new is re-encoding the received coding shreds when an insert pushes a batch past 32 at once, and rebuilding batches made only of data shreds. Timed on our model, per batch:

Old recovery, 16 data + 16 coding — 299 µs

New rebuild, same 32 shreds — 299 µs

New rebuild, 24 data + 16 coding — 325 µs

New rebuild, 32 data and no coding — 299 µs

New rebuild, all 64 received — 305 µs

Most of that is hashing the 64 leaves of the Merkle tree, about 214 µs here, which both versions do; encoding 32 coding shreds takes about 83 µs. For the same 32 shreds the new path costs exactly what the old one did, and re-encoding the received coding shreds adds about 9% when more than 32 are present. These are timings of our model on an Apple M1 Pro; absolute numbers depend on the hardware, SHA-256 speed above all.

Two Turbine changes around it

Rebuilt coding shreds are now retransmitted. A validator forwards rebuilt shreds to its children in Turbine, so one dropped packet upstream doesn’t starve everyone below. When an insert brings only data shreds, the rebuild produces coding shreds the validator never received, and the first version of always-recover, keeping Agave’s old output, threw them away. #16622 forwards them as well, which its description notes Firedancer already did.

Leaders no longer rebroadcast. When a leader’s own slot had not been seen by enough stake, Agave’s replay stage asked the broadcast stage to send every data and coding shred of that slot again, after 5 seconds and then at doubling intervals up to 320 seconds. On 5 November #16595 removed Tower consensus from Agave’s replay stage as part of its Alpenglow cleanup, and the request went with it. Hours later #16713 deleted the broadcast worker that served those requests. The issue behind it had called the mechanism redundant if repair works. A validator missing shreds now has two ways to get them: rebuild them from the batch, or ask a peer through repair.

What this does not show

We ran a model of Agave’s rebuild, not Agave: shred headers, signatures, the per-shred checks and the batch header checks are not in it, and a malformed batch here differs from an honest one only in its erasure coding. Arrival order and loss are random and independent, which real Turbine is not, and inserts are one shred or a random 1 to 16. We had no cluster, so nothing here was measured on a network; the timings are from an Apple M1 Pro, not validator hardware. Firedancer’s implementation of the same rules was out of scope.

Shred Recovery: Questions People Actually Ask

What is a Solana erasure batch?

A group of 64 shreds: 32 data shreds carrying the block and 32 coding shreds that are their Reed–Solomon parity, so any 32 of the 64 rebuild the rest. All 64 are leaves of one Merkle tree, and the leader signs its root. Agave and SIMD-0504 also call it an FEC set.

What does SIMD-0504 change about shred validation?

It replaces the checks validators inherited from Agave’s code with a written list: sixteen checks on each shred and eight on each erasure batch as a whole. A batch that fails them makes the block invalid: under TowerBFT a validator must not vote for it, under Alpenglow it must vote skip. The checks apply whether a shred was received or rebuilt, so a validator has to check the coding shreds even when all 32 data shreds arrived.

What is “always recover” in Agave?

Agave rebuilds every erasure batch once, in the batch of incoming shreds that first brings it to 32 shreds, even when no data shred is missing. It re-encodes the coding shreds from the data, compares them with the coding shreds it received, and rebuilds the Merkle tree from all 64 leaves to compare with the signed root. With the SIMD-0504 feature active, a failure marks the slot dead unless it was already full.

Is SIMD-0504 active on Solana mainnet?

No. Agave’s gate, stricter_shred_validation, was merged on 30 October 2026 and had no feature account on mainnet, testnet or devnet on 6 November. Until it is activated, Agave runs the checks and reports failures to metrics without rejecting anything new.

Does a Solana leader still rebroadcast slots that did not propagate?

Not in Agave’s main branch. The replay code that asked a leader to resend an unpropagated slot was removed on 5 November 2026 along with Tower consensus in replay, and the broadcast worker that served those requests was deleted the same day. Missing shreds are recovered from erasure coding or fetched through repair.

The one-line version

A leader can sign an erasure batch whose shreds each verify but whose coding shreds aren’t the parity of its data; SIMD-0504 makes that batch invalid, and Agave now rebuilds every batch once it has 32 shreds, so every validator rejects it the same way, whichever shreds reached it.

Sources: SIMD-0504 at commit 33c75cff; Agave #16194, #16378, #16639, #16622, #16595 and #16713, read at commit 9eacc06d; the old recovery path at dd6f564f. The model, simulation and timings are our own.

Solana WebSockets That Stay Connected but Miss Updates

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:19 +0000

Originally published on xroot.dev.

Your indexer subscribes to a program’s logs at finalized, because it only wants data that can never roll back. The socket stays open. No error arrives, no disconnect, no lag warning. And some transactions that are finalized on chain never reach it.

We measured how often on 5 November 2026, against the public mainnet RPC endpoint, which reported Agave solana-core 4.4.0. Over half an hour, a finalized logsSubscribe stream never looked at about 3% of slots and missed 61 of 1,803 finalized transactions that getSignaturesForAddress returns for the same slots. A processed stream on the same connection missed none.

The cause is a seven-year-old design decision meeting a consensus protocol that has run mainnet for two weeks. It was reported on 3 November, and a fix was proposed the same day. Here is what the stream reads, why it skips, which subscriptions are exposed, what the fix changes for clients, and the reconciliation loop that catches the gap today.

One finalized transaction in thirty never arrived

The setup was three programs and three commitment levels. The Address Lookup Table program and the first Memo program land roughly one transaction every slot or two, so each of their transactions is an independent test of whether a stream looked at its slot. The second Memo program lands a transaction in almost every slot, so the slots a stream reported for it are the slots that stream scanned. Ground truth was getSignaturesForAddress at finalized, polled over the same window.

All nine subscriptions shared one WebSocket connection, so one node served all three commitment levels. The run covered 05:36 to 06:07 UTC, slots 465,589,591 to 465,598,091. The endpoint dropped our connection about once a minute under the high-volume Memo stream (close code 1006, no close frame), so each level is judged only on slots strictly inside a stretch where its connection was live.

finalized — slots never scanned — 53 of 1,664 · 3.2%

finalized — finalized transactions missed — 12 of 438 · 2.7%

confirmed — slots never scanned — 4 of 1,664 · 0.24%

confirmed — finalized transactions missed — 4 of 440 (3 in one slot)

processed — slots never scanned — 0 of 1,664

processed — finalized transactions missed — 0 of 440

A second run, with one connection per commitment level and so most likely three different nodes behind the load balancer, agreed. Finalized never scanned 93 of 3,152 slots (2.95%) and missed 49 of 1,365 transactions; confirmed skipped 8 slots (0.25%) and 2 of 2,415 transactions; processed skipped none. Across both runs, finalized missed 61 of 1,803.

programSubscribe behaves the same way. A third connection subscribed to the Lookup Table program’s accounts at all three levels for 30 minutes. In the stretch all three covered, the confirmed stream delivered 37 table updates (3.0% of 1,253) that the finalized stream never sent, and the finalized stream delivered none that confirmed did not.

The gaps are not random. Almost every jump skipped exactly one slot. Of the 146 slots the finalized streams never scanned across both runs, 135 were the third slot of a leader’s four-slot window (slot number mod 4 = 2, which is how Agave numbers positions in a window), and so were all 12 the confirmed streams skipped. Neither the issue nor the pull request mentions it, and we have not traced the cause. Something deterministic in when that slot becomes rootable is a better guess than thread scheduling.

Each update reads exactly one slot

Agave’s PubSub service is driven by commitment updates. When the processed or finalized slot moves, the notifier thread visits every subscription at that level. For each one, it loads one bank, the one at the new commitment slot, and runs a query against it. What the query returns depends on the subscription type, and for two of them the answer is “only what happened in this slot”.

// rpc/src/rpc_subscriptions.rs — one bank: the new commitment slot's
let bank = bank_forks.read().unwrap().get(slot);

// programSubscribe's query against that bank
bank.get_program_accounts_modified_since_parent(&params.pubkey)

// runtime/src/bank.rs — which scans only that slot's own storage
self.rc.accounts.load_by_program_slot(self.slot(), self.bank_id(), Some(program_id))

// logsSubscribe reads the same bank's log collector: its own transactions only
bank.get_transaction_logs(pubkey)

programSubscribe sees the accounts written in the slot it was handed, and logsSubscribe sees the transactions executed in it. Nothing records which slots a subscription has already been shown: the “last notified slot” passes through these two filters untouched. So if the finalized slot moves from 5 to 7, slot 7 is scanned and slot 6 is not, by this update or by any later one.

The one-slot read for program subscriptions dates to March 2019. It is not a regression. The change is in how the commitment slot moves.

Three ways the commitment slot jumps

The issue names three paths, and each one is in the source.

Coalescing. The commitment service drains its queue with try_iter().last(): if two updates are waiting when it wakes, it keeps the newer one and the older slot is never announced. Both the TowerBFT and the Alpenglow inputs are read this way.
A skip vote the cluster overrules (processed). Under Alpenglow, processed follows the node’s own notarize votes. If the node votes to skip a slot the cluster then notarizes, it never notarizes that slot, and a parent check stops it notarizing the rest of that leader window. Processed then jumps to the next window.
One root for many slots (finalized). Votor roots the highest finalized block it can root, and a single Rooted message moves the node’s finalized and root slots to that slot at once. It is published only after the bank tree has been rooted and pruned, so the banks in between are gone by the time the notifier runs.

The third path is the one our data shows. Alpenglow has decided finality on mainnet since 21 October 2026, and under it a block is rootable only once the node has voted on it and replayed it. A finalized block that is not rootable yet when a later one is gets folded into the later root. The processed paths exist in the code, but they did not fire on this node during our half hour.

Which subscriptions are exposed, and why confirmed is not a cure

The one-slot read is specific to two subscription types. The others either read through ancestors or walk back over the slots they missed:

programSubscribe · logsSubscribe — one slot per update

accountSubscribe — reads through ancestors — latest state arrives

signatureSubscribe — status cache, through ancestors — arrives

blockSubscribe — walks back to the last slot sent — arrives

rootSubscribe — every newly rooted slot, in order — arrives, twice

Confirmed takes a different route, which is why it did twelve times better. Under Alpenglow there is no optimistic confirmation in the TowerBFT sense, so votor sends the RPC layer an “optimistically confirmed” notification for each new root, with a comment explaining it is critical for compatibility with the RPC API. The tracker that receives it walks every ancestor above the last confirmed slot and issues one update per slot. On the same node, confirmed and finalized notifications for a slot arrived a median of 9 milliseconds apart: on an Alpenglow Agave node, confirmed is already root-timed.

It still skipped 0.25% of slots, always the same window position as the finalized gaps. Our reading is a race with pruning. The confirmed walk follows parent links that squashing a root clears, and each slot it queues is then loaded from a bank tree that rooting prunes. Both happen at the moment a slot becomes final. We have not proven which of the two loses in our samples.

The fix on the table, and what it changes for clients

Pull request 16689 changes the read from “one slot” to “every slot since the last one this subscription was shown”:

Snapshots before rooting. Each bank’s account writes and transaction logs are copied into a retained cache before rooting runs, so pruning and accounts cleaning cannot erase an update that has not been delivered yet. Rooted banks are captured from the same function that rooted them.
Delivery in order, once. On each commitment update, the notifier walks from the last bank this subscription was shown to the new slot and delivers each in order, deduplicating frozen banks by bank ID. The confirmed path gets the same retained chain.
A visible change in context.slot. Today a notification’s context.slot is the commitment slot that triggered it. With the fix it is the slot where the change happened, so a jump from 5 to 7 arrives as an update for 6 and then one for 7. Code that treats context.slot as “the current finalized slot” will see it lag behind.
Bounded, and loud when exceeded. The cache is capped at the PubSub queue budget (--rpc-pubsub-queue-capacity-bytes, 256 MiB by default) and at 512 banks, under two minutes at the 4.7 slots a second we measured. A subscription that needs a bank already evicted is disconnected through the same path a lagging client takes today, instead of being skipped silently.

As of 5 November the pull request is open with no reviews, and no release contains it. The public endpoint we measured runs 4.4.0, which has the one-slot read, the coalescing and the root-timed confirmed path exactly as described above.

Catching the gap in your own pipeline

No subscription setting makes a PubSub stream complete today, so the dependable move is to diff it against the ledger. For a logs stream, getSignaturesForAddress at finalized is the list of everything that should have arrived. This is the loop we ran:

// ws: an open WebSocket to your RPC node · rpc(): a plain JSON-RPC POST helper
const PROGRAM = 'AddressLookupTab1e1111111111111111111111111';
const GRACE_SLOTS = 150; // ~30 s for the stream to deliver before we call it missed

const seen = new Set(); // signatures the stream delivered
let fromSlot = 0;       // first slot the stream was live for
let cursor;             // newest signature already reconciled

ws.send(JSON.stringify({
  jsonrpc: '2.0', id: 1, method: 'logsSubscribe',
  params: [{ mentions: [PROGRAM] }, { commitment: 'finalized' }],
}));
ws.onmessage = ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.method !== 'logsNotification') return;
  const { context, value } = msg.params.result;
  fromSlot ||= context.slot;
  seen.add(value.signature);
};

async function reconcile() {
  if (!fromSlot) return;
  const sigs = await rpc('getSignaturesForAddress', [
    PROGRAM,
    { commitment: 'finalized', limit: 1000, ...(cursor && { until: cursor }) },
  ]);
  if (!sigs.length) return;
  // Only judge signatures the stream has had time to deliver.
  const settled = sigs.filter((s) => s.slot <= sigs[0].slot - GRACE_SLOTS);
  if (!settled.length) return;
  cursor = settled[0].signature;
  for (const s of settled) {
    if (s.slot > fromSlot && !seen.has(s.signature)) {
      // fetch with getTransaction and apply it
      console.log('missed', s.signature, 'in slot', s.slot);
    }
  }
}
setInterval(reconcile, 30_000);

Against mainnet from 07:57 UTC for three and a half minutes, it checked 239 finalized signatures and flagged 5 that the stream had skipped, every one of them in the third slot of a leader window. The grace period matters: the HTTP call and the WebSocket can land on different nodes, and without it a signature the stream is about to deliver looks missed.

Subscribe at confirmed to shrink the backlog. On an Alpenglow Agave node it arrived with finalized and skipped a twelfth as often. Gate on rootSubscribe if you need finality to be explicit rather than a property of today’s implementation: the source says the confirmed notification may be deprecated. Make that gate idempotent. On the same endpoint, rootSubscribe sent each root twice, once on its own and again just before the next one (127 notifications for 66 roots in 15 seconds).
Treat every disconnect as a gap. Reconcile from the last slot you finished. After the fix, falling behind the retention window is exactly how a gap will announce itself.
For account state, re-read what the missed transactions touched. getMultipleAccounts with minContextSlot, or accountSubscribe for a known set, which reads through ancestors.
Know which path you are on. Geyser plugins are fed from replay, not from this notifier, so a Geyser-based stream does not go through the one-slot read. A provider’s own WebSocket product may or may not be Agave’s PubSub underneath; the reconciliation loop works either way.

What this does not show

One endpoint, one morning, half an hour per run, and three programs. The rate will move with load and with the node. The logs numbers are checked against the ledger; the programSubscribe number is a comparison with the confirmed stream on the same connection, because a lookup table can change without an account notification under that owner (a closed table, for one).

We did not build or run the patched node, so section 05 describes the fix from its code and tests, not from measurement. Processed showed no gaps here, although the paths that would skip it are real. TowerBFT is not measured at all: mainnet no longer runs it. The one-slot read is as old under TowerBFT as under Alpenglow, so the exposure is not new, but we cannot say how often it fired before 21 October. The leader-window clustering is unexplained.

Missed WebSocket Updates: Questions People Actually Ask

Does programSubscribe miss updates on Solana?

At processed and finalized commitment on an Agave node, yes, whenever the commitment slot advances by more than one slot. Each update reads only the accounts written in the one slot it was triggered for, so writes in the slots it jumped over are never sent. On mainnet on 5 November 2026 a finalized stream jumped over about 3% of slots.

Is confirmed commitment safe to use instead of finalized?

It is much better but not complete. On an Agave 4.4 node under Alpenglow, confirmed notifications are sent when a block is rooted and walk every slot since the last one, so they arrive within milliseconds of finalized and skipped about 0.25% of slots in our measurement against 3% for finalized. Reconcile against the ledger either way.

Does accountSubscribe have the same problem?

No. accountSubscribe reads the account through all ancestors of the commitment slot and sends whenever its last-modified slot changes, so the latest state always arrives. signatureSubscribe, blockSubscribe and rootSubscribe also cover the slots in between.

How do I detect missed logsSubscribe notifications?

Diff the stream against getSignaturesForAddress for the same program at finalized commitment, after giving the stream a grace period to deliver, and fetch anything missing with getTransaction. Treat every disconnect as a gap to reconcile as well.

Has the fix shipped?

Not as of 5 November 2026. Pull request 16689 in the Agave repository, opened on 3 November, retains the skipped slots and delivers them in order. It is open and unreviewed, and no release contains it.

The one-line version

On Agave today, a finalized programSubscribe or logsSubscribe stream is a sample of the finalized slots, not the set. On mainnet it is about 97% of them.

Subscribe at confirmed, reconcile against the ledger, and treat a disconnect as a gap. When the fix ships, a gap will close your socket instead of passing unnoticed.

The commitment levels themselves are explained in how many confirmations a deposit needs, and the certificates behind them in Alpenglow finality in numbers. A pipeline built on these streams is the subject of ingesting the Solana firehose with Rust, and the errors a reconnect can return are in the RPC error codes.

Sources: Agave master at commit 32f5b38fd6, rpc_subscriptions.rs, bank.rs, commitment_service.rs, votor’s event_handler.rs and optimistically_confirmed_bank_tracker.rs; the same paths checked in the v4.4.0 release; issue 16654 and pull request 16689 as of commit cfa411b669. Measurements: our own WebSocket and JSON-RPC calls to the public mainnet endpoint on 5 November 2026, 05:34 to 06:09 and 07:57 to 08:01 UTC.

Two Tokens, One Stock: The Weekend Arbitrage Nobody Ran

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:17 +0000

Originally published on xroot.dev.

Robinhood Chain now has two tokens for NVIDIA, two for Tesla and two for nine other stocks and ETFs: one issued by Robinhood, one by Ondo. Since 26 October, eleven Uniswap v4 pools let anyone swap one for the other at a fixed rate.

Ondo’s announcement on 27 October gave a reason the pairing matters. Robinhood’s tokens cannot be minted or redeemed on weekends, so their price can drift. An eligible trader could buy a discounted Robinhood token, swap it for the Ondo token, then bridge and redeem that one, which works on weekends. We read the chain from the pools’ launch to the end of 3 November (UTC): every swap, deposit and bridge mint, plus the Robinhood tokens’ main markets for comparison. The pools held their rate to within a basis point. On the first weekend no one ran the trade, and the discount it needs was not there.

Two issuers, one ratio per stock

The two tokens are not the same instrument. Robinhood Stock Tokens are debt securities of Robinhood Assets (Jersey) Limited, minted and burned only by an authorised participant between Monday 02:00 and Saturday 02:00 CET. Ondo’s tokens are issued by Ondo Global Markets (BVI) Limited and minted and redeemed by eligible users on Ethereum, BNB Chain and Solana, and over the weekend for all eleven paired tickers. Neither is open to US persons.

Each issuer also folds dividends and corporate actions into its own shares-per-token figure, so the pools do not trade at one for one. Each stores a reference rate, in Ondo tokens per Robinhood token:

SPCX, MSTR, CRCL, TSLA — 1.00000

NVDA — 0.99906

GOOGL · META — 0.99774 · 0.99772

AAPL · QQQ — 0.99720 · 0.99663

SPY — 0.99232

GME — 0.98315

Where the numbers can be checked, they are exact. Ondo’s share-multiplier oracle on Ethereum answers for three of these tokens: SPYon, QQQon and TSLAon. For each of those, the pool’s reference equals Robinhood’s multiplier divided by Ondo’s, to six decimal places. For the other eight the oracle returned “asset not found”.

Ondo listed four more tokens on the chain without a Robinhood counterpart. One of them changed a day later: Robinhood minted its first BMNR token on 28 October at 14:05 UTC. By 3 November there was still no StablePair pool for it.

How a StablePair pool holds the rate

The pools run on Uniswap’s StablePair hook, a dynamic-fee hook for two assets meant to hold a known price. Its reference is not an oracle. It is a number stored per pool when the pool is created, and it changes only when an account with the config-manager role calls updateFeeConfig. Around that number the hook sets every swap’s fee:

Inside a ±0.005% band — all buys one price, all sells another

Round trip inside the band — 1 basis point

Outside, toward the reference — decaying fee, ×0.99 per block

Outside, away from the reference — no fee

All eleven pools use the same settings, and no reference changed through 3 November. You can read any pool’s reference yourself:

# feeConfig(bytes32 poolId) on the hook: returns k, optimalFeeE6,
# targetMultiplier, referenceSqrtPriceX96. Pool below: NVDA / NVDAon.
curl -s https://rpc.mainnet.chain.robinhood.com -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
        "to":"0xd061f665d1c4816787fceaa168fa66c59d3abcc0",
        "data":"0xb9629a414c71fa93d5a448afc030cfec54e1779ed1d2498c905569ee817eb5cadcbdc6fb"
      },"latest"]}'
# rate = (referenceSqrtPriceX96 / 2^96)^2 = 0.99906 NVDAon per NVDA

One account set up all eleven

Everything happened on Monday 26 October, in about an hour:

12:27⁠–⁠12:34 UTC — Ondo tokens bridged in to one address

12:47:52 — hook deployed, all roles to that address

12:51:41⁠–⁠12:58:14 — eleven pools initialized

13:00⁠–⁠13:34 — one deposit per pool, about $517,000

The address, 0x9d9210ea…4c0e4, is an ordinary account, not a contract. It received the bridged Ondo tokens, holds the hook’s admin, pool-initializer and config-manager roles, created every pool and seeded each with roughly equal value of both tokens, about $42,000 to $54,000 per pool. At the end of 3 November the pools held between 87.4% (GOOGLon) and 100.0% (GMEon) of each Ondo token’s supply on the chain.

The hook is an upgradeable proxy, and Uniswap’s hook list records it that way. So the key behind that one address can change any pool’s exchange rate and replace the hook’s code. That says nothing about intent, but anyone providing liquidity or quoting a price off these pools is trusting that key.

The first week, swap by swap

Dollar figures below use each Robinhood token’s last price before Friday’s 4pm close on its busiest USDG pool:

Swaps, all eleven pools — 232, from 127 senders

Volume — about $47,800

Same tokens, main v3 USDG pools — about $99.4 million

Share through the pegged pools — 0.05%

Swaps within 1 bp of the reference — 179 of 232

Most swaps executed at the edge of the band, exactly as the design intends. Two pools moved further. In GOOGL, one 17-token trade on 28 October pushed the price 7.1 basis points below the reference, and two trades minutes later pulled it back. On 29 and 30 October a run of one-way trades took it 5.5 basis points below again. While it was out of the band, trades pushing further paid no fee and trades pushing back paid 1 to 1.8 basis points. The pool ended the week 4.1 basis points below.

GME is the week’s largest trade, and it ran the other way from the announcement’s example. At 05:30 UTC on Wednesday 28 October, one address bridged 838.3 GMEon onto the chain. Four minutes later it swapped 837.9 of them for 851.1 of Robinhood’s GME tokens, a $20,600 trade at prices 13.6 basis points worse than the reference. That emptied the pool’s Robinhood side from 940 tokens to 89 and left its price 26.2 basis points from the reference. Only one later trade, of 0.11 tokens, pushed back, so the gap stayed open through the end of the week: a 25-basis-point edge for anyone holding Robinhood GME tokens who had a use for GMEon.

The weekend

Robinhood’s window closed at 01:00 UTC on Saturday 31 October and reopened at 01:00 UTC on Monday 2 November, after Europe had left summer time. That is 48 of the 203 hours we observed. In the pegged pools:

Weekend swaps — 16 of 232

Robinhood → Ondo token — $2,222

…swapped straight back (QQQ) — $2,019

Net, mostly one CRCL trade — about $200

Ondo tokens bridged in or out — none

The announcement’s trade ends with a bridge and a redemption. Not a single Ondo token was minted or burned on Robinhood Chain over the weekend. In fact none was after 09:47 UTC on 28 October.

The likely reason is that the discount never opened. The Robinhood tokens’ busiest USDG markets are Uniswap v3 pools, and the busiest one for each token carried $99.4 million between them in the same week. Over the weekend their volume fell to 3.0% of the week’s total, in 24% of its hours. Excluding trades under $10, whose prices are rounding noise, here is where each token traded relative to its Friday 4pm price:

NVDA — avg −0.13% · low −1.13%

META — avg −0.14% · low −0.79%

GME — avg −0.22% · low −0.94%

AAPL — avg −0.09% · low −0.49%

TSLA · SPY — avg +0.05% · +0.14%

QQQ · CRCL — avg +0.54% · +0.53%

GOOGL · SPCX — avg +1.06% · +1.79%

MSTR — avg +2.29% · high +3.26%

In 8 of the 11, the weekend average sat between Friday’s close and the first hour of Monday’s session: the market pricing weekend news before the open. NVDA, META and GME averaged 0.13% to 0.22% below Friday. That is before the v3 pool’s own fee, the bridge and Ondo’s off-hours spread, which its docs say can be wider. The loop had nothing to capture.

What would make the two tokens diverge

Two limits matter when a real gap does open. The first is capacity. The pools hold almost every Ondo token on the chain, so the trade can only take what a pool holds, roughly $21,000 to $27,000 of Ondo tokens per stock at launch. GME shows what happens next: one trade empties a side and the pool stops correcting.

The second is the stored rate. The hook does not know when either issuer’s shares-per-token figure changes, for example on an ex-dividend date. Until the config manager updates the reference, the pool keeps quoting the old ratio. Because the hook charges nothing to swaps that move the price away from the reference, the pool can be traded to the new ratio for free, and its liquidity providers absorb the difference.

The token pages for both issuers’ contracts on this chain are in our Robinhood Chain token list, and reading the chain directly covers the RPC and explorer used here.

What this does not show

This is one week and one weekend. Dollar values come from on-chain USDG prices, not from the stock market, and there is no on-chain fair value for a stock on a Saturday. We could check the reference rate against both issuers for only three of the eleven pools, because Ondo’s oracle did not answer for the other eight. Those eight are reported as configured. Block times were interpolated between samples taken every 2,500 blocks, which is accurate to about ten seconds. We name addresses, not the people or companies behind them.

Two Tokens, One Stock: Questions People Actually Ask

What is the difference between NVDAon and Robinhood’s NVDA token?

They are issued by different companies under different terms. Robinhood Stock Tokens are debt securities issued by Robinhood Assets (Jersey) Limited, minted and redeemed only by an authorised participant during a weekday window. Ondo Stocks are issued by Ondo Global Markets (BVI) Limited and can be minted and redeemed by eligible users on Ethereum, BNB Chain and Solana, including on weekends for the eleven tickers paired on Robinhood Chain. Neither is offered to US persons.

Can Robinhood stock tokens be redeemed on weekends?

No. Robinhood’s tokenization window runs from Monday 02:00 to Saturday 02:00 CET; outside it, no tokens are minted or burned. The tokens still trade on chain over the weekend, but their supply cannot change until Monday.

Why is the exchange rate between the two tokens not exactly 1?

Each issuer adjusts its own shares-per-token figure for dividends and corporate actions, so one Ondo token and one Robinhood token for the same stock can represent slightly different amounts of it. Each pool stores a reference rate set when it was created: 1.0 for SPCX, MSTR, CRCL and TSLA, and between 0.98315 (GME) and 0.99906 (NVDA) Ondo tokens per Robinhood token for the other seven.

Did Robinhood stock tokens trade at a discount on the weekend of 31 October?

Not by enough to matter. On each token’s busiest USDG pool, excluding trades under $10, weekend prices stayed within 1.13% below and 3.26% above Friday’s 4pm price. In 8 of 11 tokens the weekend average sat between Friday’s close and Monday’s first hour, which is the market pricing weekend news. The other three averaged 0.13% to 0.22% below Friday.

Who sets the StablePair reference price?

Whoever holds the hook’s config-manager role can change any pool’s reference with updateFeeConfig. On Robinhood Chain all three of the hook’s roles, including the right to upgrade its code, were granted to one ordinary account when it was deployed, and no reference changed through 3 November 2026.

The one-line version

Eleven pools pin Ondo and Robinhood tokens for the same stock to a rate one account set and can change. In their first week they carried 0.05% of those tokens’ trading, and the weekend discount they were built to absorb never appeared.

Sources: Ondo’s 27 October announcement, off-hours trading and eligibility docs; Robinhood’s Stock Tokens docs; Uniswap’s StablePair specification at commit fa163e5c and hook-list entry. Pool, swap, deposit, transfer and role events were read from rpc.mainnet.chain.robinhood.com, from the Ondo tokens’ arrival on 26 October to block 105,464,942 (3 November, 23:59:59 UTC). Ondo’s multipliers were read from its oracle on Ethereum.

When a Solana Feature Activates but Its Program Migration Fails

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:15 +0000

Originally published on xroot.dev.

On Solana, a feature gate activating and the change it carries actually happening are two separate events. For most gates the difference never shows. For a gate that replaces a core program’s bytes, it can: the replacement runs once, at the epoch boundary, and if it fails, the gate stays active anyway.

SIMD-0690, merged on 26 October, adds a deliberate way for that replacement to fail: the runtime hashes the new program bytes and refuses to deploy them unless they match a hash shipped inside the validator. Agave implemented it on 29 October. On 2 November it queued the first migration that relies on it, p-ATA, a rewrite of the Associated Token Account program, and Firedancer followed on 3 November. We pulled the real p-ATA buffer from mainnet, hashed it the way both clients do, and replayed every way the activation can go through the loader Agave uses. The check works. It also depends on something no code enforces: the two clients agree only if the gates activate in the right order.

Activated is not the same as replaced

In the first bank of each epoch, Agave works out which feature gates have just activated, writes the activation slot into each gate’s account, and then runs the migrations tied to those gates. The p-ATA one is a single call, and its failure path is a log line:

if new_feature_activations.contains(&feature_set::replace_ata_with_p_ata::id())
    && let Err(e) = self.upgrade_loader_v2_program_with_loader_v3_program(
        &feature_set::replace_ata_with_p_ata::SPL_ASSOCIATED_TOKEN_ACCOUNT_PROGRAM_ID,
        &feature_set::replace_ata_with_p_ata::PROGRAM_BUFFER,
        feature_set::replace_ata_with_p_ata::BUILD_HASH,
        true,
        "replace_ata_with_p_ata",
    )
{
    warn!("Failed to replace SPL Associated Token Account with p-ATA buffer '{}': {e}", ...);
}

Every check runs before anything is written, so a failure changes nothing except the gate. The gate is now active, so it is never a new activation again and the call never repeats. The proposal says so in one line: on a mismatch, “the feature is still marked as activated, but the program data remains unchanged.” A retry means a new gate in a new release. That leaves four states a migration can be in:

Gate account does not exist — not submitted

Gate exists, no activation slot — pending, next epoch

Active, program under Loader v3 — migrated

Active, program under its old loader — activated, migration failed

What the hash check adds

A migration copies a Loader v3 buffer account, uploaded ahead of time, into the target program’s address. Before SIMD-0690, the runtime checked that the buffer existed, was owned by the upgradeable loader and deserialized as a buffer, then deployed whatever it held. Agave’s implementation adds one step between those checks and the deploy:

let buffer = Self::new_checked(bank, buffer_address)?;
let data = buffer.buffer_account.data();

let elf = &data[UpgradeableLoaderState::size_of_buffer_metadata()..];
let end_offset = elf.iter().rposition(|&x| x != 0).map_or(0, |i| i + 1);
let hash = solana_sha256_hasher::hash(&elf[..end_offset]);

if hash != expected_hash {
    return Err(CoreBpfMigrationError::BuildHashMismatch(hash, expected_hash));
}

Skip the 37-byte buffer header, drop trailing zero bytes, take SHA-256, compare. Only then does the deploy step load and verify the ELF in the runtime’s program environment. That step deliberately still accepts SBPF v0 programs “for core program migrations”, which matters here because the p-ATA ELF is v0.

What came before is the reason for the change. When p-token replaced SPL Token in place on 13 May 2026, the function that did it took a program address, a buffer address, a flag and a log name. There was no hash. A Loader v3 buffer always has a write authority (the loader refuses to remove it), so until the activation slot, any change that authority made to the buffer, as long as it still loaded and verified, would have become SPL Token. Our p-token explainer covers that migration. Agave’s SIMD-0690 change also turns the expected hash from an optional parameter into a required one, so every future migration must name its bytes, while the check itself waits for its own gate, core_bpf_hash_validation.

The real buffer, hashed

SIMD-0567 merged on 1 November at 11:02 UTC. Twenty-seven minutes later, the p-ATA buffer appeared on mainnet: 37 transactions in slots 464,075,848 to 464,075,854, between 11:30:19 and 11:30:21 UTC. No transaction has touched it since. We read its bytes and hashed them both ways:

Account size — 35,869 bytes

Loader v3 buffer header — 37 bytes, authority set

ELF — 35,832 bytes, SBPF v0

Trailing zero bytes — 15

SHA-256, zeros removed — 4e008052⁠…⁠7f7d9e

Agave, Firedancer and SIMD-0567 expect — 4e008052⁠…⁠7f7d9e

SHA-256 of the whole ELF — 8dc8d134⁠…⁠3605a4

The buffer matches. The 15 zero bytes are worth a second look, because they are not padding. The buffer holds exactly one ELF file, and the file itself ends in zeros: its last section header has an alignment of 1 and an entry size of 0. Hash the ELF as a file and you get a different value. The expected hash is defined over the stripped bytes, the way solana-verify computes it, so solana-verify get-buffer-hash reproduces it straight from the chain.

The header also shows the buffer’s authority is still set, to 8pEc9HbS…7pkzf. Until the gate activates, whoever holds that key can rewrite or close the buffer. Before SIMD-0690 a rewrite would have been deployed. Now it can only make the activation fail.

Seven ways the activation can go

To see the success and failure paths without a cluster, we built a harness around the real buffer bytes. It runs Agave’s check copied verbatim, Firedancer’s check ported from C, and the deploy step through solana-sbpf 0.26.0, the loader version Agave pinned at the commit we read, configured the way Agave’s migration path configures it. With the SIMD-0690 gate active, both clients give the same answer for every case:

Buffer as it is on mainnet — migrated

Plus 4,096 zero bytes — migrated, same hash

Minus its last 15 zero bytes — hash passes, loader rejects

One .rodata letter changed — hash mismatch

Instruction 17 immediate, 83 → 84 — hash mismatch

First opcode set to 0xff — hash mismatch

Buffer closed before activation — account not found

Every failure leaves the gate active and ATA exactly as it was. Two of the rows are worth a closer look.

The hash pins the content but not the length. A buffer missing its last 15 bytes hashes identically, because those bytes are zeros. It is still a broken ELF: its section header table now runs past the end of the file, and the loader stops with “Offset or value is out of bounds.” The check and the loader cover each other. Neither alone would catch both a substituted program and a truncated one.

The authority problem has changed shape rather than disappeared. A changed letter in a string constant and a changed constant in an instruction both pass the loader and the verifier. Only the hash notices them. The buffer’s authority can no longer decide what ATA becomes, but closing or rewriting the buffer before activation still decides that ATA does not change, and a retry then needs a new gate.

When the order slips, the clients split

The two clients compute the same hash, but they decide differently whether to compute it. Agave hashes only if core_bpf_hash_validation is already active and otherwise skips the check. Firedancer always passes the p-ATA hash and checks whenever one is passed. Its feature map says why: it “assumes this feature gate is activated for all migrations”, because the SIMD-0690 gate will activate first. The same harness, with the SIMD-0690 gate inactive when p-ATA activates:

Buffer as it is on mainnet — both migrate

One .rodata letter changed — Agave deploys, Firedancer refuses

Instruction 17 immediate, 83 → 84 — Agave deploys, Firedancer refuses

First opcode set to 0xff — both refuse, for different reasons

In the highlighted rows the clients finish the epoch’s first slot with different bytes at the ATA address, so they compute different bank hashes. Validators executing with Firedancer’s runtime would disagree with validators executing with Agave’s about the same block. Frankendancer, the hybrid, executes with Agave’s runtime, so the line falls between runtimes rather than client brands. Which software each validator runs is visible in gossip and in block footers.

None of this is a bug today. The buffer on mainnet matches, so the order makes no difference to the bytes that would be deployed. SIMD-0567 names SIMD-0690 as a dependency, and both clients document the order. Activating both in the same epoch is also safe: Agave installs the new feature set before it runs any migration, so the check is already on. But the order is a scheduling commitment, not a check in code. Anza’s activation guidelines fix a priority order and say exceptions will occur. The thing to watch is simple: gate FCsQnd4V…zp1u must be active no later than gate pata6uFa…ksx3. Neither gate account had been created on mainnet when this was written.

Telling the states apart

A failed migration leaves no transaction and no event on chain. The only direct record is a warning in each validator’s log. It can still be detected from three accounts, read in one call:

const FEATURE_OWNER = 'Feature111111111111111111111111111111111111';
const LOADER_V3 = 'BPFLoaderUpgradeab1e11111111111111111111111';

async function migrationState(rpc, gate, program, buffer) {
  const res = await fetch(rpc, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getMultipleAccounts',
      params: [[gate, program, buffer], { encoding: 'base64' }] }),
  });
  const [g, p, b] = (await res.json()).result.value;

  // Feature account: owned by the Feature program, byte 0 = Some(activated_at)
  const data = g?.owner === FEATURE_OWNER ? Buffer.from(g.data[0], 'base64') : null;
  if (!data) return 'gate not submitted';
  if (data[0] !== 1) return 'gate submitted, pending';
  const slot = data.readBigUInt64LE(1);

  if (p.owner === LOADER_V3) return `activated at ${slot}: migrated`;
  return `activated at ${slot}: MIGRATION FAILED (buffer ${b ? 'still there' : 'gone'})`;
}

// p-token:  activated at 419472000: migrated
// p-ATA:    gate not submitted

The two comments are the script’s output against mainnet, for p-token and p-ATA. Checking the owner of the gate account matters: a gate’s address can hold lamports in an ordinary system account before anyone submits it, and reading those as feature data would report nonsense. Our upgrades tracker follows which protocol upgrades are live.

When p-ATA does migrate, the program account at ATokenGP…8knL changes owner from BPFLoader2111… to BPFLoaderUpgradeab1e…, gains a program-data account and has no upgrade authority. SIMD-0567 adds that ATA cannot be invoked during the migration slot, because Loader v3 programs take effect one slot after deployment. Tools that decide whether a program is upgradeable by its loader will see the change.

Two smaller things in the code

The log reads backwards. The mismatch error is built as BuildHashMismatch(hash, expected_hash), with the buffer’s hash first, but its message labels the first value “Expected”. For our altered-letter buffer, the warning prints:

Invalid build hash. Expected: 7c10bb1d…a3b147e730, Got: 4e008052…674e7f7d9e

The value after “Expected” is what the buffer holds, and the value after “Got” is what the validator expected. The labels have been this way since the error was introduced in April 2025. Anyone diagnosing a failed migration from logs should swap them.

A panic fixed in passing. The 2025 version of this check searched for the last non-zero byte across the whole account, header included. When the program bytes were all zero, as in a buffer created but never written, that search could land inside the 37-byte header and produce a slice that ends before it starts. Our harness reproduces the panic for a header with no authority, and for an authority whose last byte is zero. On a real cluster it would have stopped every validator at the activation slot. The SIMD-0690 commit fixed it under the line “strip trailing zeros from ELF bytes only”. It was never reachable on mainnet: the only migration that ever passed a hash before then was the slashing program’s, whose gate was never created on mainnet, and Agave removed it in June 2026. Firedancer’s version never had the problem.

What this does not show

The harness replays the checks and the loader on real bytes. It does not run a cluster through an epoch boundary. The deploy column uses Agave’s loader for both clients; Firedancer has its own loader, which we did not run. The altered buffers are our edits, not anything seen on chain. We checked the on-chain buffer against the published hash but did not rebuild p-ATA from source with solana-verify. We read mainnet only, not testnet or devnet.

Program Migrations: Questions People Actually Ask

Can a Solana feature gate be active while the program it was meant to replace is unchanged?

Yes. A core program migration runs once, inside the first bank of the epoch in which its feature gate activates. If any check fails, the runtime logs a warning and moves on: the feature account records its activation slot and the target program keeps its old bytes. Nothing retries, because the gate is never newly activated again. A second attempt needs a new feature gate in a new validator release.

What exactly does SIMD-0690 hash?

The program bytes in the source buffer account: everything after the 37-byte Loader v3 buffer header, with trailing zero bytes removed, hashed with SHA-256. The result must equal a hash compiled into the validator next to the feature gate. solana-verify computes executable hashes the same way, so solana-verify get-buffer-hash reproduces the value from the chain.

Is the p-ATA buffer on mainnet the one Agave expects?

Yes. The buffer at pataAAkF439TTjwRqmxRkTTEfZemRdoriXusez4PQ6S hashes to 4e008052…7f7d9e, the value in Agave’s replace_ata_with_p_ata gate, in Firedancer’s constant and in the SIMD-0567 text. It was created and written in 37 transactions on 1 November 2026 and has not been written since.

Do Agave and Firedancer run the hash check the same way?

They compute the same hash but differ on when they check it. Agave checks only once the SIMD-0690 gate, core_bpf_hash_validation, is active. Firedancer always checks the p-ATA hash and records that it assumes the SIMD-0690 gate activates first. If p-ATA activated before SIMD-0690 with an altered buffer, Agave would deploy the altered bytes, Firedancer would refuse them, and the two clients would compute different bank hashes.

How do I check whether a migration actually happened?

Read three accounts. The feature account is owned by the Feature program and holds an activation slot once active. The target program is owned by BPFLoaderUpgradeab1e… after a successful migration. The source buffer is consumed on success. An active gate with the program still under its old loader means the migration failed.

The one-line version

SIMD-0690 makes a core program migration deploy the reviewed bytes or nothing. A failure leaves the gate active and the program unchanged, and Agave and Firedancer agree on which happened only if the hash-check gate activates first.

The last in-place swap is in SPL Token was replaced in place, the prefunded-account rule p-ATA builds on is in SIMD-0312’s CreateAccountAllowPrefund, and how to tell which client built a block is in reading the block footer.

Sources: SIMD-0690 at commit eac20f29; SIMD-0567 at 93cdf03a; Agave #16077 and #16524 (source read at 9260869d); Firedancer #12680 (37c65819); the buffer and gate accounts read from mainnet with getAccountInfo, getMultipleAccounts and getSignaturesForAddress. Scenario results are from our own harness.

Why Solana’s getFeeForMessage Is Not a Transaction-Validity Check

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:14 +0000

Originally published on xroot.dev.

getFeeForMessage answers one question: what would this message pay? For years Agave also answered null when the message’s blockhash was gone or its durable nonce did not match, and code learned to read that null as “get a new blockhash”. Agave 4.5 stops doing it. And the null was never a reliable expiry signal in the first place.

Agave #16519, merged on 29 October, removes both checks, because the fee depends on neither. We ran the old behaviour on a local Agave 4.2.1 validator, which has the same check as the 4.4 release, and found a 150-block window in which it priced transactions that the same node was already rejecting with “Blockhash not found”.

What the fee is made of

The fee has two parts: 5,000 lamports for each signature, counting the signatures inside Ed25519, secp256k1 and secp256r1 precompile instructions, and the priority fee, the compute-unit limit times the compute-unit price in micro-lamports, divided by a million and rounded up. Both come from the message itself:

Transfer, one signature — 5,000

Two signatures — 10,000

200,000 CU at 1,000,000 µlamports — 205,000

200,000 CU at 1 µlamport — 5,001

Values in lamports, from our local validator. The last row is the rounding: 0.2 lamports of priority fee costs 1. How that fee ranks a transaction against others is a separate calculation. Nothing here depends on the recent blockhash or on a durable nonce.

What the old version checked first

Up to 4.4, Agave’s bank refused to price a message unless its blockhash was in the bank’s blockhash queue or, failing that, the message was a durable-nonce transaction whose nonce account stored exactly that value. Either check failing meant null. So did invalid compute-budget instructions, such as two SetComputeUnitLimit instructions. Three different problems, one answer.

The catch is in the queue. A bank keeps the last 300 blockhashes, but accepts a transaction only if its blockhash is at most 150 blocks old (blockhash_queue.rs, is_blockhash_valid). The fee check asked “is it in the queue?”, not “is it young enough?”. We held one blockhash on the local validator and recorded when each method gave up on it:

Blockhash issued at block height 360 — +0

lastValidBlockHeight 510 — +150 blocks

isBlockhashValid false, at height 511 — +151 blocks

getFeeForMessage still — 5,000

sendTransaction — Blockhash not found

getFeeForMessage null, at height 661 — +301 blocks

For 150 blocks, about a minute at mainnet’s 400 ms slots, the old method priced a transaction that the network rejected. Code that waits for a null before refreshing its blockhash spends that minute sending transactions that are dropped.

What Agave 4.5 changes

The new function reads the compute-budget instructions and computes the fee, nothing else. The changelog lists it under 4.5.0, which was unreleased at the merge, when the stable line was 4.3 and the beta 4.4. Side by side, with the old column measured on 4.2.1 and the new one read from the merged code:

Fresh blockhash — 5,000 → 5,000

Blockhash 151–300 blocks old — 5,000 → 5,000

Blockhash dropped or never seen — null → 5,000

Durable nonce, stored value — 5,000 → 5,000

Durable nonce, any other value — null → 5,000

Duplicate SetComputeUnitLimit — null → null

v0, lookup table missing — error → error

The last row is a JSON-RPC error, -32602 “invalid transaction message: Attempted to lookup addresses from a table that does not exist”: the RPC method resolves lookup tables before it asks the bank. The issue behind the change gives one more reason for it: the nonce check was the only part of the fee calculation that needed resolved addresses, which kept RPC from using a lighter message type. In 4.5 a null means one thing only: the compute-budget instructions are invalid. Like the 4.4 RPC changes, it will reach clients gradually, as RPC providers upgrade, so code meets both behaviours for a while.

What a fee does not promise

A fee is computed from the message alone, in every version. It never checked the things that decide whether a transaction lands. We signed and sent three transactions the local node had just priced at 5,000 lamports:

Fee payer with no account: “no record of a prior credit” — rejected

Transfer above the payer’s balance: custom program error 0x1 — rejected

Blockhash past its last valid height: “Blockhash not found” — rejected

All three were rejected in preflight simulation. A fee also says nothing about signatures, account locks, the compute the instructions will use or whether a program succeeds. From 4.5 it says nothing about the blockhash or the nonce either.

What to call instead

Is the blockhash still usable?   getLatestBlockhash -> lastValidBlockHeight,
                                 then getBlockHeight <= lastValidBlockHeight
                                 (or isBlockhashValid)
Is the durable nonce current?    getAccountInfo on the nonce account (jsonParsed):
                                 its stored blockhash must equal the message's
Would it execute right now?      simulateTransaction
What will it pay?                getFeeForMessage

In our run isBlockhashValid first reported false at block height 511, one past the blockhash’s lastValidBlockHeight of 510, and sendTransaction rejected it there, so the height comparison matches what the node enforces. Simulation is the closest thing to a validity check, but it is one node’s view at one moment: an account can change between simulation and landing.

What this does not show

We measured Agave 4.2.1’s test validator, whose fee check matches the 4.4 release line for line in behaviour; we did not run 4.4 or 4.5, so the 4.5 column comes from the merged code. A local validator makes blocks at its own pace, so the 150-block window is in blocks, not seconds. Every call used processed commitment on a single node.

getFeeForMessage: Questions People Actually Ask

Does getFeeForMessage check whether a Solana blockhash is still valid?

No. From Agave 4.5 it does not look at the blockhash at all. Before that it only checked that the blockhash was still in the bank’s queue of the last 300, while transactions are accepted only up to 150 blocks, so it returned fees for blockhashes the network had already stopped accepting. Use the lastValidBlockHeight returned by getLatestBlockhash, or isBlockhashValid.

When does getFeeForMessage return null in Agave 4.5?

Only when the message’s compute-budget instructions are invalid, for example two SetComputeUnitLimit instructions, bad instruction data or an invalid heap size. A message that cannot be read at all, such as a v0 message whose address lookup table does not exist, gets a JSON-RPC error instead of null.

How long is a Solana blockhash valid for transactions?

150 blocks after the block that produced it. getLatestBlockhash returns lastValidBlockHeight, the last block height at which a transaction using it can land. In our test isBlockhashValid turned false at lastValidBlockHeight + 1, and sendTransaction rejected the blockhash from then on.

Does getFeeForMessage include the priority fee?

Yes. It adds the priority fee set by the message’s compute-budget instructions, compute-unit limit times compute-unit price in micro-lamports, divided by a million and rounded up, to 5,000 lamports per signature, counting the signatures in Ed25519, secp256k1 and secp256r1 precompile instructions too.

Does a fee from getFeeForMessage mean the transaction will succeed?

No. It is computed from the message alone. It does not check signatures, whether the fee payer exists or can pay, the blockhash or durable nonce (from Agave 4.5), account locks or whether the instructions succeed. Simulate the transaction to check those.

The one-line version

getFeeForMessage prices a message and nothing more: from Agave 4.5 it returns a fee for expired blockhashes and wrong nonces, and before that it kept pricing blockhashes for 150 blocks after the network stopped accepting them, so check expiry with lastValidBlockHeight and validity with simulateTransaction.

Sources: Agave #16519, merged as 8ffb33c9, and issue #15876; the 4.4.0 release source for the old check, the blockhash queue and the processing age. Measurements are from our own client against a local solana-test-validator 4.2.1.

Token-2022 v12: What Changed for Rust Developers

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:12 +0000

Originally published on xroot.dev.

On 28 October the Token-2022 repository released v12. It rewrites the program on Pinocchio, roughly halving the compute cost of a transfer, and publishes seven crates with breaking version bumps. The program every Solana wallet and exchange calls did not change: all three clusters still run v11.1.0, byte for byte.

So for now, “v12” means Rust crates. We diffed the v11.1.0 and v12.0.0 tags, read the deployed program on mainnet, devnet and testnet, and resolved both versions with Cargo. What follows is what breaks for Rust code, what does not, and how to tell when the new program actually ships.

Published is not deployed

The deployed Token-2022 binary carries a security.txt that names the release it was built from. Read it from the program-data account and hash the same bytes, and you know exactly what a cluster runs:

Mainnet — program@v11.1.0, since 23 Oct

Devnet, testnet — program@v11.1.0, since 23 Sep

SHA-256, all three — 5e888b29⁠…⁠6413d9

v11.1.0 verified build — 5e888b29⁠…⁠6413d9

v12.0.0 binary on any cluster — none

Mainnet took v11.1.0 on 23 October at 15:39 UTC, a month after devnet and testnet. The v11.1.0 release notes carry a deployment section, a verifiable-build hash and an audit link. The v12.0.0 notes list changes only. Until a v12 build is verified and deployed, every Token-2022 instruction on chain runs the v11.1.0 code, whatever crate version your project depends on. To check for yourself:

import base64, hashlib, json, struct, urllib.request

RPC = "https://api.mainnet-beta.solana.com"
PROGRAMDATA = "DoU57AYuPFu2QU514RktNPG22QhApEjnKxnBcu4BHDTY"  # Token-2022's program-data account

def rpc(method, params):
    req = urllib.request.Request(RPC, json.dumps({"jsonrpc": "2.0", "id": 1, "method": method,
                                 "params": params}).encode(), {"content-type": "application/json"})
    return json.load(urllib.request.urlopen(req))["result"]

data = base64.b64decode(rpc("getAccountInfo", [PROGRAMDATA, {"encoding": "base64"}])["value"]["data"][0])
slot = struct.unpack_from("<Q", data, 4)[0]          # last deploy slot
elf = data[45:].rstrip(b"\x00")                     # 45-byte header, zero padding stripped
tag = elf.find(b"source_release\x00") + 15
print("deployed at slot", slot)                      # 460497271
print("source_release ", elf[tag:elf.index(b"\x00", tag)].decode())   # program@v11.1.0
print("sha256         ", hashlib.sha256(elf).hexdigest())             # 5e888b29…6413d9

The Pinocchio rewrite, and the savings still waiting

Pull request #1469 replaces the SDK entrypoint with Pinocchio’s and switches the processor from AccountInfo to Pinocchio’s AccountView, the zero-copy view of the input buffer. It is the same move that made p-token cheap for the original token program. The pull request reports these instruction counts from its own tests:

transfer — 1,444 → 719 CU

transfer_checked — 1,782 → 856 CU

initialize_account — 1,822 → 614 CU

initialize_mint — 1,347 → 553 CU

mint_to — 1,262 → 545 CU

burn — 1,372 → 638 CU

close_account — 1,219 → 535 CU

These are the pull request’s measurements from its instruction-count tests, not ours, and extensions add their own cost on top. They become real only when a v12 binary is deployed. Until then, a transfer of any Token-2022 asset on mainnet costs what v11.1.0 charges.

What breaks in Rust

Most Rust code depends on spl-token-2022-interface, the crate with instruction builders and account layouts. Its builders and state types did not change. The breaks are in four places.

1. The processor signature

In the spl-token-2022 program crate, Processor::process changed from &[AccountInfo] to &mut [AccountView]. Test suites that run Token-2022 as a native processor, with processor!(spl_token_2022::processor::Processor::process), stop compiling on 12.0.0. Load the program’s binary into the test instead, or keep the test on 11.

2. The zk-ops feature is gone

#1524 removed zk-ops, a default feature its own manifest said to remove “once the underlying syscalls are released on all networks”. It gated the confidential-transfer and confidential mint-and-burn processors, which are now always compiled in. A manifest that still names the feature does not build. We asked Cargo to resolve both versions with it:

# spl-token-2022 = { version = "=11.1.0", default-features = false, features = ["no-entrypoint", "zk-ops"] }
#   resolves

# spl-token-2022 = { version = "=12.0.0", default-features = false, features = ["no-entrypoint", "zk-ops"] }
error: failed to select a version for `spl-token-2022`.
package `featcheck` depends on `spl-token-2022` with feature `zk-ops` but `spl-token-2022` does not have that feature.
help: available features: no-entrypoint, test-sbf

3. Two interface helpers take AccountView

In spl-token-2022-interface 4.0, alloc_and_serialize and alloc_and_serialize_variable_len_extension now take &mut AccountView. They grow an account and write an extension into its TLV data; Token-2022 itself uses them for its token-metadata and token-group extensions, and a program that stores TLV data the same way can call them too. Callers holding an AccountInfo need to move to Pinocchio’s types or stay on interface 3.

4. The zero-knowledge types moved a major version

The interface re-exports its proof types from solana-zk-elgamal-proof-interface, now 1.0.0 instead of 0.1. Its confidential builders take those types, for example ProofLocation<CiphertextCommitmentEqualityProofData>. Proof data built against the old crate will not type-check. The confidential stack moves together: interface 4.0, proof-generation and proof-extraction 0.7, and solana-zk-sdk 8.

Instruction builders — unchanged

Mint and account layouts — unchanged

onchain CPI helpers — still AccountInfo

Processor::process — AccountView

zk-ops feature — removed

Confidential transfers: new call, same keys

Changing how confidential keys are derived would be the dangerous kind of break: a wallet that derives different keys can no longer decrypt balances it already holds. zk-sdk 8 changed the derivation API, but not the keys. In 7.0.1, derive_confidential_keys(signer, seed) signs "solana-conf-bal/v1" ‖ seed. In 8.0.1, STANDARD_DERIVATION_MESSAGE is defined as that same "solana-conf-bal/v1", so the seedless call signs the same bytes the old empty-seed call did.

// zk-sdk 7 (Token-2022 v11 stack)
let (elgamal, ae) = derive_confidential_keys(&signer, b"")?;

// zk-sdk 8 (v12 stack): the seed parameter is gone; seeded keys use
// derive_confidential_keys_with_seed(&signer, seed)
let (elgamal, ae) = derive_confidential_keys(&signer)?;

// zk-sdk 8 takes a solana-signer v4 Signer. Signers from the Agave 4.3 stack
// are v3, so sign the standard message yourself (same keys):
let signature = signer.try_sign_message(STANDARD_DERIVATION_MESSAGE)?;
let (elgamal, ae) = derive_confidential_keys_from_signature(&signature)?;

The last pattern is the one Token-2022’s own CLI and client tests now use, per #1584. zk-sdk 8.0.1 depends on solana-signer 4.0.0, while 7.0.1 used 3.0.0, and a v3 keypair does not satisfy the v4 trait.

Two smaller fixes ride along. The interface documentation listed the multisig accounts for confidential mint and burn wrongly, naming the mint twice and dropping the token account. The builders and the IDL that generates the JavaScript client were already right, so only hand-written integrations that followed the comments are affected (#1509). And spl-token-client 0.21.0 no longer builds proof-record transactions that exceed the packet limit when a memo, nonce or compute-budget instruction is added (#1550).

An upgrade order that works

Every crate in the release took a breaking version bump, so nothing moves until you change a version requirement: Cargo will not pick 12.0.0 to satisfy "11". When you do move:

Builders and account reads only — interface 3 → 4

Token-2022 as a native test processor — load the binary

A manifest that names zk-ops — delete the feature

TLV account helpers — move to AccountView

Confidential transfers — upgrade the stack together

None of this changes what happens on chain. The mint and account layouts did not change, and the instruction builders encode every instruction exactly as interface 3 did.

What this does not show

We did not build or run v12, so the compute figures are the pull request’s. Our Cargo check covered dependency resolution, not a compile of downstream code. Where we say a signature or type changed, we read it from the tagged source. The deployment facts come from each cluster’s program-data account, and a later upgrade would show up there first.

Token-2022 v12: Questions People Actually Ask

Is Token-2022 v12 live on Solana mainnet?

No. Mainnet, devnet and testnet all run the same v11.1.0 binary: its embedded security.txt says source_release program@v11.1.0 and its hash matches the v11.1.0 verified build, 5e888b29…. Mainnet was upgraded to it on 23 October 2026. v12.0.0 was published as Rust crates on 28 October, and its release notes have no deployment or verification section.

Will upgrading the spl-token-2022 crate to 12.0.0 break my build?

Only if you use the program crate itself. Processor::process now takes &mut [AccountView] instead of &[AccountInfo], so registering Token-2022 as a native processor in tests no longer compiles, and the zk-ops feature no longer exists, so a Cargo.toml that names it fails to resolve. Instruction builders, state parsing and the onchain CPI helpers are unchanged.

Does solana-zk-sdk 8 change my confidential transfer keys?

No. zk-sdk 8’s derive_confidential_keys(signer) signs STANDARD_DERIVATION_MESSAGE, which is the constant "solana-conf-bal/v1", and zk-sdk 7’s derive_confidential_keys(signer, b"") signed the same bytes. The keys are identical; only the function signature changed, and seeded derivation moved to derive_confidential_keys_with_seed.

How much cheaper is Token-2022 v12?

According to the instruction-count tests in the pull request that moved the program to Pinocchio, transfer falls from 1,444 to 719 compute units and transfer_checked from 1,782 to 856, roughly half. None of that applies on chain until a v12 binary is deployed.

How do I check which Token-2022 version a cluster runs?

Read the program-data account DoU57AYuPFu2QU514RktNPG22QhApEjnKxnBcu4BHDTY, skip its 45-byte header and trailing zero bytes, and read the source_release field of the embedded security.txt. Hashing the same bytes with SHA-256 gives the value solana-verify reports for a verified build.

The one-line version

v12 is a Pinocchio rewrite that halves transfer costs, but for now it exists only as crates: it breaks native test processors, the zk-ops feature and two TLV helpers, keeps confidential keys identical, and changes nothing on chain until a verified v12 binary replaces the v11.1.0 that every cluster runs.

For the extensions themselves, see pausable and permissioned burn and how confidential transfers compare.

Sources: the v12.0.0 and v11.1.0 releases and the tagged source (1bc00fa5, 8867f751); pull requests #1469, #1524, #1584, #1509 and #1550; the solana-zk-sdk 7.0.1 and 8.0.1 crate sources; and the Token-2022 program-data account on mainnet, devnet and testnet.

One Solana Slot, Multiple Banks: Fork-Aware Geyser Indexing

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:10 +0000

Originally published on xroot.dev.

Your Geyser plugin buffers account updates by slot and writes a slot to the analytics tables when the slot is rooted. For as long as a slot meant one bank, that was correct. In October, Agave’s accounts database finished a migration whose stated purpose is to let “multiple banks with the same slot” exist side by side.

A bank is one replay of one block. When a node replays a slot twice, both replays stream their account writes and transactions to every Geyser plugin as they execute, and only one of them is ever finalized. The interface has been naming the bank behind each update since version 4.3.0. An indexer that keys by slot alone merges the two, and the abandoned bank’s data reaches the finalized table.

Here is where the second bank comes from, what a plugin is and is not told, what a slot-keyed indexer commits wrongly, and the bank-keyed buffer that fixes it, with tests that show both.

A slot is not a bank

A slot is a position in time: the window one leader has to produce a block. A bank is a node’s execution of a specific block at that position, with its own account changes, its own transaction results and its own ID. The Solana SDK says it plainly: a BankId “is unique even if the slot number of two different slots is the same”.

Agave’s accounts database used to assume the opposite inside its write cache, the in-memory layer that holds a bank’s account writes until its slot is rooted and flushed. Between late September and the end of October, one Agave engineer moved it from slot keys to bank keys:

BankId becomes its own type (#15620) — 2 Oct

Ancestors carry (slot, bank ID) (#15857) — 8 Oct

Write cache rekeyed by bank ID (#16102) — 20 Oct

Roots added by bank (#16262) — 23 Oct

Purge by bank ID (#16360) — 27 Oct

Flush and freeze by bank ID (#16447, #16459) — 28 Oct

Slot-to-bank map removed (#16497) — 28 Oct

Purge deferred to bank drop (#16508) — 31 Oct

The two highlighted changes say what the series is for. #16360 switched purging to bank IDs “so multiple banks with the same slot can exist in the write cache”. #16497 removed the last lookup by slot, after which the cache “no longer asserts one bank per slot: banks at the same slot each keep their own cache, and removing a bank removes only its own cache.” Before the series, the old bank’s cache had to be purged inline before the slot could be created again. #16508 moved that purge to the background and measured it falling from about 2 milliseconds to about 100 microseconds.

Where the second bank comes from

Three paths in Agave’s replay stage clear a bank and let the same slot be replayed into a new one.

Switching to the cluster’s version of a block. A leader can produce more than one version of a block for its slot. Under Alpenglow, live on mainnet since 21 October, votor tells replay when the version the cluster certified differs from the one the node replayed. Replay repairs the cluster’s version, then clears its own bank for that slot and every descendant and replays again. The same slots come back with new bank IDs.
Fast leader handover. The first slot of a leader’s four-slot window may start on an optimistic parent, before the previous leader’s last block is settled. If the leader then switches parents, the block carries an UpdateParent marker, and replay clears the in-progress bank and recreates it from the marker’s position in the block.
The leader’s own optimistic bank. On the producing side, the same handover clears the bank the leader started building and replaces it.

The second and third paths are fast leader handover, and replay’s restart path checks the FastLeaderHandover11111111111111111111111111 feature, which has not been activated on mainnet. The first needs only a leader that produced two versions of a block, which is rare, but the path is live today. The write-cache series is what lets these replays happen without the old bank’s cache being torn down first.

What a Geyser plugin is told, and what it is not

Since agave-geyser-plugin-interface 4.3.0, the callbacks that carry data name the bank they came from. In version 6.0.0, the current one on 31 October:

update_account_for_bank — slot + bank ID, every write

notify_transaction_for_bank — slot + bank ID, every transaction

update_bank_status · Rooted — bank ID + parent, once per rooted slot

update_slot_status · Dead — slot only, no bank ID

notify_entry_update_parent — cleared bank ID, entry plugins only

bank cleared to switch block versions — no callback at all

Three things in that table decide how an indexer has to be built.

Discards are mostly silent. The only notice of a cleared bank is the UpdateParent entry notification, and the plugin manager sends it only to plugins that enable entry notifications, which most account indexers do not. A bank cleared to switch block versions produces nothing at all. By the time either happens, the bank’s writes and transactions have already been delivered.

Finality is per bank, and ordered. When votor roots a block, the RPC tracker sorts the newly rooted chain by slot and reports each slot once, with its bank ID and with the previous root as its parent. The chain arrives contiguous: a slot between a rooted slot and its reported parent was never rooted. And a bank’s Rooted arrives after its data. Account writes are delivered synchronously while the bank replays, before it can freeze. Transactions travel through a separate service, but the root notification waits on that service’s declared work before it is processed.

Old plugins are blind. The slot-only callbacks were deprecated in 4.3.0, and each new bank-aware method’s default implementation forwards to its old counterpart, dropping the bank ID on the way. A plugin that still implements only update_account keeps compiling and keeps receiving data, with no way to tell two banks of one slot apart.

What a slot-keyed indexer commits

To see the failure without a validator, we fed the event sequence these paths produce to two small indexers in Rust. One buffers by slot and commits a slot when it is rooted. The other buffers by slot and bank ID. Slot 104 is replayed twice: bank 5 executes transactions a and b, writing account X to 70 and account Y to 1, and is then cleared. Bank 6 executes transaction c, writing X to 90, and is rooted.

// bank 5: the version that is abandoned
ix.transaction(104, 5, sig(0xa));
ix.account(104, 5, w(X, 70, 2));
ix.transaction(104, 5, sig(0xb));
ix.account(104, 5, w(Y, 1, 3));
// bank 6: the version the cluster finalizes
ix.transaction(104, 6, sig(0xc));
ix.account(104, 6, w(X, 90, 4));
ix.rooted(104, 103, 6);

// slot-keyed: Y = 1 is "finalized", slot 104 has 3 transactions
// bank-keyed: no Y, slot 104 has 1 transaction (c), X = 90

The slot-keyed indexer commits a value for Y that never existed on the finalized chain, and counts three transactions in a block that has one. Volume, fee and activity tables built on it are inflated by exactly the abandoned bank’s work.

It does get X right, and only by luck. Both banks wrote X, and the higher write_version happened to belong to bank 6, because the clearing paths remove the old bank before the new one replays. Swap the arrival order and a third test shows the slot-keyed indexer committing the abandoned value. Nothing in the interface promises that order, and the write-cache series exists to make same-slot banks cheaper to keep around.

Key by bank, commit on the rooted bank

The fix is a different buffer key and one rule at root time:

pub struct BankKeyed {
    pending: BTreeMap<(Slot, BankId), Pending>,
    pub finalized: Finalized,
}

impl BankKeyed {
    // update_account_for_bank / notify_transaction_for_bank
    pub fn account(&mut self, slot: Slot, bank_id: BankId, w: AccountWrite) {
        self.pending.entry((slot, bank_id)).or_default().write(w);
    }

    // update_bank_status(slot, parent, Rooted, bank_id): one call per newly
    // rooted slot, in slot order, parent = the previous root. Every bank
    // buffered in (parent, slot] is decided now: keep the rooted one.
    pub fn rooted(&mut self, slot: Slot, parent: Slot, bank_id: BankId) {
        let decided: Vec<_> = self
            .pending
            .range((parent + 1, BankId::MIN)..=(slot, BankId::MAX))
            .map(|(key, _)| *key)
            .collect();
        for key in decided {
            let p = self.pending.remove(&key).expect("key was just listed");
            if key == (slot, bank_id) {
                p.commit(slot, &mut self.finalized);
            }
        }
    }
}

The range does two jobs. It drops other banks at the rooted slot, the same-slot case, and it drops banks at slots the chain skipped, an ordinary abandoned fork, because a slot between a root and its reported parent will never be rooted. Banks above the rooted slot stay buffered until their own turn. Handling notify_entry_update_parent is optional: it lets a cleared bank’s buffer go early, but correctness rests on the rooted bank ID, the one signal every plugin receives.

Six tests pin both behaviours down. Two show the slot-keyed indexer committing the abandoned bank’s data, one of them through arrival order alone. The others show the bank-keyed buffer handling the same-slot case, an abandoned fork at a skipped slot, descendants of the root that must stay buffered, and the early discard. Inside a bank, the highest write_version per account is its final state, and that rule is still correct. It just has to be applied per bank, not per slot.

What this does not show

The tests replay event sequences derived from Agave’s source. They are not a captured Geyser stream from a validator, and we have not measured how often a mainnet node clears a bank today. With fast leader handover inactive, only the block-version switch can do it on mainnet, and that needs a leader to have produced two versions of a block.

The ordering guarantees in section 03 come from reading the notification paths, not from a fault-injection test. And a Dead status still names only a slot. A plugin that must react to a dead bank, rather than simply never committing it, cannot tell from that call which of a slot’s banks died.

Same-Slot Banks: Questions People Actually Ask

Can two Solana banks have the same slot?

Yes. A bank is one replay of one block, and Agave gives every bank a unique bank ID even when two banks share a slot. Under Alpenglow a node replaces its bank for a slot when the cluster settles on a different version of that block, and fast leader handover adds a second way once its feature activates.

Does Geyser tell a plugin which bank an update came from?

Since agave-geyser-plugin-interface 4.3.0, yes: update_account_for_bank, notify_transaction_for_bank and update_bank_status all carry a bank_id. The older slot-only callbacks are deprecated, and the default bank-aware methods forward to them without the bank ID.

How does an indexer know which bank was finalized?

Agave reports every newly rooted slot through update_bank_status with SlotStatus::Rooted and the rooted bank’s ID, in slot order, with the previous root as the parent. Commit only that bank, and discard every other bank buffered between the parent and the rooted slot.

Is buffering by slot until the slot is rooted enough?

No. A slot-keyed buffer merges every bank that ever replayed the slot, so accounts written only by an abandoned bank and transactions executed only in it reach the finalized table. Key the buffer by slot and bank ID.

Does Agave notify a plugin when it discards a bank?

Not in general. A bank cleared by fast leader handover produces an UpdateParent entry notification, but only to plugins that enable entry notifications. A bank cleared to switch to the cluster’s version of a block produces no notification at all. The rooted bank ID is the only signal every plugin gets.

The one-line version

A slot can have more than one bank, Geyser streams all of them, and only the bank named in the Rooted status is the finalized one. Key the buffer by slot and bank ID, and implement the _for_bank callbacks.

The pipeline this buffer belongs in is the subject of ingesting the Solana firehose with Rust, and the certificates that decide which bank is rooted are in Alpenglow finality in numbers. What a block says about its own producer is in which client built each block.

Sources: Agave master at commit 5817ebe009, the merge of #16508: replay_stage.rs, update_parent.rs, optimistically_confirmed_bank_tracker.rs, entry_notifier.rs and transaction_status_service.rs; pull requests #16360, #16497 and #16508; the GeyserPlugin trait in agave-geyser-plugin-interface 6.0.0; and solana_clock::BankId. The feature account FastLeaderHandover11111111111111111111111111 does not exist on mainnet.

One Lamport Can Break Consensus: Solana’s Integer Inflation

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:09 +0000

Originally published on xroot.dev.

Once an epoch, every Solana validator computes how many lamports of inflation to mint, adds them to the chain’s capitalization, and folds the result into its bank hash. Today that calculation runs in floating point, with a powf in the middle of it.

SIMD-0607, written by engineers from both Anza and Firedancer, replaces every floating-point step with integer arithmetic specified down to the order of its divisions. Agave merged the implementation on 30 October behind a feature gate. We copied the specification’s Rust into a test harness to check its claims and to measure the problem it fixes. Two mathematically identical float formulas for the same reward disagreed by one lamport in 62 of 60,000 epochs. The integer path cannot disagree with itself.

Why one lamport is a consensus failure

Capitalization is part of the state every validator hashes. If two clients compute the same epoch’s reward and land one lamport apart, their capitalizations differ, their bank hashes differ, and the network has a disagreement no vote can fix. The proposal’s motivation is exactly that: these values “must be computed identically by all validator clients, without relying on IEEE-754 behavior or platform math-library functions such as powf.”

Basic float operations are deterministic. Exponentiation is not specified to the last bit, and the inflation rate is 0.08 × (1 − taper)^year. To see how much that matters, we computed the legacy epoch reward two ways that are equal on paper, (1 − taper).powf(year) and exp(year × ln(1 − taper)), for 6,000 epochs in each of five slot-time regimes and both tapers:

Capitalization 10¹⁸ lamports — 62 of 60,000 rewards differ

Capitalization 6.2 × 10¹⁷ lamports — 47 of 60,000 rewards differ

Size of every difference — 1 lamport

About one epoch in a thousand, the truncation that turns a float reward into lamports lands on the other side of an integer. That is not a claim that Agave and Firedancer compute different rewards today. It is the reason neither should depend on how a math library rounds the last bit.

The integer schedule

Rates are integers over RATE_SCALE = 10^15, so 8% is 80_000_000_000_000. Decay factors are integers over 2^64, a finer scale because a factor very close to one is multiplied by itself across hundreds of millions of slots. The per-slot factor is derived, not tabulated: a 32-term series for the logarithm of the taper and a cubic approximation of the exponential, then a binary exponentiation whose order and flooring are fixed:

fn decay_per_slot(ns: u128, taper_num: u32, taper_den: u32) -> Option<u128> {
    // -ln(1 - taper) = ln(taper_den / (taper_den - taper_num)), scaled by 2^64
    let annual_exponent =
        approximate_logarithm(taper_den, taper_den.checked_sub(taper_num)?)?;
    let slot_exponent = annual_exponent.checked_mul(ns)? / YEAR_NS;
    approximate_exponential(slot_exponent) // 2^64 * exp(-x), cubic
}

fn pow_decay_floor(mut base: u128, mut n: u64) -> u128 {
    let mut result = DECAY_SCALE;
    while n > 0 {
        if n & 1 != 0 { result = mul_decay_floor(result, base); }
        n >>= 1;
        if n > 0 { base = mul_decay_floor(base, base); }
    }
    result
}

// rate   = max(TERMINAL_RATE, floor(anchor_rate * decay / 2^64))
// annual = floor(capitalization * rate / 10^15)
// reward = floor(annual * slots_in_epoch * ns_per_slot / YEAR_NS)

Every step floors, every multiplication is checked, and an overflow is an error the validator must turn into a panic. The specification forbids wrapping, saturating or substituting a value, and it forbids falling back to floating point.

Its numbers, reproduced to the lamport

The proposal publishes how far the integer schedule drifts from the floating-point one: the largest difference in a single epoch’s reward over 6,000 epochs, at a capitalization of 10¹⁸ lamports, across the 400, 350, 300, 250 and 200 ms slot regimes. Running its functions verbatim against its stated float baseline:

15% taper, largest difference — 5,923 lamports (spec: 5,923)

30% taper, largest difference — 1,061 lamports (spec: 1,061)

Where the 15% worst case falls — 350 ms, epoch 1,282

Where the 30% worst case falls — 400 ms, epoch 509

32-term logarithm vs 200 terms — identical, both tapers

Both drift figures match exactly. So does the claim that 32 terms of the logarithm series are enough: for the 15% and 30% tapers, the 32-term sum and a 200-term sum are the same integer, to the last of 2⁶⁴ units. The drift is the price of the change, at most a few thousand lamports of an epoch’s reward. A relative difference below 7 × 10⁻¹¹ buys a reward every client computes identically.

Overflow, and why it panics

With 128-bit intermediates, the reward arithmetic stays valid up to a capitalization of about 18.4 trillion SOL, a thousand times beyond the 18.4 billion SOL a 64-bit lamport count can hold at all. The checks that can fail in practice are the invalid inputs: a zero slot duration, or a taper of 100% or more, return an error before any arithmetic.

The panic rule is deliberate. A validator that cannot compute the reward exactly as specified is safer stopped than running on a number the rest of the cluster did not compute. That is the same reasoning as the proposal itself, applied to its own failure path.

The activation order with SIMD-0550

SIMD-0550 doubles the yearly disinflation from 15% to 30%. Its original design kept issuance continuous by recomputing the stored initial rate at activation, initial = anchor / (1 − 0.30)^year, with powf. Our earlier post on SIMD-0550 described that design. An amendment merged on 29 October replaced it: SIMD-0607 must activate first or at the same boundary, the anchor is computed with the integer 15% schedule including its terminal clamp, and the 30% integer taper applies from the activation slot. Agave rekeyed the SIMD-0550 gate in the 4.4.0 release.

Anchor rate, activation at year 6 (illustrative) — 3.0172%

Rate zero slots after activation — 3.0172%

Rate one year later — 2.1120%

Naive governor formula, 0.08 × 0.70⁶ — 1.5% (terminal floor)

The anchor works: at zero elapsed slots the decay factor is exactly 2⁶⁴, so the rate does not move. The trap is for anyone reading the stored governor. After activation it reports initial = 0.08 and taper = 0.30, and the textbook formula built from those two numbers, which measures decay from genesis, lands on the 1.5% floor while the chain is minting at about 3%. Forward curves should start from getInflationRate, not from getInflationGovernor.

Where it stands

Agave’s implementation, #16355, merged on 30 October behind the remove_runtime_float_ops gate. Neither that gate nor SIMD-0550’s has been activated on mainnet. When SIMD-0607 does activate at the boundary into epoch E+1, rewards earned in epoch E are still paid with the legacy calculation, and the integer path starts with rewards earned in E+1.

What this does not show

We ran the specification’s code, not Agave’s implementation of it, and compared against the float baseline the specification states rather than against a running validator. The two float paths in section 01 are a test of sensitivity, not a measurement of any client. The year-6 activation in section 05 is illustrative, at constant 400 ms slots; the real anchor depends on the slot-time history up to the activation slot.

Integer Inflation: Questions People Actually Ask

Why does Solana want to remove floating point from inflation?

Inflation rewards are added to capitalization, which is part of the bank hash. If two validator clients compute an epoch’s reward one lamport apart, their bank hashes differ. Floating-point exponentiation depends on the math library, and mathematically identical float formulas can round to different lamport amounts. SIMD-0607 specifies the whole calculation in integers so every client gets the same number.

How large is the difference between the integer and floating-point schedules?

At most 5,923 lamports per epoch for the 15% taper and 1,061 for the 30% taper, over 6,000 epochs and five slot-time regimes at a capitalization of 10^18 lamports, a relative difference below 7.03 × 10^-11. We reproduced both figures exactly from the specification’s code.

What does SIMD-0607 have to do with SIMD-0550?

SIMD-0550 doubles the disinflation rate from 15% to 30% a year. Since an amendment merged on 29 October 2026, it must activate after or together with SIMD-0607: the anchor rate at activation is computed with the integer 15% schedule, and the 30% integer taper applies from there. The stored inflation governor keeps initial 0.08 and switches taper to 0.30.

Can I compute Solana’s inflation rate from getInflationGovernor?

Not after SIMD-0550 activates. The governor will report initial 0.08 and taper 0.30, but the rate decays from the activation anchor, not from genesis, so initial × (1 − taper)^years gives the wrong answer. Read getInflationRate, which the node computes.

Is SIMD-0607 active on mainnet?

Not as of 30 October 2026. Agave merged the implementation that day behind the remove_runtime_float_ops feature gate, which has not been activated on mainnet.

The one-line version

Floating point lets two correct implementations disagree by a lamport about once in a thousand epochs; SIMD-0607 trades a few thousand lamports of drift per epoch for a reward every client computes identically, and SIMD-0550 now waits for it.

The faster disinflation itself is in Solana’s inflation will decay twice as fast, how those rewards reach stake accounts is in when staking rewards arrive, and why two independent clients matter at all is in which client built each block.

Sources: SIMD-0607 as amended at commit 2934dbeb; the SIMD-0550 amendment; Agave #16355 (commit 9bcf93e368) and #16499. Measurements are from the specification’s functions run in our own harness.

Agave CLI Transaction V1: Which Signing Workflows Break?

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:08 +0000

Originally published on xroot.dev.

On 29 October, Agave merged a change that makes the solana command-line tool build every transaction as a version 1 message. Not optionally and not behind a flag: there is no longer a code path in the CLI that compiles a legacy message.

Its changelog entry carries one warning: hardware wallets that cannot parse v1 “may no longer work with the CLI”. That is the visible break. There are three quieter ones, plus a list of things that look like they should break and do not. We traced each through the code at the merge commit and measured the ones with numbers by compiling the same messages the new CLI compiles.

One builder, one version

Pull request 16448 replaces hand-built message assembly across eleven files with a MessageBuilder, whose build returns VersionedMessage::V1 and nothing else. Three things change in what the CLI emits, all because the v1 format moves resource requests out of ComputeBudget instructions and into the message itself:

First byte of a transfer message — 0x01 → 0x81

Same transfer, message size — 150 → 164 bytes

Compute limit when not simulated — 200,000 per instruction, max 1.4M

Loaded-accounts data limit — always 64 MiB

Priority fee — flat: ⌈price × limit ÷ 10⁶⌉ lamports

The explicit limits are not optional either. A v1 transaction that requests no compute limit and no loaded-accounts size gets zero of both and fails at execution, so the builder always writes them. The rest of this post is what those three facts do to the ways people sign.

The Ledger app refuses them, and fails safe

The CLI side of Ledger signing does not care about message versions: it chunks the message bytes into sign APDUs and lets the device decide. The device runs the Solana app, version 1.16.1 on the day of the merge, and its parser accepts any first byte with the high bit set as “a versioned message”, then reads the rest with the v0 layout. Walk the CLI’s v1 transfer through it:

81            version byte          → versioned, version 1
01 00 01      header                → 1 signer, 0 + 1 read-only
0c            [v1: config mask]     → read as "12 account keys"
              12 × 32 = 384 bytes needed, 159 left
                                    → check_buffer_length fails
device → 0x6a80  CLI → "Ledger received invalid Solana message"

For a small message the misread account count runs off the end of the buffer. A large v1 message can survive that read, but the next step looks for your public key among the first “accounts”, and in a v1 message those bytes are the config mask and the lifetime, never your key. Depending on where the misread runs out, the device answers 0x6a80 or 0x6a81. The app’s sign handler returns on both errors before it reaches the blind-signing branch, so this fails closed: the device refuses rather than showing wrong amounts or offering to sign a hash.

A reviewer on the pull request put the cost plainly: Ledger has not implemented v1, and when it does, the change will “force all users to update their Ledger firmware”. The suggested workaround is to install an earlier CLI. We read the Ledger app’s source rather than signing on a device, and did not check Trezor or Keystone firmware, which the CLI also supports.

Offline signing across CLI versions

Offline signing with --sign-only works because every party rebuilds the same message from the same arguments and signs the same bytes. The submitter attaches the collected signatures as --signer PUBKEY=SIGNATURE, and each is checked against the message it compiles.

A cold signer on a 4.4 CLI compiles the legacy encoding; a submitter on a build with this change compiles v1. Same instructions, same blockhash, different bytes. We signed the legacy encoding of a transfer and checked the signature against both: it verifies the legacy message and fails the v1 one. Multi-party flows, treasury setups and any procedure that moves an unsigned transaction between machines need every participant on the same side of the change.

Durable nonces, the usual companion of offline signing, keep working on their own. The builder inserts AdvanceNonceAccount as the first instruction and uses the nonce value as the message lifetime, and the runtime finds a durable nonce the same way for every message version: instruction zero, the System program, the advance-nonce discriminant. The problem is not the nonce. It is that the workflows nonces exist for are the ones that cross machines, and often end on a hardware wallet.

The 44× priority fee on nonce transactions

Online commands simulate first: when you pass --with-compute-unit-price, the CLI simulates the transaction and sets the limit to what it consumed, then recomputes the v1 priority fee from that. Those fees barely move. A transaction that cannot be simulated, because it uses a durable nonce, takes the default limit, and that is where the two versions part.

A legacy message with no limit instruction gets the runtime’s default, which gives each non-migrating builtin instruction 3,000 compute units. The System program and the ComputeBudget program are both builtins, so a nonce transfer with a price, three instructions, defaulted to 9,000. The v1 builder has no builtin discount: 200,000 per instruction for the two it emits.

Nonce transfer, legacy limit — 9,000 CU

Nonce transfer, v1 limit — 400,000 CU

Priority fee at 1,000,000 micro-lamports/CU — 9,000 → 400,000 lamports

Priority fee at 100,000 micro-lamports/CU — 900 → 40,000 lamports

Same flag, 44 times the fee. solana transfer does not take a compute-limit flag, so the only lever is the price: divide it by the ratio of the limits to pay what you paid before. Without a price there is no priority fee at all, but the declared limit still grows. An online transfer without a price is never simulated, so its v1 message declares the 1,400,000-unit maximum where the legacy one defaulted to 3,000. That costs nothing in fees. It does raise the cost the leader divides by when it ranks transactions.

What looks like it should break, and does not

Address lookup tables. v1 has none, but the CLI never used them for its own messages, and the address-lookup-table subcommands are ordinary instructions to the lookup-table program, so they build and send as v1 like anything else.
Program deploys get no faster. v1 allows 4,096-byte transactions, but the loader limits write instruction data to the 1,232-byte packet size for every version. v1’s larger header costs each write 13 bytes of program data, 1,012 down to 999 when one keypair pays for and owns the buffer, so an 800 KB program takes 801 writes instead of 791. With a price set, deploy writes are simulated in both versions and their fees stay close.
Memos. --memo already used the Memo v4 program before the change, and still does.
Durable nonces themselves, as section 03 shows.

One more downstream effect belongs to everyone who reads transactions rather than signing them. CLI transactions now carry their compute settings in the v1 config rather than in ComputeBudget instructions, so fee dashboards that scan for those instructions will record nothing for them. That is the general v1 reader problem, arriving through a tool many teams treat as a reference client.

What to do before it ships

No release contained the change when it merged; it is on master, on the way to the next minor line. Until Ledger ships v1 parsing, pin a 4.4 CLI on any machine that signs with a hardware wallet. Upgrade every machine in an offline-signing procedure together, never one at a time. And if you set a price on nonce or other unsimulated transactions, recompute it, because the limit it multiplies is no longer the runtime default.

What this does not show

The Ledger result comes from reading the app’s parser and walking the CLI’s bytes through it, not from signing on a device. The sizes, signature check and limits come from compiling the same messages with the solana-message 6.0.0 crate the merge commit uses; the legacy defaults come from the runtime’s builtin table. Which other CLI commands use default rather than simulated limits varies by subcommand, and only the transfer path is worked through here.

CLI Transaction V1: Questions People Actually Ask

Does the Solana CLI still create legacy transactions?

Not on Agave master after 29 October 2026. Pull request 16448 routes every CLI message through a MessageBuilder that compiles version 1 messages only. Released CLIs up to 4.4 still build legacy messages, and no release contained the change when it merged.

Can I sign v1 transactions with a Ledger?

Not with Ledger Solana app 1.16.1. Its parser reads a v1 message with the v0 layout and rejects it, so the CLI reports “Ledger received invalid Solana message”. It fails closed: the device refuses rather than displaying wrong details or offering blind signing.

Do durable nonce transactions still work in v1?

Yes. The builder puts AdvanceNonceAccount first and uses the nonce value as the message lifetime, and the runtime detects durable nonces the same way for every message version. What changes is the priority fee: nonce transactions use the default compute limit, which the v1 builder sets at 200,000 per instruction.

Why did my priority fee go up with the new CLI?

v1 carries a flat lamport priority fee, which the CLI computes as price × limit ÷ 1,000,000. Commands that do not simulate, such as transfers with a durable nonce, now declare 200,000 compute units per instruction instead of the runtime’s 3,000 for each builtin instruction, so the same --with-compute-unit-price costs 44 times more on a nonce transfer.

Can I sign offline with one CLI version and submit with another?

Not across this change. Offline signing only works if every signer and the submitter compile byte-identical messages. A signature over the legacy encoding does not verify the v1 encoding of the same instructions, so everyone in the flow has to run a CLI on the same side of the change.

The one-line version

The CLI change is a format change, and formats break at the edges: the device that parses them, the other machine that must produce the same bytes, and the fee that is now computed from a different number. Keep hardware-wallet machines on 4.4, move offline-signing setups together, and recompute prices on nonce transactions.

The v1 wire format itself is in Solana’s 4,096-byte transactions, durable nonces are in the pre-signed transaction that never expires, and what the limit does to landing is in the leader’s ranking formula.

Sources: Agave at the merge of #16448, commit a4f4c5ea9e: message_builder.rs, compute_budget.rs, wallet.rs, program.rs, remote-wallet/ledger.rs, compute_budget_instruction_details.rs and builtins-default-costs; LedgerHQ/app-solana at af6ed454f0: parser.c and handle_sign_message.c.

Agave 4.4 RPC Compatibility: What Actually Changed?

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:07 +0000

Originally published on xroot.dev.

Agave 4.4.0 shipped as the stable release on 28 October. For the weeks it takes operators to upgrade, an RPC endpoint behind a load balancer is a mix of 4.3 and 4.4 nodes, and each request can land on either. Most of what changed in 4.4 is a new parameter, and a 4.3 node does not reject a parameter it does not know. It ignores it.

The release’s CHANGELOG lists four RPC changes. Diffing the RPC crates from v4.3.2 to v4.4.0 finds six behavior changes that reach clients. One parameter and one notification fix are not in the changelog, and two other RPC fixes on the 4.4 line were backported to 4.3.x, so they are not differences at all. For each change below: what a 4.4.0 node returns, what a 4.3.2 node returns for the same request, and what to send so both give you a usable answer.

Six changes, and what a 4.3 node does with each

getTransaction · minContextSlot — 4.3 ignores it

getSignatureStatuses · commitment, minContextSlot — 4.3 rejects or ignores

accountSubscribe, programSubscribe · dataSlice — 4.3 ignores it

getLeaderSchedule · unknown identity — {} on 4.3, -32022 on 4.4

getLeaderSchedule · keyByVoteAccount (not in the changelog) — 4.3 ignores it

confirmed notifications that could be skipped (not in the changelog) — fixed in 4.4 only

The 4.3 column is not a guess. The request-config structs below are copied verbatim from rpc-client-types/src/config.rs at both tags and parsed the way a node parses parameters, with jsonrpc_core::Params::parse into the method’s argument tuple. Neither version sets deny_unknown_fields, so a field the struct does not have is dropped without an error. The 4.4 column was checked against a node running 4.4.0.

getTransaction: null used to mean two things

An indexer that learns of a transaction from one node and fetches it from another has always had a race: the second node may not have reached that slot yet, and getTransaction answers null both for “no such transaction” and for “not yet”. Since #15091, a 4.4.0 node takes minContextSlot and fails fast when it is behind:

→ ["<signature>", { "commitment": "finalized",
                    "maxSupportedTransactionVersion": 0,
                    "minContextSlot": 999999999999 }]
← { "error": { "code": -32016,
               "message": "Minimum context slot has not been reached",
               "data": { "contextSlot": <the node's finalized slot> } } }

A 4.3.2 node parses the same request, keeps encoding, commitment and maxSupportedTransactionVersion, and drops minContextSlot, because its config struct has no such field. It answers null exactly as before. A client that added minContextSlot and now treats null as “definitely not there” is wrong whenever a 4.3 node answers.

getSignatureStatuses: the config that fails on 4.3

The same pull request gave getSignatureStatuses a commitment and a minContextSlot, and made searchTransactionHistory optional. That last part is what bites. In 4.3.2 the config struct’s only field had no default, so the natural 4.4-style request is a parse error on a 4.3 node:

→ [["<signature>"], { "commitment": "finalized" }]

4.4.0 ← { "result": { "context": { "apiVersion": "4.4.0", "slot": … },
                      "value": [{ "confirmationStatus": "finalized", … }] } }
4.3.2 ← { "error": { "code": -32602,
          "message": "Invalid params: missing field `searchTransactionHistory`." } }

Add "searchTransactionHistory": false and the request parses on both, but a 4.3 node then drops commitment and minContextSlot and answers from its processed bank, which is the only bank this method used before 4.4. On 4.4 without a commitment it still defaults to processed, so leaving the parameter out gives the same answer on both versions.

Subscriptions: dataSlice now does something

accountSubscribe and programSubscribe have accepted a dataSlice for a long time, because they share the account-config type with getAccountInfo. In 4.3.2 the notifier passed no slice to the encoder, so the full account went out regardless. Since #15241 the slice is applied. Subscribing to the Clock sysvar on a 4.4.0 node:

no dataSlice — 40 bytes

{ offset: 0, length: 8 } — 8 bytes: the slot

{ offset: 16, length: 0 } — 0 bytes

A 4.3.2 node sends 40 bytes for all three. That makes this the one change that can break a client that changed nothing: a subscription config copied from a getProgramAccounts call, slice included, used to stream full accounts and now streams the slice. If you set dataSlice on a subscription, check the length of what arrives, because the answer depends on the node.

getLeaderSchedule: a new error and a new key

Filtering the schedule by an identity that has no slots this epoch used to return {}. Since #12197 it is an error with a code that did not exist before:

→ [null, { "identity": "11111111111111111111111111111112" }]
← { "error": { "code": -32022,
    "message": "Node 11111111111111111111111111111112 was not in the leader schedule for specified epoch" } }

Code that reads an empty map as “not a leader this epoch” now throws on 4.4 nodes, and code written for the error never sees it from a 4.3 node. Handle both.

The second change is missing from the changelog. #13796 added keyByVoteAccount, which keys the schedule by vote account instead of validator identity, while the identity filter keeps matching on identity. On a 4.4.0 node, a validator’s leader slots come back unchanged under its vote account, the one getVoteAccounts lists for that identity. A 4.3.2 node drops the flag and returns the identity-keyed map. Both are valid base-58 public keys, so nothing fails: the keys are simply not the ones the client asked for.

Confirmed notifications that never came

The last change is a fix, and it is also not in the changelog. When a slot’s confirmation arrived before its bank finished replaying, the node parked it until the bank froze. If the next slot’s confirmation was processed first, the node’s “last notified” mark moved past the parked slot, and the deferred notification emitted nothing. The slot was later announced rooted without ever being announced confirmed, to confirmed WebSocket subscribers and on the Geyser slot-status stream, and its prioritization-fee entry was never finalized.

The pull request reports this “several times per day per node at mainnet volume” on the 4.2 line. 4.4.0 delivers the parked notification, and a follow-up keeps it from being delivered twice. Neither was backported to 4.3. A consumer that waits for “confirmed” before it will accept “rooted” for a slot can stall on 4.3 nodes; treat rooted as implying confirmed.

Writing requests that work on both

Always send searchTransactionHistory in a getSignatureStatuses config. It costs nothing on 4.4 and is required on 4.3.
Check context.apiVersion before trusting a new parameter. Every HTTP method that returns a context reports the answering node’s version, and behind a load balancer it can change from one request to the next. An answer from a 4.3 node was given without your commitment or minContextSlot.
Keep retrying a null from getTransaction when you know the transaction exists. getTransaction returns no context, so a 4.3 answer cannot be told apart; on 4.4, retry -32016 until the node’s contextSlot catches up.
Treat {} and -32022 as the same answer, and verify vote-account keys against getVoteAccounts before relying on keyByVoteAccount.
Measure subscription payloads if you pass dataSlice, and drop it if you were relying on the full account.

For Rust clients, the 4.4 solana-rpc-client adds get_signature_statuses_with_config, and #15309 lets get_fee_for_message take a v1 message. One more 4.4 change, a bound on the root scan in getBlocks, makes the method faster without changing what it returns.

What this does not show

The 4.3 behavior is reproduced from its source, by parsing requests with the exact structs a 4.3.2 node uses, not by sending them to a 4.3.2 node. How long mainnet stays mixed, and how a given provider routes requests, are not measured here. Rejecting base58 encoding for v1 transactions and the camelCase fields of getAgGenesisCert were both backported to 4.3.x, so they are left out as changes between these two versions.

Agave 4.4 RPC: Questions People Actually Ask

Does getTransaction support minContextSlot?

From Agave 4.4.0, yes. A node whose context slot at the requested commitment is below the minimum returns error -32016 with the node’s contextSlot in the error data, instead of null. A 4.3 node accepts the parameter and ignores it, so it can still return null for a transaction it simply has not seen yet.

Why does getSignatureStatuses fail with “missing field searchTransactionHistory”?

The node is running 4.3 or earlier. Before 4.4.0 the config object’s searchTransactionHistory field had no default, so a config that only sets commitment or minContextSlot fails to parse with error -32602. Always send searchTransactionHistory explicitly and the request parses on both versions.

What is RPC error -32022?

New in Agave 4.4.0: getLeaderSchedule returns -32022 when the identity you filter by is not in the leader schedule for the epoch. Earlier versions returned an empty object for the same request.

Does accountSubscribe support dataSlice?

From Agave 4.4.0, accountSubscribe and programSubscribe apply dataSlice to binary encodings, and a zero-length slice returns empty data. Earlier versions accepted dataSlice on subscriptions and ignored it, always sending full account data.

How can a client tell which version answered?

HTTP methods that return a context object include context.apiVersion, the answering node’s version; WebSocket notifications do not. Behind a load balancer each request can reach a different node, so check it per response, not once per connection.

The one-line version

Agave 4.4 mostly adds parameters, and 4.3 nodes ignore parameters they do not know. Until the fleet behind your endpoint has upgraded, the new protections are only as good as the version that answered, so read apiVersion and write requests that are valid on both.

The full list of custom error codes, which -32022 now extends, is in Solana RPC error codes explained, and what each commitment level means is in how many confirmations a deposit needs.

Sources: the v4.4.0 release and its CHANGELOG; rpc-client-types/src/config.rs at v4.3.2 and v4.4.0; rpc/src/rpc_subscriptions.rs at v4.3.2 and v4.4.0; and pull requests #12197, #13796, #14936, #15068, #15091, #15131, #15241 and #15309 in anza-xyz/agave.

Solana P-256 Syscalls: Agave and Firedancer, Edge Case by Edge Case

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:05 +0000

Originally published on xroot.dev.

On 27 October both of Solana’s independent runtimes merged the same new feature, written separately. Agave added P-256 curve operations to its syscalls at 02:38 UTC; Firedancer added its own sixteen hours later. Different authors, different languages, different arithmetic, and consensus needs them to return the same bytes for every input a program can send, including every input the specification rejects.

SIMD-0565 extends Solana’s curve syscalls to P-256, also called secp256r1: the curve behind passkeys, WebAuthn and the secure chips in phones. We wrote our own reference implementation from the curve’s published constants, generated 626 test vectors aimed at the edges of the specification, ran them through the code Agave’s syscalls call, and checked Firedancer’s tests and source for the same cases. We found no case where the two differ. We also built a small program that verifies a P-256 signature with three of the new syscalls and no modular inverse. It costs 22,760 compute units.

What SIMD-0565 adds

No new syscall names. The proposal adds two curve ids, 7 for little-endian and 0x87 for big-endian, to the four curve syscalls programs already use for curve25519 and BLS12-381: point validation, decompression, group operations (add, subtract, multiply by a scalar) and multiscalar multiplication. Points are 64 bytes, x then y, and the point at infinity is 64 zero bytes. Compressed points are 33 bytes: a 02 or 03 parity prefix, then x. Every call has a fixed price, charged before its inputs are read, whether it succeeds or not:

Validate a point — 20 CU

Decompress — 610 CU

Add or subtract — 520 CU

Multiply by a scalar — 9,000 CU

Multiscalar, n points — 9,000 + 3,800 × (n − 1)

Most points within 1.4M CU — 367

A multiscalar call with more than 512 points fails outright, before anything is charged. The SIMD’s authors set the prices on a private ten-validator cluster with 200 ms slots, so that a block packed with any one of these operations still replays within its slot.

Two implementations of one rulebook

Agave’s version, #13918, opened in July, calls solana-secp256r1 0.1.0, a pure-Rust P-256 crate Anza published in September. Firedancer’s, #12498, opened on 22 October, is C built on AWS’s s2n-bignum routines where the build has them. What the two share is everything consensus can see: the same feature-gate key, the same seven compute prices, and five test vectors. Firedancer’s syscall tests reuse the expected outputs from Agave’s, in both byte orders.

Agreement matters more than either implementation being right by its own tests. If one client returns 0 where the other returns 1, a program that branches on the result writes different account data on each, the two compute different bank hashes for the same block, and the network splits along client lines. The dangerous inputs are the ones nobody thought to try.

The edge cases, and what both clients do

These are the inputs where a reasonable implementation could choose differently. In every row the two give the same answer: Agave on our vectors through the crate its syscalls call, Firedancer in its own tests or, where its tests don’t reach, in its source.

64 zero bytes — identity, valid

x = 0, y = √b, a real point — valid

(0, 1) — rejected

x or y written as value + p — rejected

Prefix other than 02 or 03 — rejected

33 zero bytes, SEC1’s identity — rejected

P + P, or P − (−P) — 2P

P − P, or k·P + (n − k)·P — identity

0·P, or k times the identity — identity

Scalar n, n + 1 or 2²⁵⁶ − 1 — rejected

Multiscalar, 0 points — identity

Multiscalar, bad last scalar or point — rejected

Multiscalar, over 512 points — InvalidLength

Any P-256 call before activation — InvalidAttribute

“Rejected” means the call returns 1 and writes nothing; the last two rows are errors that abort the transaction. Firedancer’s tests cover the identity, off-curve and out-of-range points, the 04 prefix, both byte orders, P + P, P − P, P + (−P), adding and subtracting the identity, 0·P, k times the identity, n·P, multiscalar calls of 0, 1, 2 and 70 points including a bad scalar or point, running out of compute and the gate being off. The x = 0 point, the value-plus-p encodings, the other prefixes, n + 1, doubling through subtraction and cancellation inside a multiscalar call we confirmed in its source.

626 vectors, and three things to know before you call them

Our reference is about 160 lines of Python written from the curve constants in NIST SP 800-186 and the SIMD text, without reading either client’s arithmetic. It reproduces all five shared vectors. From it we generated 313 vectors per byte order: 73 hand-picked cases and 240 random operations. The hand-picked ones include everything in the table above, 64-point multiscalar calls whose two 32-point halves are equal or cancel (Firedancer works in batches of 32 points, so these land on its batch boundary), and calls of 367 and 512 points. Run through solana-secp256r1 0.1.0, called exactly as Agave’s syscalls call it at the merge commit, all 626 match, including all 127 rejections.

x = 0 is on the curve. The identity’s encoding has x = 0, and so does a real point, (0, √b). Both clients treat only the exact all-zero encoding as the identity, so (0, √b) is an ordinary point, decompression of x = 0 succeeds, and (0, 1) is rejected.
Scalars are never reduced. A scalar of n, n + 1 or 2²⁵⁶ − 1 makes the call return 1, even when the point is the identity. A SHA-256 hash is a valid scalar only if it is below n, so reduce it first: any 256-bit value is below 2n, so one comparison and one subtraction are enough.
Little-endian is per coordinate. With curve id 7, x and y are each byte-reversed in place, and a compressed point keeps its prefix byte first with only x reversed, which is not SEC1. The generator written in the other byte order fails validation.

The one place the code differs

Read side by side, the clients take different paths in one place: an unknown curve id or group operation in validation, group operations or multiscalar multiplication. Firedancer’s syscalls always abort with InvalidAttribute. Agave aborts only when the feature from SIMD-0137 is active, and otherwise returns 1. That feature has been active on mainnet since slot 311,904,000, the first slot of epoch 722, so the result is the same there. Nothing on the P-256 path itself branches this way.

A signature check from three syscalls

The obvious use is checking passkey signatures inside a program, which today goes through the secp256r1 precompile. ECDSA verification normally needs s⁻¹ mod n, and no syscall computes it. It can be avoided. The signature is valid when s·R equals z·G + r·Q up to sign, where R is the point whose x-coordinate is r, z the message hash and Q the public key. Decompression gives R, one multiplication gives s·R, one two-point multiscalar call gives z·G + r·Q, and comparing x-coordinates ignores the sign:

use solana_define_syscall::{
    curve_constants::{GROUP_OP_MUL, SECP256R1_BE},
    definitions::{sol_curve_decompress, sol_curve_group_op, sol_curve_multiscalar_mul},
};

/// ECDSA check: s·R == ±(z·G + r·Q), where R is the point with x = r.
/// Same answer as the textbook check except for x(R) = r + n, which has
/// probability about 2^-128 and is not tried here.
pub fn verify_p256(q: &[u8; 64], z: &[u8; 32], r: &[u8; 32], s: &[u8; 32]) -> bool {
    if is_zero(r) || is_zero(s) || *r >= N || *s >= N {
        return false;
    }
    // The syscalls reject scalars >= n instead of reducing them.
    let z = if *z >= N { sub(z, &N) } else { *z };

    let mut c = [0u8; 33];
    c[0] = 0x02; // either parity: s·(−R) = −(s·R) has the same x
    c[1..].copy_from_slice(r);
    let (mut rp, mut u, mut t) = ([0u8; 64], [0u8; 64], [0u8; 64]);
    let scalars = [z, *r];
    let points = [G, *q];
    unsafe {
        // R: 610 CU
        if sol_curve_decompress(SECP256R1_BE, c.as_ptr(), rp.as_mut_ptr()) != 0 {
            return false;
        }
        // U = s·R: 9,000 CU
        if sol_curve_group_op(SECP256R1_BE, GROUP_OP_MUL, s.as_ptr(), rp.as_ptr(), u.as_mut_ptr()) != 0 {
            return false;
        }
        // T = z·G + r·Q: 9,000 + 3,800 CU; returns 1 if Q is not a valid point
        if sol_curve_multiscalar_mul(
            SECP256R1_BE,
            scalars.as_ptr() as *const u8,
            points.as_ptr() as *const u8,
            2,
            t.as_mut_ptr(),
        ) != 0
        {
            return false;
        }
    }
    t != [0u8; 64] && u[..32] == t[..32]
}
// N and G are the group order and generator, big-endian; is_zero and sub are byte helpers.

We built it with platform-tools v1.57 and ran it in solana-sbpf 0.26.0, the VM version Agave pinned at the merge, set up as in our CPI measurement, with the three curve syscalls implemented the way Agave implements them on top of the same crate. OpenSSL signed 20 messages, and the program got each signature, the same signature with the other half of S, a hash with one bit flipped, and a different public key. All 80 verdicts match textbook ECDSA:

Curve syscalls: 610 + 9,000 + 12,800 — 22,410 CU

Memory syscalls — 30 CU

Program instructions — 320 CU

One signature check — 22,760 CU

Precompile, cost-model charge — 4,800 CU

Two differences from the precompile. Cost: a check through the syscalls takes about 4.7 times the 4,800 compute units the cost model charges per precompile signature, before the message is hashed. Policy: this check accepts both halves of S, where the precompile rejects the high one, the reason half of raw WebAuthn signatures fail it. A program that wants the precompile’s rule adds s ≤ n/2; one that doesn’t can skip normalising S altogether. The SIMD gives that freedom as the reason for curve operations instead of a single verify syscall, which would have had to fix one malleability rule for everyone.

Where it stands

Both pull requests introduce the gate secp256r1_syscall_enabled, key SeRjtX7Abiq5hQYbzdCny266oveDseHZh9tnrs2cdVC, so the syscalls were off on every cluster when they merged, and a program calling them gets InvalidAttribute until the feature is activated. The SIMD itself was still marked Draft, with its compute prices added a week earlier. The program side is ready: solana-define-syscall 5.2.0, published in July, already declares the curve ids and all four syscalls, and our program imports them from there.

What this does not show

We did not build or run Firedancer. Its side rests on reading its source and on its own CI run, which passed test_secp256r1 and test_vm_syscall_curve on the pull request’s final commit, whose P-256 files are identical to the merged ones. On Agave’s side we ran the crate its syscalls call, not the syscalls: memory translation, compute charging and the gate we read rather than executed. Vectors find disagreements; they cannot prove there are none. The compute prices are the SIMD’s calibration, not our measurement, and 22,760 is one program built with one toolchain.

P-256 Syscalls: Questions People Actually Ask

What does SIMD-0565 add to Solana?

It extends the four existing curve syscalls (point validation, decompression, group operations and multiscalar multiplication) to P-256, also called secp256r1, with curve id 7 for little-endian and 0x87 for big-endian encoding. Points are 64 bytes, x then y, with 64 zero bytes for the point at infinity. Agave and Firedancer both merged an implementation on 27 October 2026, behind a new feature gate.

How much does it cost to verify a P-256 signature with the new syscalls?

Our test program verified an ECDSA P-256 signature for 22,760 compute units: 22,410 for one decompression, one scalar multiplication and one two-point multiscalar multiplication, 30 for memory syscalls and about 320 program instructions. Hashing the message is extra. The secp256r1 precompile is charged 4,800 compute units per signature in the cost model.

Do the secp256r1 syscalls reduce scalars modulo the group order?

No. A scalar of n or more makes the call return 1 in both Agave and Firedancer, including n + 1 and 2^256 − 1. A program that uses a 256-bit hash as a scalar must reduce it first; since any 256-bit value is below 2n, one comparison and one subtraction are enough.

How is the point at infinity encoded for Solana’s P-256 syscalls?

As 64 zero bytes. Only that exact encoding is the identity: (0, √b), which also has x = 0, is an ordinary point on the curve, and (0, 1) is rejected. Decompression cannot produce the identity, and 33 zero bytes are rejected.

Are the P-256 syscalls active on mainnet?

Not when they were merged. Both pull requests introduced the feature gate secp256r1_syscall_enabled, so it was inactive on every cluster, and every P-256 call fails with InvalidAttribute until it is activated.

The one-line version

Agave and Firedancer implemented SIMD-0565’s P-256 syscalls independently and agree on every edge case we could find, from the x = 0 point to unreduced scalars; with them, a program verifies a P-256 signature for 22,760 compute units and sets its own rule for S.

Sources: SIMD-0565 at commit f13f5d65; Agave #13918, merged as cf58f070; Firedancer #12498, merged as 8e7388db; solana-secp256r1 0.1.0, solana-define-syscall 5.2.0 and solana-sbpf 0.26.0. The reference, vectors, harnesses and test program are our own.

Solana Geo Leader Schedule: Location Pays, Splitting Doesn’t

Suliman Mokhtar — Fri, 06 Nov 2026 04:24:03 +0000

Originally published on xroot.dev.

Under Alpenglow’s fast leader handover, the gap between two leaders is mostly the time a block takes to cross from one to the next. Today’s schedule picks leaders at random, so that crossing is often an ocean. SIMD-0675 proposes to reorder the schedule so that leaders near each other go one after another.

In review, Dean Little raised the obvious worry: that the reordering “appears to incentivize sybils”, letting validators use geography, “or even just a self-attestation of geography”, to line up their leader rotations “with better-than-random odds”. Two days later, the author of the proposal’s parameter analysis answered that splitting stake barely moves the odds, 7.146% to 7.147% in one example, because “the majority of the ‘upside’ for extractors (compared to random) is already given by the schedule design.”

We rebuilt the reordering in Rust from the specification to check both statements. The reviewer is right about splitting: it changes nothing, not even one window. But the second half of the sentence is the finding. The upside the schedule hands out depends on where an operator’s stake sits, and an honest operator in the right region gets back-to-back windows five to seven times as often as today, without splitting or lying about anything.

Bins, radii and runs

The base schedule is computed exactly as today, one stake-weighted random leader per four-slot window. SIMD-0675 then walks it in order and drops each leader into a bin:

Radius. Every validator has a radius, the smallest distance around it that holds STAKE_FLOOR (10%) of all stake. Dense places get small radii, isolated ones large radii. Locations are self-reported, through SIMD-0674.
Bins. A leader joins a random open bin whose anchor is within the larger of the two radii, or opens a new bin if none is.
Runs. When a bin holds RUN_LENGTH leaders, it is shuffled and written out as a block of consecutive windows. The proposal says 3; reviewers have argued for 7.

Every validator keeps exactly the windows it would have had. Only their order changes. With 200 ms slots, a run of three windows is 2.4 seconds of block production from one area of the map.

for &l in base {
    let near: Vec<usize> = (0..bins.len())
        .filter(|&i| {
            let a = bins[i].anchor;
            dist2(&vs[l], &vs[a]) <= r[a].max(r[l])
        })
        .collect();
    let bi = if near.is_empty() {
        bins.push(Bin { anchor: l, members: vec![l] });
        bins.len() - 1
    } else {
        let i = near[rng.roll(near.len())]; // one roll per join
        bins[i].members.push(l);
        i
    };
    if bins[bi].members.len() == run_length {
        let mut b = bins.remove(bi);
        rng.shuffle(&mut b.members); // Fisher-Yates
        out.extend(b.members);
    }
}
// end of epoch: shuffle the open bins, shuffle each one, append

The model, and a check against the proposal

Our implementation follows the specification’s pseudocode line for line: the radius, the nearness test, one random draw per join, Fisher-Yates within a run and a shuffled flush at the end of the epoch. Two simplifications are deliberate. The random generator is SplitMix64 rather than the specified ChaCha20, which changes which schedule comes out but not its statistics. And the network is stylized: about 800 validators with lognormal stake across 19 metros. Asia holds 10.4% of stake, the figure in the parameter analysis published on solana.com; the European and North American split and the metro mix are our assumptions. Latency between leaders uses the analysis’ estimate, 1.5 times the great-circle distance at 200 km per millisecond. Each scenario is 108,000 windows, an epoch, averaged over five seeds.

Mean handover, random schedule (SIMD’s figure) — 37.3 ms (36.2)

RUN_LENGTH 3 — 18.2 ms (17.0)

RUN_LENGTH 7 — 11.6 ms (10.8)

The proposal’s simulation, on the real stake distribution of epoch 1038 and measured round-trip times, is in brackets. Our stylized network lands within about a millisecond at every run length, which is close enough to trust it for the question it was built for: who gets consecutive windows.

Splitting stake changes nothing

We gave one operator 3% of stake as one validator in Frankfurt, then as six validators of 0.5% each in the same place. The two schedules were identical, window for window, at every run length.

That is not a statistical tie, it is structural. The base schedule gives the six the same windows the one would have had. The radius of a location is computed from all the stake there, so it is the same. And a bin only ever asks about locations and radii, never identities. Sybils at one address are invisible to the reorder, which is the reviewer’s 7.146% to 7.147% taken to its limit.

Splitting across regions is worse than useless for an extractor. The same 3% spread over Frankfurt, Ashburn and Singapore led two windows in a row 4.2% of the time at RUN_LENGTH 3, against 7.6% for the operator that stayed in one place.

Location changes a lot

Consecutive windows under one operator are the precondition for multi-block MEV: two windows are eight slots in which one party orders every transaction. We measured how often an operator’s window is followed by another of its own, under today’s random schedule and under the reorder. Columns are random, then RUN_LENGTH 3, then 7.

1% operator, Frankfurt — 1.06% → 2.56% → 3.31%

1% operator, Tokyo — 1.06% → 5.31% → 7.66%

3% operator, Frankfurt — 3.15% → 7.56% → 9.22%

3% operator, Tokyo — 3.15% → 15.10% → 19.10%

3% split over three regions — 3.15% → 4.18% → 4.90%

Under random, the chance is the operator’s stake share, wherever it sits. Under the reorder, a run is filled from nearby stake, so the chance tracks the operator’s share of its region instead. Three percent of all stake is a modest slice of Europe and a large slice of Asia, the smallest region that still forms bins of its own at a 10% floor. The same operator in Tokyo gets back-to-back windows 4.8 times as often as today at RUN_LENGTH 3, and 6.1 times at 7, twice what it would get in Frankfurt.

Nobody lied and nobody split stake. This is the schedule working as designed, and it is the reviewer’s point stated with a location attached: the upside comes from the design, and the design pays most to the largest operator in the smallest self-contained region. The solana.com analysis already notes that Asia sits just above the floor, at 10.4%, “with very little margin”. Our numbers say the margin is also where consecutive control is cheapest.

And lying about it

The attack the proposal’s authors model is a validator that declares an isolated location, so that no one else joins its bins. The solana.com analysis uses the most isolated point it could find, in the South Pacific, and reports that at RUN_LENGTH 7 lying is worth 0.28 extra consecutive windows to a validator with 4.07% of stake, the largest today, and 1.69 to one with 10%.

4.07% operator, back-to-back, truthful in Frankfurt — 4.23% → 10.13% → 12.15%

4.07% operator, back-to-back, declares South Pacific — 4.23% → 32.34% → 41.59%

10% operator, back-to-back, truthful in Frankfurt — 10.05% → 21.72% → 25.98%

10% operator, back-to-back, declares South Pacific — 10.05% → 65.11% → 83.19%

Measured the analysis’ way, as the expected run remaining from one of the liar’s windows, our model puts the gain from lying, against the same operator in Frankfurt, at 0.58 windows for the 4.07% validator and 2.43 for the 10% one, both at RUN_LENGTH 7. That is higher than the analysis’ figures, which come from the real map, where a few validators in Argentina and Australia can still reach the isolated point. The direction is the same: lying pays a little below the floor and a lot at it, which is why STAKE_FLOOR is pinned at 10%.

The proposal’s own location-fibbing table shows lying rarely improves a validator’s latency. It was never meant to. The reason to lie is the run, not the handover.

What it means for the parameters

RUN_LENGTH moves every number above. Going from 3 to 7 buys 6.6 milliseconds of mean handover in our model and raises back-to-back control for every operator we measured. The proposal’s authors prefer 3 for exactly this reason; the analysis finds a knee at 7 and calls 3 “the conservative choice”. Reviewers suggested handling Sybils outside the protocol, by raising the validator admission ticket or by detecting misreported locations, and the authors agreed that detection is probably possible.

Neither remedy touches the effect in section 04. A ticket prices the number of validators, and the location-driven gain needs only one. Detection catches false locations, and the Tokyo operator’s location is true. If the concern is consecutive control by honest operators, the levers are the run length and the floor, and the floor is already pressed against Asia’s share.

What this does not show

The network is stylized, so the exact percentages belong to it; the mechanism, that consecutive control tracks local rather than global share, does not depend on the split we chose. Back-to-back windows are a precondition for multi-block MEV, not a measure of its value, which the analysis also stresses. The random generator differs from the specified one. And SIMD-0675 and SIMD-0674 are open proposals, last amended on 22 October, so the constants may still change.

Geo-Aware Leader Schedule: Questions People Actually Ask

What is Solana’s geo-aware leader schedule?

SIMD-0675, an open proposal, keeps today’s stake-weighted random leader schedule and then reorders it: leaders that are geographically close are grouped into runs of RUN_LENGTH consecutive leader windows, so the handover between them is short. Every validator keeps exactly as many windows as before.

Does splitting stake into several validators help under SIMD-0675?

Not at one location. The reorder sees a validator’s location and stake, not its identity, so six validators in one city with a combined stake behave exactly like one. In our model they produced identical schedules, window for window.

Where does the geo-aware schedule give an operator more consecutive windows?

Where its share of the local stake is large. A run is filled from nearby stake, so an operator’s chance of leading two windows in a row tracks its share of its region. In our model a 3% operator in Tokyo got back-to-back windows 15% of the time at RUN_LENGTH 3, against 3% under today’s random schedule and 7.6% in Frankfurt.

Can a validator lie about its location to get consecutive leader slots?

Yes, and the proposal’s parameter analysis measures it: a validator that declares an isolated location ends up alone in its bins. The analysis puts the gain at 0.28 extra consecutive windows for a 4.07% validator at RUN_LENGTH 7, rising sharply once the liar holds STAKE_FLOOR, 10% of stake, which is why STAKE_FLOOR sits at 10%.

Is SIMD-0675 live on mainnet?

No. As of 26 October 2026 it is an open proposal, as is SIMD-0674, the location registration it depends on. Its parameters, especially RUN_LENGTH, are still being debated between 3 and 7.

The one-line version

SIMD-0675 halves handover latency and does not reward Sybils, but it turns local stake share into consecutive leader windows, and the smallest region that forms its own bins is where a large operator gains the most.

The consensus this schedule feeds is in Alpenglow finality in numbers, the admission ticket reviewers proposed raising is in the 2,000 validator seats, and the stake-weighted QoS that follows the leader is in stake-weighted QoS, with the formula.

Sources: SIMD-0675 and SIMD-0674 as amended on 22 October 2026, with their review threads to 26 October; the parameter analysis on solana.com, by Umberto Natale, 14 October 2026. Results are from our Rust model of the reorder, described in section 02.