Solana Blockchain 6.1.1

Latest

8 August 2026

This release has upgrade notes. Read them before updating — they describe behaviour changes that need your attention.

PERFORMANCESOLANADEPOSITSSPLTOKENSRPCSCANNINGMEMORYBUG-FIXESECOSYSTEM

Solana Blockchain v6.1.1

Release Date: August 8, 2026 Tags: PERFORMANCE, SOLANA, DEPOSITS, SPL, TOKENS, RPC, SCANNING, MEMORY, BUG-FIXES, ECOSYSTEM

Overview

A performance release for deposit detection, plus one narrow correction on token deposits.

The background scanner that catches deposits a live connection missed replays the twenty-five most recent transactions on every Solana address it watches, every pass. It downloaded each of those transactions again on every pass, forever, whether or not the deposit behind it had been credited months ago. It now checks its own records first and fetches only what it has not already settled — the same deposits credited, a fraction of the calls to your RPC endpoint, which is the resource this chain runs out of first.

The correction affects tokens only. A customer who withdrew an SPL token to a Solana address the platform itself had issued them saw the outgoing half leave their balance and the incoming half never arrive.

Requires Core v6.6.3 and the Ecosystem extension.

Update Instructions

# 1. Update the addon in Admin → System → Extensions
# 2. Restart the backend
pnpm updator

No schema change. No new tables, no seeders, nothing to configure.


Upgrade Notes

A self-transfer that was already swallowed is not repaired retroactively

The scanner only ever looks at the twenty-five most recent transactions on an address, so it can only credit what is still inside that window.

  • A skipped token self-transfer still within the last twenty-five transactions on that address is credited on the next scan after you update.
  • Anything older is outside what the scanner can see and stays uncredited. If you know of a customer who withdrew a token to their own platform deposit address and never saw it come back, settle that one by hand.

Changed

Deposit scanning stops re-downloading deposits it has already credited

The scanner exists to catch anything the live connection missed, so it re-reads recent history on a timer. It had no memory between passes: every couple of minutes, for every watched address, it fetched the same twenty-five transactions from the network and worked out again that they were already settled. On a busy installation that is the bulk of the chain's RPC traffic, spent on answers it already had.

  • Changed the background scan to check whether a transaction has already been credited to that wallet before fetching it from the network, and to remember that answer for the rest of the pass. Deposits are detected and credited exactly as before; what changed is how much is downloaded to reach the same conclusion.
  • Changed nothing about the scan that runs while a customer is watching their deposit page. That one still replays recent history in full, deliberately — replaying an already-credited transaction there is what produces the confirmation a customer sees when the credit landed while their page was closed.

Transaction lookups held in memory

Fetched transactions are held briefly so that several wallet listeners watching the same deposit do not each ask the network for it. Entries were only ever added. Nothing removed them, so a backend that had been running for weeks was holding one entry for every Solana transaction it had ever looked at.

  • Changed the platform to drop cached transactions once they are past their one-minute life, sweeping once a minute. The cache answers exactly the same questions; only what it keeps afterwards changed.
  • Changed the sweep to be registered once, when Solana support first starts, and never to hold the process open by itself.

Fixed

A token withdrawal to a customer's own deposit address swallowed the incoming credit

When a customer withdraws an SPL token to a Solana address the platform issued them, a single on-chain transaction carries both halves of it. The platform records the outgoing half against that transaction, and the token scanner then treated any record under that transaction as proof the incoming half had been dealt with. So the withdrawal left the balance and the matching deposit was never credited — on a transfer that never left the installation.

  • Fixed the token scanner to look for a recorded deposit before deciding a transaction has already been handled, so the incoming half of a self-transfer is credited on its own merits.