Ecosystem v6.4.8

Release Date: August 27, 2026 Tags: DEPOSITS, EVM, RPC, WITHDRAWALS, CUSTOM-CHAINS, CORRECTNESS

Overview

A deposit-detection release. On a chain whose RPC endpoint refuses a wide log query, the background scanner that finds contract-token deposits abandoned the whole sweep at the first refused block range — and because that refusal depends on the size of the window and on the endpoint rather than on the moment, the same refusal came back on the next pass, and the one after that.

So USDT, USDC and every other non-native ecosystem token deposit on that chain went uncredited unless the customer happened to stay on the deposit screen while the transfer confirmed, because the live watcher takes a different path. Nothing errored to anyone. The only trace was a warning line repeating in the backend log — and the free public endpoints, BSC's dataseed nodes being the observed case, are exactly the ones that answer this way.

Read Upgrade Notes before you update. That log line is the only way to tell whether your install was affected, and the customers who were missed have to be found by hand. Requires Core v6.7.3.

Update Instructions

pnpm updator

Restart the backend and ship the frontend build. There is no database change and nothing to run; the two new scan settings are optional.

Upgrade Notes

Token deposits missed on a rate-capped chain

Search your backend log for token sweep failed alongside the words limit exceeded. For as long as that line was repeating for a chain, every contract-token deposit on it went undetected unless the customer was sitting on the deposit screen when the transfer confirmed. Those customers were never paid, and nothing told them or you which deposits they were.

• Fixed the sweep itself, so detection resumes on those chains when the backend restarts.
• Review token deposits on any chain that produced that warning. Check the addresses against the chain's explorer before crediting anything by hand.
• If the log now reports skipped block ranges for one chain, pin its scan window with ECOSYSTEM_SCAN_EVM_CHUNK_BLOCKS_BSC — the key takes any chain in place of BSC — or for every chain at once with ECOSYSTEM_SCAN_EVM_CHUNK_BLOCKS.

Added

Per-chain tuning for the token deposit scan

The scanner no longer asks every endpoint for a fixed one thousand blocks at a time, and nothing needs setting for that: it negotiates the window with the node and remembers what worked.

• Added ECOSYSTEM_SCAN_EVM_CHUNK_BLOCKS_<CHAIN> to pin the starting window for one chain, and ECOSYSTEM_SCAN_EVM_CHUNK_BLOCKS to pin it for all of them. Both default to one thousand blocks.
• Native coin deposits are unaffected. Those are found through the chain's block explorer, not through a block window.

Changed

Which chains hold gas back in the max-withdraw quote

A chain's native coin pays its own network gas out of the balance being spent, so the "maximum withdrawable" figure has to hold some back or the quote cannot actually be sent. The list of chains getting that treatment was typed by hand, and it had drifted from the platform's own chain list.

• Changed the quote to use the platform's own list. MO Chain was missing from the hand-typed one, so native MO was quoted at the balance less the platform fee with nothing held back for gas, and the withdrawal then failed at broadcast and was refunded automatically. Native MO max quotes are now lower by the estimated gas and can be sent.
• RSK moves the other way. It was on the hand-typed list and is not on the platform-wide one, so native RBTC max quotes no longer hold gas back and will quote more than can be sent — an RSK customer clicking Max now hits the same failed-and-refunded round trip MO customers used to, until they withdraw slightly less.
• Custom EVM chains an operator added themselves are unchanged and still gas-estimated. Nothing about the amount actually charged for a withdrawal changed, and no wallet was ever left short in either direction: an under-funded native send is refused before it reaches the chain and refunded, and the gas debit that follows a confirmed send cannot take a balance below zero.

Avalanche and Linea can be added as custom EVM chains

Both were listed as built-in chains in the wallet layer but had no entry in the ecosystem's own chain registry, so neither could be dialled, monitored or credited. Because the platform still counted them as built-ins, adding either one properly through Admin → Ecosystem → Custom EVM Chains was refused with a conflict — the half-entry locked you out of the only door that would have made the chain work.

• Removed both built-in entries, so Avalanche and Linea can now be added from that screen like any other custom EVM chain.
• Changed the custom EVM chain add to register the chain in every registry and write its environment variables together rather than one of them.
• Nothing changes for existing wallets. Neither chain was ever offered in the admin blockchain, token or master-wallet screens, so no supported install could have issued an Avalanche or Linea address in the first place.

The scanner's already-credited shortcut is narrower

• Changed the shortcut the deposit scanner uses to skip transfers it has already credited, so it matches only a recorded deposit for that wallet. It used to match any record carrying the same transaction hash, including the withdrawal record of a transfer sent to an address on the customer's own account — in that one case the scanner treated the incoming leg as already handled and stopped looking at it. The crediting logic itself always applied the narrower check and was never wrong, and the withdrawal screen already refuses an address belonging to the customer's own account, so no balance is expected to have moved.
• Changed the failure path behind that shortcut: when its database lookup fails, the remaining transfers in the window still get their pass instead of the pass being abandoned.
• Applies to token transfers on general EVM chains. Native-coin transfers on those chains still use the older, wider check.

Fixed

Token deposits went undetected on rate-capped RPC endpoints

The background sweep is the only thing that finds a contract-token deposit once the customer has closed the deposit page, and it gave up on the entire sweep for an address at the first block range the node refused. That kind of refusal depends on the size of the window and on the endpoint rather than on the moment, so it returned on the next pass two minutes later and the one after that — the sweep could stay dead for as long as the endpoint kept saying no. A customer who stayed on the deposit screen was still credited, because the live monitor watches for the transfer event over an open connection instead of sweeping a wide range of past blocks. The customers who deposited and walked away were the ones left uncredited. BSC's public dataseed nodes, which refuse a wide query with the two words "limit exceeded" and no indication of which limit, are the observed case.

• Fixed the sweep to negotiate the window with the endpoint: fewer blocks when the node says the query is too big, a wait when it says there are too many requests, and both when it refuses without saying which.
• Fixed a refused range so it costs that range rather than the whole pass. Skipped ranges are reported in a warning with a count and an example range, and the following pass covers them again.
• The window size the endpoint actually served is remembered, so the next pass does not re-discover it.
• Changed the refusal log to carry the node's own one-line answer instead of the whole request payload.

RSK and HECO logos on the blockchain screen

• Fixed the RSK and HECO rows on the admin blockchain screen, which showed a blank generic coin badge because the page looked for each logo under the chain's name rather than its token ticker — two files that have never existed, requested afresh on every load. The artwork for both has always shipped under the ticker.