The browser doesn't trust the server: a Solana frontend that checks its own backend
My server can tell the web page that a borrower got credit tier A. The page doesn't show it until Solana agrees.
That sounds like paranoia about my own code, so here's the context. I'm building TEE Income Oracle. A borrower's bank statement is scored inside a secure enclave, the enclave signs a credit tier, and the tier is written to Solana, where a lending pool reads it before it lends. Between the browser and all of that sits a server I wrote, the gateway. It talks to the enclave, streams progress to the page, and pays transaction fees so a demo wallet needs no SOL.
The whole product claims that a lender doesn't have to trust me. If the page repeats whatever my gateway says, that claim stops at the page. So the page treats the gateway as a messenger: it can carry bytes, but it never becomes the source of anything the page calls verified.
This post is for frontend developers building on Solana. You know transactions, signatures and RPC calls; you don't need to know anything about enclaves. It walks through five places the page checks its own backend, each as the shortcut, what can go wrong with it, and what the page does instead. The page still trusts two things, the RPC node it reads from and the code I serve it, and I'll come back to both at the end. Every link points to release v0.5.5.
1. Sign your own copy
Before scoring starts, the borrower signs a short text that ties the session to their wallet. It's a plain message signature, the kind a wallet's signMessage produces, not a transaction:
tee-income-oracle: bind session
session: <session id>
wallet: <borrower's address>
policy: <policy hash>
expires: <unix seconds>
The policy hash identifies the scoring rules the enclave will apply; each pool says which policy it accepts.
The shortcut: the gateway sends this text, the page passes it to the wallet, and the wallet signs it.
What can go wrong: the gateway now holds the pen. Whatever it puts in that text gets signed: a different wallet, an expiry next year, a policy no pool lends under. In the demo the wallet lives in the browser tab and signs without a prompt, so nobody reads the text first.
What the page does: it writes the text itself and signs its own copy, and only if the gateway's copy is identical. The wallet line comes from the page alone. The other values come from the gateway, so the page can only hold them to rules: the session id must match the session the page will submit under, the policy must be one a listed pool lends under, and the expiry must fall within the next ten minutes (plus a minute for clock skew). A gateway can still choose the session and the policy within those rules. It can't get a signature for anything else. (intent.ts)
This isn't a quirk of my setup. Kit's documentation for signing off-chain messages makes the same argument from the other side: a valid signature from a wallet proves little until you've also confirmed it covers the message you meant to have signed.
2. Check that the signature you got back is yours
To borrow, the page builds a transaction and the borrower signs it. The gateway's relayer pays the fee, so it signs too, sends the transaction, and returns its signature. The page polls that signature until it's confirmed.
The shortcut: take the returned signature, wait for "confirmed", show "borrowed".
What can go wrong: every confirmed transaction has a signature. A buggy or hostile relayer could hand back one from an earlier borrow, or from someone else's, and the page would celebrate a loan that never happened. Reading the loan account afterwards helps, but on public RPC that read can come from a node that's behind.
What the page does: on Solana, a transaction's id is its first signature, and the first signature belongs to the fee payer, signed over the transaction's message bytes. The fee payer here is the relayer. So the page checks that the returned id is a valid relayer signature over the exact bytes it built. With @solana/kit (the library formerly released as web3.js 2.0), that's a decode and a verify:
const { messageBytes } = getTransactionDecoder().decode(wire);
const signature = getBase58Encoder().encode(returnedId);
if (!isSignatureBytes(signature)) return false;
return verifySignature(relayerKey, signature, messageBytes);
Solana's guide to partial signing gives a similar rule to whoever assembles a transaction from several signers: before you submit, make sure each signature you collected is over the message you froze. The page applies it from the other end, after submission, to the one id that comes back. A signature over any other message fails, so the id is tied to these exact message bytes. (The excerpt is condensed from isOurTransaction in use-loan.ts.)
That still isn't complete replay protection. Ed25519 signatures are deterministic: the same key signing the same bytes always gives the same signature. So two identical borrows built on the same blockhash have the same id, and asking for the latest blockhash each time doesn't guarantee a different one. The chain is safe either way: validators drop a transaction they've already processed, so nothing executes twice. The risk is to what the page believes. Before relaying, the page reads the loan account and refuses to borrow while a loan is open, so a replay needs a repay in between: borrow, repay, then an identical borrow while the blockhash is still valid, about a minute. A relayer could answer that last borrow with the first one's signature, which did confirm. The page reads the loan account again after confirmation, but that read has no lower bound on freshness, so a node still showing the first loan would let it through.
3. Show what the chain says, not what the server says
When scoring finishes, the gateway streams the result: the tier, and the payload it says the oracle wrote to Solana. The payload is the signed part of the on-chain record, including the tier, the policy, the statement dates and the enclave build that scored it.
The shortcut: show the tier straight away, and read the chain for extra details. My first version did this. A reviewer described it as the gateway's word with a seal on it.
What can go wrong: the page looks verified while showing an unverified value. My first fix had a subtler hole. It matched the chain record to the gateway's report by timestamp, then kept displaying the gateway's tier. A gateway could relay a real tier C record and report tier A with the same timestamp. The timestamps match, and the page says A.
What the page does: it shows "reading your tier back from Solana…" until the payload on chain matches the reported payload, field by field. It then displays that payload and the record's expiry, both as read from Solana. If a payload at least as new as the report differs in any field, the page shows an error. That doesn't prove the gateway lied, because the oracle lets a newer record replace an older one, but the chain no longer confirms the report, so the page fails closed. (borrow-view.ts)
The same mistake hid in a smaller place. A "registered on Solana" chip was fed by a gateway endpoint. Now only a read of the on-chain registry can say "registered". The gateway still moves the page from one step to the next, and it supplies the link to its transaction. It never supplies a value the page shows as fact.
4. A "valid" badge is a promise about the program
The loan page shows a badge for the borrower's tier against a pool: valid, stale, expired, policy mismatch and so on.
The shortcut: check the rules that seem important. My first version did that, and review found four of the pool's checks missing. The badge could say "valid" about a credential the program would reject.
What the page does: it runs every credential check the pool program runs, in the program's order:
1. the record was written by the oracle,
2. it hasn't expired,
3. the pool lends to this tier at all,
4. it was scored under the pool's policy,
5. it's fresh enough (how old the record is, how old the bank statement is, and how many days it covers),
6. the enclave build that scored it is approved by the pool and not revoked.
The order matters because the badge names the first check that fails, and that should match what the program would say about the same credential. (credential.ts, borrow.rs)
Even then, "valid" makes a narrow promise: the credential passes this pool's checks at the state and time the page read. A borrow can still fail for reasons outside the credential: the amount is over the tier's limit, there's already a loan in this pool, the vault is short, a token account is frozen, or the state changes before the transaction runs. The funders' loan book runs the same function for every borrower, so "fresh" there makes the same narrow promise.
Choosing which checks to run is a product decision too. Repay first sat behind the same "is your tier valid?" gate as Borrow, which locked a borrower with a stale tier out of repaying, and repaying needs no tier at all. Repay now has no tier check in front of it.
5. The RPC node is a server too
Reading "from the chain" really means reading from an RPC node, which is someone else's server. Two things went wrong there.
A node one step behind. Public devnet RPC is load-balanced, so the read right after a confirmation can land on a node that hasn't caught up. The tests didn't catch this; a manual run on the live site did. After a repay, the page read the pool and saw the loan was gone. Then the data layer fetched again, hit a lagging node, and the closed loan came back on screen.
The fix has two parts. The read-back retries a few times, and it reads the pool, its vault and the loan in one call, so all three come from the same node. Then the read that proved the change goes straight into the cache of TanStack Query, the page's data layer, and any fetch already in flight is cancelled, so it can't overwrite it:
await queryClient.cancelQueries({ queryKey: poolKey });
queryClient.setQueryData(poolKey, provingRead);
That fixes the race I saw, and no more. A later refetch, say when the tab regains focus, can still hit a lagging node. Solana's RPC has a parameter for the general case, minContextSlot. Account reads such as getMultipleAccounts return the slot they were evaluated at in context.slot. Keep the highest slot you've accepted, pass it as minContextSlot on later reads with the same commitment level, and a node that hasn't reached that slot returns an error (code -32016, "Minimum context slot has not been reached") instead of older data. The page doesn't do this yet.
A reply that's one short. The funders' loan book asks for up to 100 accounts per call and matches each reply to its request by position. Nothing checked the reply's length. The RPC spec says a node returns one entry per address, with null for an account that doesn't exist, but the page took that on trust. A node, or a proxy in front of one, that returned 99 accounts for 100 addresses would shift every row after the gap, and show one borrower with the next borrower's "fresh" badge. Now a reply of the wrong length is an error (rpc.ts). So is a duplicated loan row, which would inflate every total, and so is a record that doesn't name the borrower it was fetched for. One bad row fails the whole book (use-book.ts), because a partial book presented as the book is worse than an error.
Where the trust actually stops
None of this makes the page trustless:
- It reads one RPC node. It checks what's cheap to check: reply lengths, account sizes and types, which wallet a record belongs to, and signatures over bytes it built. A node that invented consistent data could still fool it.
- "Confirmed" also comes from that node. The signature check proves the id belongs to the bytes the page built; the node still reports whether they landed.
- The gateway names the relayer. The relayer's key comes from the gateway's own info endpoint. The signature check ties the returned id to the bytes the page built; it doesn't prove who paid the fee.
- I serve the page. A different build could skip every check. That's why the source is public at release tags, and why the receipt checks also run from a command line.
What the checks do buy: my gateway is no longer the only authority for a tier, a loan or a registration. The page checks each of those claims against what an RPC node returns, and most gateway bugs now show up as an error on screen instead of a wrong number. The limits above still apply: a stale read, or a reused identical transaction, can get past these checks.
A checklist for your own frontend
- Rebuild anything the user signs from data you already hold, and sign your copy.
- Treat a signature from an API as a claim. If you built the transaction, verify the signature over its bytes. It ties the id to those bytes; it doesn't stop an identical transaction being reused.
- Show values from a chain read, not from the API that triggered the write. Compare every field of the reported payload, display the chain's values, and fail closed when the payloads differ. Read anything outside the payload, such as expiry, straight from the chain.
- Make a status badge mirror the program's checks, in the program's order, and say what it doesn't cover.
- After a write, keep the read that proved it. For later reads, carry the highest slot you've accepted forward as minContextSlot.
- Check reply lengths whenever you match results to requests by position.
To try this on your own app, pick one value your UI shows as confirmed, and trace where it comes from. If the answer is "the API told us", that's the first check to add.
---
Originally published on prashantchaudhari.dev.
Agave 4.4: What Changes for Solana Developers
On 28 October 2026, Anza announced Agave v4.4.0 as stable, recommended for 20% of mainnet stake and for testnet and devnet. Now, mainnet uses 4.3.2, so this is what validators will move to over the next few weeks. It adds three new gates, alongside the SIMD-0290 gate that was already in 4.3 and waits to be activated, along with a brief list of RPC and operator changes. None of the gates are active, but two change the content of blocks and program accounts, so check before they flip.
Key Takeaways
- SIMD-0290 lets blocks have transactions whose fee payer can't pay. Transactions like that show up as failed, with a zero fee and no logs.
- SIMD-0433 makes program upgrades resize the program data account to the new binary, refunding surplus rent.
- SIMD-0317 requires 32:32 FEC sets, and SIMD-0599 removes inactive stake from reward calculations.
- Rent is already down to 5,080 lamports per byte on mainnet; the next cut to 2,575 awaits testnet.
- getTransaction and getSignatureStatuses support minContextSlot, and account subscriptions obey dataSlice.
This guide is for developers deploying indexers, bots, and programs on Solana, as well as for everybody who works with raw blocks.
Where things stand
We read the gate accounts on mainnet and testnet directly on 29 October 2026 (mainnet epoch 1071).
!Feature gate status on 29 October
The timing is important to remember. Epochs are still 432,000 slots long, and on our Amsterdam node it took about 25.5 hours each to process epochs 1069 and 1070, with an average slot duration of 213 milliseconds once skipped slots are counted. Gates activate at epoch boundaries, so a scheduled activation becomes live about a day later.
SIMD-0290: blocks can carry transactions that cannot pay
Today, the presence of just one transaction whose fee payer can't pay enough to cover the fee makes the whole block invalid. With SIMD-0290, this requirement is relaxed for recent-blockhash transactions (and durable nonce transactions are waiting for SIMD-0297 activation). Such a transaction stays in the block but doesn't execute anything. It is a step towards asynchronous execution.
We reviewed the 4.4.0 codebase to learn how such transactions are recorded in the block:
- The status of a transaction is an error, the same error that used to make the whole block invalid, for instance InsufficientFundsForFee or AccountNotFound.
- The fee is zero. Nothing transfers and account states don't change.
- There are no log messages, inner instructions, or return data.
- Such a transaction contributes to block limits according to its full requested compute unit limit, rather than actual usage. This makes it impossible for a leader to stuff too many free transactions into a block.
Calculations that sum meta.fee over failed transactions will give incorrect results here, and algorithms that expect every failed transaction to have logs or a paid fee payer need to be checked. Consider a transaction failure with zero fee and no logs as "included, not executed".
SIMD-0433: program upgrades resize the account
Loader v3 allows increasing the size of a program data account using ExtendProgram, but never reducing it, meaning that when a program is rewritten to a smaller binary (like in the case of Pinocchio), it keeps paying rent for the original size. Once SIMD-0433 activates, the Upgrade operation resizes the account to fit the new ELF plus metadata header. The surplus rent is refunded to the spill account, and a larger binary grows the account without a separate ExtendProgram call.
Before the next deployment after the activation, make sure that:
- The spill account exists. It is where the refunds will go, so make sure that it is your account.
- The lamports for growth. The extra rent should be in the program data account or in its buffer prior to Upgrade, otherwise it fails with InsufficientFunds.
- The rent you overpaid earlier. Upgrading resets the account balance to the minimum required rent and sends the rest to the spill account, even without SIMD-0433. Programs deployed before the two rent cuts receive some of the deposit back on the next upgrade.
- Upgrades via CPI. Multisig and governance programs that upgrade a program via CPI still have the 10 KiB per-instruction growth limit. Perform the ExtendProgram operation in several iterations first to increase the size, or upgrade on the top level.
SIMD-0317: fixed 32:32 FEC sets
Blocks transit through Turbine as shreds, grouped into forward error correction (FEC) sets. Every client already sends 32 data shreds and 32 coding shreds per set, but receivers still accept all kinds of combinations. SIMD-0317 mandates 32:32 sets, and any other set will be dropped on ingest. The gate checks the size of the Merkle proof generated from a 64-shred set in the codebase.
It also fixes the size: 995 bytes of payload in each data shred and 31,840 bytes per set. Receivers can validate shred indices without waiting for coding shreds, and two valid shreds from one set with distinct Merkle roots prove equivocation. There is no practical difference for teams decoding shreds themselves, including ShredStream consumers, as the senders use the same format anyway.
SIMD-0599: inactive stake leaves the rewards path
Partitioned epoch rewards currently traverse every stake account regardless of whether it has effective or activating stake in it. They earn nothing, but they still affect the number of partitions and the lattice hash. SIMD-0599, jointly developed by Anza and Firedancer engineers, removes stake that didn't have any effective or activating stake in the whole rewarded epoch from this calculation.
Stakes that deactivate at the boundary still receive rewards for their last epoch, and the users see no difference. The optimization is significant though. Scanning the mainnet stake accounts on our Amsterdam node we found that out of 1,364,680 delegated stake accounts 232,962 (17.1%) were completely inactive, storing about 3.28 million SOL. All of these accounts, every client processes at every epoch boundary now.
Rent: two steps live, step three gated
SIMD-0437 reduces the lamports_per_byte parameter from 6,960 to 696 in five steps, each separately gated. The first and the second step are live on mainnet. The third one, down to 2,575, is already in 4.3.0-rc.1 and is pending activation on testnet. The fourth and fifth steps (to 1,322 and 696) are not on the activation schedule yet.
This is how the rent for a standard 165-byte token account (rent is calculated on the size of the data + 128-byte overhead) looks now:
!Rent for a 165-byte token account
Any hardcoded 2039280 in the code is already incorrect on mainnet. Always calculate the minimum rent from getMinimumBalanceForRentExemption or the Rent sysvar, because this value changes three more times.
RPC and operator changes in 4.4
These updates come with the binary and don't wait for a gate:
- getTransaction supports minContextSlot.
- getSignatureStatuses supports commitment and minContextSlot, and still defaults to processed. If the node is behind, it returns error -32016, allowing load-balanced clients to retry on a different node and not get stale data.
- accountSubscribe and programSubscribe respect dataSlice. A zero-length slice returns empty data, which is useful for watching lamport or owner changes without paying for the account data.
- getLeaderSchedule returns the new error -32022 if the requested identity is not present in the schedule.
- Validators running an external scheduler need version 5 of the bindings. The --experimental-retransmit-xdp-* command line flags are gone in favor of --xdp-interface, --xdp-cpu-cores and --xdp-zero-copy.
What this means on OrbitFlare
Our devnet already runs 4.4, and you can start experimenting with minContextSlot and dataSlice subscriptions right now. Our mainnet regions will follow Anza's adoption guidance without any changes in URLs, keys, or gRPC subscriptions. The gated changes will activate at the same slot for all nodes. What may require an update is your code: handling zero-fee failures, preparing the spill account for upgrades, and calculating rent at runtime.
Conclusion
Agave 4.4 looks quite uneventful on the surface. SIMD-0290 and SIMD-0317 move Solana towards validation that doesn't depend on execution, while SIMD-0433 and rent cuts make state maintenance less expensive. Check your indexer for zero-fee failures before the gate reaches testnet, and don't hardcode rent values.
Resources
1. Agave v4.4.0 release
2. Agave changelog
3. Feature gate tracker schedule
4. SIMD-0290: Relax fee-payer constraint
5. SIMD-0433: Loader v3, set program data to ELF length
6. SIMD-0317: Enforce 32 data + 32 coding shreds
7. SIMD-0599: Remove inactive stakes from rewards
8. SIMD-0437: Incremental rent reduction
---
Originally published at orbitflare.com.
Mentions
The browser doesn't trust the server: a Solana frontend that checks its own backend My server can tell the web page that a borrower got credit tier A. The page doesn't show it until Solana agrees. That sounds like paranoia about my own code, so here's the context. I'm building TEE Income Oracle. A borrower's bank statement is scored inside a secure enclave, the enclave signs a credit tier, and the tier is written to Solana, where a lending pool reads it before it lends. Between the browser and all of that sits a server I wrote, the gateway. It talks to the enclave, streams progress to the page, and pays transaction fees so a demo wallet needs no SOL. The whole product claims that a lender doesn't have to trust me. If the page repeats whatever my gateway says, that claim stops at the page. So the page treats the gateway as a messenger: it can carry bytes, but it never becomes the source of anything the page calls verified. This post is for frontend developers building on Solana. You know transactions, signatures and RPC calls; you don't need to know anything about enclaves. It walks through five places the page checks its own backend, each as the shortcut, what can go wrong with it, and what the page does instead. The page still trusts two things, the RPC node it reads from and the code I serve it, and I'll come back to both at the end. Every link points to release v0.5.5. 1. Sign your own copy Before scoring starts, the borrower signs a short text that ties the session to their wallet. It's a plain message signature, the kind a wallet's signMessage produces, not a transaction: tee-income-oracle: bind session session: <session id> wallet: <borrower's address> policy: <policy hash> expires: <unix seconds> The policy hash identifies the scoring rules the enclave will apply; each pool says which policy it accepts. The shortcut: the gateway sends this text, the page passes it to the wallet, and the wallet signs it. What can go wrong: the gateway now holds the pen. Whatever it puts in that text gets signed: a different wallet, an expiry next year, a policy no pool lends under. In the demo the wallet lives in the browser tab and signs without a prompt, so nobody reads the text first. What the page does: it writes the text itself and signs its own copy, and only if the gateway's copy is identical. The wallet line comes from the page alone. The other values come from the gateway, so the page can only hold them to rules: the session id must match the session the page will submit under, the policy must be one a listed pool lends under, and the expiry must fall within the next ten minutes (plus a minute for clock skew). A gateway can still choose the session and the policy within those rules. It can't get a signature for anything else. (intent.ts) This isn't a quirk of my setup. Kit's documentation for signing off-chain messages makes the same argument from the other side: a valid signature from a wallet proves little until you've also confirmed it covers the message you meant to have signed. 2. Check that the signature you got back is yours To borrow, the page builds a transaction and the borrower signs it. The gateway's relayer pays the fee, so it signs too, sends the transaction, and returns its signature. The page polls that signature until it's confirmed. The shortcut: take the returned signature, wait for "confirmed", show "borrowed". What can go wrong: every confirmed transaction has a signature. A buggy or hostile relayer could hand back one from an earlier borrow, or from someone else's, and the page would celebrate a loan that never happened. Reading the loan account afterwards helps, but on public RPC that read can come from a node that's behind. What the page does: on Solana, a transaction's id is its first signature, and the first signature belongs to the fee payer, signed over the transaction's message bytes. The fee payer here is the relayer. So the page checks that the returned id is a valid relayer signature over the exact bytes it built. With @solana/kit (the library formerly released as web3.js 2.0), that's a decode and a verify: const { messageBytes } = getTransactionDecoder().decode(wire); const signature = getBase58Encoder().encode(returnedId); if (!isSignatureBytes(signature)) return false; return verifySignature(relayerKey, signature, messageBytes); Solana's guide to partial signing gives a similar rule to whoever assembles a transaction from several signers: before you submit, make sure each signature you collected is over the message you froze. The page applies it from the other end, after submission, to the one id that comes back. A signature over any other message fails, so the id is tied to these exact message bytes. (The excerpt is condensed from isOurTransaction in use-loan.ts.) That still isn't complete replay protection. Ed25519 signatures are deterministic: the same key signing the same bytes always gives the same signature. So two identical borrows built on the same blockhash have the same id, and asking for the latest blockhash each time doesn't guarantee a different one. The chain is safe either way: validators drop a transaction they've already processed, so nothing executes twice. The risk is to what the page believes. Before relaying, the page reads the loan account and refuses to borrow while a loan is open, so a replay needs a repay in between: borrow, repay, then an identical borrow while the blockhash is still valid, about a minute. A relayer could answer that last borrow with the first one's signature, which did confirm. The page reads the loan account again after confirmation, but that read has no lower bound on freshness, so a node still showing the first loan would let it through. 3. Show what the chain says, not what the server says When scoring finishes, the gateway streams the result: the tier, and the payload it says the oracle wrote to Solana. The payload is the signed part of the on-chain record, including the tier, the policy, the statement dates and the enclave build that scored it. The shortcut: show the tier straight away, and read the chain for extra details. My first version did this. A reviewer described it as the gateway's word with a seal on it. What can go wrong: the page looks verified while showing an unverified value. My first fix had a subtler hole. It matched the chain record to the gateway's report by timestamp, then kept displaying the gateway's tier. A gateway could relay a real tier C record and report tier A with the same timestamp. The timestamps match, and the page says A. What the page does: it shows "reading your tier back from Solana…" until the payload on chain matches the reported payload, field by field. It then displays that payload and the record's expiry, both as read from Solana. If a payload at least as new as the report differs in any field, the page shows an error. That doesn't prove the gateway lied, because the oracle lets a newer record replace an older one, but the chain no longer confirms the report, so the page fails closed. (borrow-view.ts) The same mistake hid in a smaller place. A "registered on Solana" chip was fed by a gateway endpoint. Now only a read of the on-chain registry can say "registered". The gateway still moves the page from one step to the next, and it supplies the link to its transaction. It never supplies a value the page shows as fact. 4. A "valid" badge is a promise about the program The loan page shows a badge for the borrower's tier against a pool: valid, stale, expired, policy mismatch and so on. The shortcut: check the rules that seem important. My first version did that, and review found four of the pool's checks missing. The badge could say "valid" about a credential the program would reject. What the page does: it runs every credential check the pool program runs, in the program's order: 1. the record was written by the oracle, 2. it hasn't expired, 3. the pool lends to this tier at all, 4. it was scored under the pool's policy, 5. it's fresh enough (how old the record is, how old the bank statement is, and how many days it covers), 6. the enclave build that scored it is approved by the pool and not revoked. The order matters because the badge names the first check that fails, and that should match what the program would say about the same credential. (credential.ts, borrow.rs) Even then, "valid" makes a narrow promise: the credential passes this pool's checks at the state and time the page read. A borrow can still fail for reasons outside the credential: the amount is over the tier's limit, there's already a loan in this pool, the vault is short, a token account is frozen, or the state changes before the transaction runs. The funders' loan book runs the same function for every borrower, so "fresh" there makes the same narrow promise. Choosing which checks to run is a product decision too. Repay first sat behind the same "is your tier valid?" gate as Borrow, which locked a borrower with a stale tier out of repaying, and repaying needs no tier at all. Repay now has no tier check in front of it. 5. The RPC node is a server too Reading "from the chain" really means reading from an RPC node, which is someone else's server. Two things went wrong there. A node one step behind. Public devnet RPC is load-balanced, so the read right after a confirmation can land on a node that hasn't caught up. The tests didn't catch this; a manual run on the live site did. After a repay, the page read the pool and saw the loan was gone. Then the data layer fetched again, hit a lagging node, and the closed loan came back on screen. The fix has two parts. The read-back retries a few times, and it reads the pool, its vault and the loan in one call, so all three come from the same node. Then the read that proved the change goes straight into the cache of TanStack Query, the page's data layer, and any fetch already in flight is cancelled, so it can't overwrite it: await queryClient.cancelQueries({ queryKey: poolKey }); queryClient.setQueryData(poolKey, provingRead); That fixes the race I saw, and no more. A later refetch, say when the tab regains focus, can still hit a lagging node. Solana's RPC has a parameter for the general case, minContextSlot. Account reads such as getMultipleAccounts return the slot they were evaluated at in context.slot. Keep the highest slot you've accepted, pass it as minContextSlot on later reads with the same commitment level, and a node that hasn't reached that slot returns an error (code -32016, "Minimum context slot has not been reached") instead of older data. The page doesn't do this yet. A reply that's one short. The funders' loan book asks for up to 100 accounts per call and matches each reply to its request by position. Nothing checked the reply's length. The RPC spec says a node returns one entry per address, with null for an account that doesn't exist, but the page took that on trust. A node, or a proxy in front of one, that returned 99 accounts for 100 addresses would shift every row after the gap, and show one borrower with the next borrower's "fresh" badge. Now a reply of the wrong length is an error (rpc.ts). So is a duplicated loan row, which would inflate every total, and so is a record that doesn't name the borrower it was fetched for. One bad row fails the whole book (use-book.ts), because a partial book presented as the book is worse than an error. Where the trust actually stops None of this makes the page trustless: - It reads one RPC node. It checks what's cheap to check: reply lengths, account sizes and types, which wallet a record belongs to, and signatures over bytes it built. A node that invented consistent data could still fool it. - "Confirmed" also comes from that node. The signature check proves the id belongs to the bytes the page built; the node still reports whether they landed. - The gateway names the relayer. The relayer's key comes from the gateway's own info endpoint. The signature check ties the returned id to the bytes the page built; it doesn't prove who paid the fee. - I serve the page. A different build could skip every check. That's why the source is public at release tags, and why the receipt checks also run from a command line. What the checks do buy: my gateway is no longer the only authority for a tier, a loan or a registration. The page checks each of those claims against what an RPC node returns, and most gateway bugs now show up as an error on screen instead of a wrong number. The limits above still apply: a stale read, or a reused identical transaction, can get past these checks. A checklist for your own frontend - Rebuild anything the user signs from data you already hold, and sign your copy. - Treat a signature from an API as a claim. If you built the transaction, verify the signature over its bytes. It ties the id to those bytes; it doesn't stop an identical transaction being reused. - Show values from a chain read, not from the API that triggered the write. Compare every field of the reported payload, display the chain's values, and fail closed when the payloads differ. Read anything outside the payload, such as expiry, straight from the chain. - Make a status badge mirror the program's checks, in the program's order, and say what it doesn't cover. - After a write, keep the read that proved it. For later reads, carry the highest slot you've accepted forward as minContextSlot. - Check reply lengths whenever you match results to requests by position. To try this on your own app, pick one value your UI shows as confirmed, and trace where it comes from. If the answer is "the API told us", that's the first check to add. --- Originally published on prashantchaudhari.dev.
🚨 Mainnet-beta validators: Agave v4.4.0 is recommended for general adoption. Upgrade now. github.com/anza-xyz/agave/releases/tag/v4.4.0
Agave 4.4: What Changes for Solana Developers On 28 October 2026, Anza announced Agave v4.4.0 as stable, recommended for 20% of mainnet stake and for testnet and devnet. Now, mainnet uses 4.3.2, so this is what validators will move to over the next few weeks. It adds three new gates, alongside the SIMD-0290 gate that was already in 4.3 and waits to be activated, along with a brief list of RPC and operator changes. None of the gates are active, but two change the content of blocks and program accounts, so check before they flip. Key Takeaways - SIMD-0290 lets blocks have transactions whose fee payer can't pay. Transactions like that show up as failed, with a zero fee and no logs. - SIMD-0433 makes program upgrades resize the program data account to the new binary, refunding surplus rent. - SIMD-0317 requires 32:32 FEC sets, and SIMD-0599 removes inactive stake from reward calculations. - Rent is already down to 5,080 lamports per byte on mainnet; the next cut to 2,575 awaits testnet. - getTransaction and getSignatureStatuses support minContextSlot, and account subscriptions obey dataSlice. This guide is for developers deploying indexers, bots, and programs on Solana, as well as for everybody who works with raw blocks. Where things stand We read the gate accounts on mainnet and testnet directly on 29 October 2026 (mainnet epoch 1071). !Feature gate status on 29 October The timing is important to remember. Epochs are still 432,000 slots long, and on our Amsterdam node it took about 25.5 hours each to process epochs 1069 and 1070, with an average slot duration of 213 milliseconds once skipped slots are counted. Gates activate at epoch boundaries, so a scheduled activation becomes live about a day later. SIMD-0290: blocks can carry transactions that cannot pay Today, the presence of just one transaction whose fee payer can't pay enough to cover the fee makes the whole block invalid. With SIMD-0290, this requirement is relaxed for recent-blockhash transactions (and durable nonce transactions are waiting for SIMD-0297 activation). Such a transaction stays in the block but doesn't execute anything. It is a step towards asynchronous execution. We reviewed the 4.4.0 codebase to learn how such transactions are recorded in the block: - The status of a transaction is an error, the same error that used to make the whole block invalid, for instance InsufficientFundsForFee or AccountNotFound. - The fee is zero. Nothing transfers and account states don't change. - There are no log messages, inner instructions, or return data. - Such a transaction contributes to block limits according to its full requested compute unit limit, rather than actual usage. This makes it impossible for a leader to stuff too many free transactions into a block. Calculations that sum meta.fee over failed transactions will give incorrect results here, and algorithms that expect every failed transaction to have logs or a paid fee payer need to be checked. Consider a transaction failure with zero fee and no logs as "included, not executed". SIMD-0433: program upgrades resize the account Loader v3 allows increasing the size of a program data account using ExtendProgram, but never reducing it, meaning that when a program is rewritten to a smaller binary (like in the case of Pinocchio), it keeps paying rent for the original size. Once SIMD-0433 activates, the Upgrade operation resizes the account to fit the new ELF plus metadata header. The surplus rent is refunded to the spill account, and a larger binary grows the account without a separate ExtendProgram call. Before the next deployment after the activation, make sure that: - The spill account exists. It is where the refunds will go, so make sure that it is your account. - The lamports for growth. The extra rent should be in the program data account or in its buffer prior to Upgrade, otherwise it fails with InsufficientFunds. - The rent you overpaid earlier. Upgrading resets the account balance to the minimum required rent and sends the rest to the spill account, even without SIMD-0433. Programs deployed before the two rent cuts receive some of the deposit back on the next upgrade. - Upgrades via CPI. Multisig and governance programs that upgrade a program via CPI still have the 10 KiB per-instruction growth limit. Perform the ExtendProgram operation in several iterations first to increase the size, or upgrade on the top level. SIMD-0317: fixed 32:32 FEC sets Blocks transit through Turbine as shreds, grouped into forward error correction (FEC) sets. Every client already sends 32 data shreds and 32 coding shreds per set, but receivers still accept all kinds of combinations. SIMD-0317 mandates 32:32 sets, and any other set will be dropped on ingest. The gate checks the size of the Merkle proof generated from a 64-shred set in the codebase. It also fixes the size: 995 bytes of payload in each data shred and 31,840 bytes per set. Receivers can validate shred indices without waiting for coding shreds, and two valid shreds from one set with distinct Merkle roots prove equivocation. There is no practical difference for teams decoding shreds themselves, including ShredStream consumers, as the senders use the same format anyway. SIMD-0599: inactive stake leaves the rewards path Partitioned epoch rewards currently traverse every stake account regardless of whether it has effective or activating stake in it. They earn nothing, but they still affect the number of partitions and the lattice hash. SIMD-0599, jointly developed by Anza and Firedancer engineers, removes stake that didn't have any effective or activating stake in the whole rewarded epoch from this calculation. Stakes that deactivate at the boundary still receive rewards for their last epoch, and the users see no difference. The optimization is significant though. Scanning the mainnet stake accounts on our Amsterdam node we found that out of 1,364,680 delegated stake accounts 232,962 (17.1%) were completely inactive, storing about 3.28 million SOL. All of these accounts, every client processes at every epoch boundary now. Rent: two steps live, step three gated SIMD-0437 reduces the lamports_per_byte parameter from 6,960 to 696 in five steps, each separately gated. The first and the second step are live on mainnet. The third one, down to 2,575, is already in 4.3.0-rc.1 and is pending activation on testnet. The fourth and fifth steps (to 1,322 and 696) are not on the activation schedule yet. This is how the rent for a standard 165-byte token account (rent is calculated on the size of the data + 128-byte overhead) looks now: !Rent for a 165-byte token account Any hardcoded 2039280 in the code is already incorrect on mainnet. Always calculate the minimum rent from getMinimumBalanceForRentExemption or the Rent sysvar, because this value changes three more times. RPC and operator changes in 4.4 These updates come with the binary and don't wait for a gate: - getTransaction supports minContextSlot. - getSignatureStatuses supports commitment and minContextSlot, and still defaults to processed. If the node is behind, it returns error -32016, allowing load-balanced clients to retry on a different node and not get stale data. - accountSubscribe and programSubscribe respect dataSlice. A zero-length slice returns empty data, which is useful for watching lamport or owner changes without paying for the account data. - getLeaderSchedule returns the new error -32022 if the requested identity is not present in the schedule. - Validators running an external scheduler need version 5 of the bindings. The --experimental-retransmit-xdp-* command line flags are gone in favor of --xdp-interface, --xdp-cpu-cores and --xdp-zero-copy. What this means on OrbitFlare Our devnet already runs 4.4, and you can start experimenting with minContextSlot and dataSlice subscriptions right now. Our mainnet regions will follow Anza's adoption guidance without any changes in URLs, keys, or gRPC subscriptions. The gated changes will activate at the same slot for all nodes. What may require an update is your code: handling zero-fee failures, preparing the spill account for upgrades, and calculating rent at runtime. Conclusion Agave 4.4 looks quite uneventful on the surface. SIMD-0290 and SIMD-0317 move Solana towards validation that doesn't depend on execution, while SIMD-0433 and rent cuts make state maintenance less expensive. Check your indexer for zero-fee failures before the gate reaches testnet, and don't hardcode rent values. Resources 1. Agave v4.4.0 release 2. Agave changelog 3. Feature gate tracker schedule 4. SIMD-0290: Relax fee-payer constraint 5. SIMD-0433: Loader v3, set program data to ELF length 6. SIMD-0317: Enforce 32 data + 32 coding shreds 7. SIMD-0599: Remove inactive stakes from rewards 8. SIMD-0437: Incremental rent reduction --- Originally published at orbitflare.com.
I used REA and a swarm of 40 parallel agents to reverse engineer the entire Solana blockchain. Leader schedule, Gulf Stream, Sealevel, Tower BFT. Rebuilt in 72 hours, zero humans in the loop. Releasing it all open source. No token, no paywall. anza-xyz/agave
🚨 Mainnet-beta validators: we're looking for volunteers to bring 10% of stake to Agave v4.4.0-rc.1 by EOD Friday, Oct 30 per routine upgrade procedure. github.com/anza-xyz/agave/releases/tag/v4.4.0-rc.1
Get your funds off any Solana or SVM chains and move them to Ethereum Mainnet. f5df29e4e18d99626f6676cfebfd026f86ff2e14643b5391d7c8df22f18e2494 anza-xyz/agave
🚨 Mainnet-beta validators: Agave v4.3.2 is the recommended version for all validators. Upgrade now. This release includes important performance and stability fixes for Alpenglow coming epoch 1064, Oct 21. github.com/anza-xyz/agave/releases/tag/v4.3.2
Anza Advances Solana Agave Client with Series of V4 Pre-Releases AI disclosure: drafted by Basis Desk's AI newsroom and machine-checked against the primary sources listed below — how we use AI. Originally published on Basis Desk. > Multiple pre-releases for the Agave validator client have been published on GitHub. Key points - Anza released Agave v4.3.1 as a pre-release on Oct. 13. - Agave v4.4.0-beta.1 was also released as a pre-release on Oct. 13. - Earlier pre-releases include v4.5.0-alpha.2, v4.5.0-alpha.1, and v4.4.0-beta.0. Anza has released a series of pre-release versions for the Solana Agave validator client [1]. Recent Agave Pre-Releases On Oct. 13, Anza released version v4.3.1, a pre-release for the Agave client [1]. Earlier the same day, version v4.4.0-beta.1 was also published as a pre-release [2]. These releases follow prior pre-releases, including v4.5.0-alpha.2 on Oct. 8 [3], v4.5.0-alpha.1 on Oct. 3 [4], and v4.4.0-beta.0 on Sept. 28 [5]. All of these versions are marked as pre-releases on GitHub [1][2][3][4][5]. The releases indicate ongoing development and testing for the Agave client, which is a fork of the original Solana Labs client [4]. Related: Anza Advances Solana Agave Client with Series of V4 Pre-Releases Sources 1. Release v4.3.1 — Agave (Solana) releases 2. Release v4.4.0-beta.1 — Agave (Solana) releases 3. Release v4.5.0-alpha.2 — Agave (Solana) releases 4. Release v4.5.0-alpha.1 — Agave (Solana) releases 5. Release v4.4.0-beta.0 — Agave (Solana) releases --- Basis Desk is a source-verified crypto newsroom. Market data, a free MCP server for AI agents and JSON APIs: basisdesk.news. Not investment advice.
a working proof of concept of the solve already exists in crypto, and it's open source so other industries can use this work github.com/anza-xyz/cryptography/tree/master/expe…