Ecosystem v6.5.6

Release Date: October 1, 2026 Tags: DEPOSITS, WITHDRAWALS, ORDER BOOK, WALLETS, BSC, TRON, CUSTOM CHAINS

Overview

A deposits release, with one decision to make before you update. The background scanner now watches every Ecosystem address a signed-in customer owns and credits any on-chain deposit that has no deposit record — including one support already made good by hand. Read the first Upgrade Note before the new build starts.

It also stops the scanner from hanging for good on a dead connection, keeps a wallet's existing key when its address is re-issued, refuses a withdrawal into the platform's own system accounts, and reads the order book through the short pages that made market orders fail against a full book.

Requires Core v6.8.2, released with it: the deposit registration at sign-in, the key checks and the wallet-service failure handling this release relies on are in Core.

Update Instructions

pnpm updator

Update Core 6.8.2 in the same window, and set the two .env lines in the first Upgrade Note first if they apply to you. There is no schema change of this add-on's own.

Upgrade Notes

The first start credits deposits nobody asked about

Signing in, a session renewal and loading the wallet list now put every Ecosystem address a customer owns under the background scanner, and a scan credits every incoming transfer to a watched address that has no deposit record for its transaction hash. A balance an administrator added by hand carries no hash — so a missing deposit that support made good with a manual balance edit will be credited a second time. Sessions renew straight away, so this starts with the first start of the new build, not with new sign-ins.

How far back it looks: EVM native coins over the last 7 days (was 24 hours), EVM tokens over the last 3,000 blocks, and BTC, LTC, DOGE, DASH, TRON, TON and Solana over whatever history the provider returns. Monero is kept off this lane by default. On those last chains this already happened on the previous release when a customer opened the deposit page; what is new is that it now happens for every signed-in customer without them doing anything.

• On a mainnet install, or anywhere support has compensated a missing deposit by hand: audit first — incoming on-chain transfers per Ecosystem address with no deposit record — or put these in .env before you update, and widen them after the audit:

  ECOSYSTEM_SCAN_CATCHUP_WINDOW_MS=0
  ECOSYSTEM_SCAN_PASSIVE_SKIP_CHAINS=XMR,BTC,LTC,DOGE,DASH,TRON,TON,SOL

  0 limits EVM native coins to the last 24 hours. The skip list covers the new slow lane only: a customer who opens a wallet or the deposit page still puts that wallet's chains on the fast lane, as before.
• ECOSYSTEM_BACKGROUND_SCAN="false" turns the background scanner off entirely, including the deposit-page catch-up the previous release already had. The live deposit page keeps working.
• Every other tuning variable has a working default; they are documented in .env.example under "Background deposit scanner".

BNB Smart Chain testnet and TRANSACTION_PROVIDERS

NodeReal now serves BNB Smart Chain testnet as well, so NODEREAL_API_KEY alone is enough there. .env.example still says it does not; that line is out of date.

• If .env sets TRANSACTION_PROVIDERS, it replaces the built-in order for every chain: name nodereal in it, or pin BNB Smart Chain alone with TRANSACTION_PROVIDERS_BSC=nodereal.

Added

Deposits are found without the deposit page

Until now the background scanner watched an address only after its owner had opened the deposit page, so a deposit sent to an address copied from the Wallet page waited until somebody opened that page.

• Added background deposit detection for every Ecosystem address a signed-in customer owns. Signing in, a session renewal and loading the wallet list put the customer's addresses on a slow lane (re-checked every 15 minutes, for 7 days after the last visit); opening a wallet puts that wallet on the fast lane (every 2 minutes for 72 hours). Monero is kept off the slow lane by default.
• Added a heartbeat for the scanner: redis-cli GET ecosystem:depositWatch:heartbeat shows what it did last.

Changed

Sends are serialised across processes

The backend, the cron process and pool-backing settlement can all sign from the same address. Nothing stopped two of them doing so at the same moment.

• Changed EVM customer withdrawals, pool-backing settlements (EVM, Solana and TRON) and the one-off EIP-7702 delegate deployment to hold a lock on every signing address across all server processes. A withdrawal that cannot get the lock within 30 seconds, or while Redis is unreachable, goes back to pending with nothing signed and is retried automatically; a settlement in the same position is marked failed unsent, with the reason, and its obligations reopen.

A market order your own orders cannot fill says so

• Changed the refusal for a market order whose only liquidity is the customer's own resting orders — typically the owner and their trading bot on one account. It now says how many of the resting orders are the customer's own, at what prices, and that an account cannot trade against itself, instead of only "insufficient liquidity… reduce the amount". A market SELL facing only the customer's own bids gets the same explanation instead of "no price available". The opening words and the status code are unchanged, so Hummingbot still classifies it as before.

Order reads cost far less CPU

On one live install the backend spent 38.7% of its CPU decoding order rows for an account with about 460,000 orders.

• Changed how order rows are decoded, removing most of that cost on accounts with very large order histories.
• Changed the trade panel's order-history list to read the newest 1,000 orders instead of up to 5,000 to show 250. An account whose newest 1,000 orders are mostly still open sees a shorter history list.

Blockchains and custom chains in the admin

• Changed the check made when a blockchain is enabled: its licence must be valid on this server, not merely present. After moving an install to a new server, activate each blockchain add-on's licence again before enabling it.
• Changed the custom-chain form: a chain ID above 2,147,483,647, or a value longer than its database column, is refused with a message naming the field instead of being handed to the database.

Fixed

Deposits that were never credited, or credited late

• Fixed the background deposit scanner stopping for good when one address scan hung on a closed blockchain connection: deposits whose owner did not have the deposit page open went uncredited until the cron process was restarted. Every address scan now runs under a time budget, each chain is scanned in its own lane so a slow Bitcoin scan no longer holds up the others, and a stalled loop is restarted automatically.
• Fixed the pending-deposit verifier hanging on a closed connection, which stopped pending EVM deposits on every chain from being finalised. Its reads now use HTTP with a 15-second limit, and a node that does not answer is retried without counting toward the limit after which a deposit is set aside for manual replay.
• Fixed the deposit page's live monitor for native EVM coins switching for good to block scanning after one explorer error, giving up after ten, or silently stopping when a poll never returned — the page then waited for a deposit that had already arrived.
• Fixed live token-deposit monitors going deaf when the shared connection for a chain dropped: one customer's reconnect destroyed the connection the others had just re-attached to, a failed reconnect was never retried, and a monitor stopped listening a few minutes after a credited deposit while still being reused.
• Fixed the NodeReal history provider (the first one tried for BNB Smart Chain): its lookups failed and transaction times were read from the wrong field, so native BNB deposits were never credited through it — on an install whose only BSC key was NODEREAL_API_KEY, only while the deposit page was open.
• Fixed TRON deposits being credited in the wrong currency: a TRC-20 token saved without its contract address, or a non-TRX token marked as native, was scanned as plain TRX, so TRX arriving at its address was credited as that token. Such a token is now refused for deposit monitoring until its contract is set.
• Fixed deposit monitors that kept polling after the customer had left the deposit page (the Back button, two subscriptions arriving together, a tab closed while the monitor was starting), spending explorer and RPC quota until the backend restarted. A monitor now stops 10 minutes after its user's last deposit-page socket goes away.
• Fixed a failed deposit subscription (for a coin with no wallet, say) stopping the monitor the same customer was using in another tab, and Bitcoin-family, TON and Monero monitors being rebuilt on every subscribe.
• Fixed the deposit page greeting a customer with "Deposit Successful" for an old, already-credited deposit as soon as it opened (most visible on Solana). Only a deposit credited in the last 15 minutes is announced; no balance was ever changed by the stray message.
• Fixed the scanner on BTC, LTC, DOGE and DASH re-downloading the platform's own refused change outputs on every pass and logging them as credited.

Withdrawals and deposit addresses

• Fixed a deposit address being re-issued over a wallet's existing key. When a Funding wallet's address entry for a chain was missing or unreadable, opening the wallet minted a new key over the old one (and zeroed the chain's recorded balance on Solana, TRON, TON and Monero), so coins still on the old address could no longer be moved. The existing key is now kept and its address restored; if it cannot be read safely, or the chain is Monero, nothing is minted and the log names the wallet ("Refusing to replace the … key of wallet …"). Keys overwritten before the update are not recovered.
• Fixed a race when issuing token deposit addresses on EVM chains: two customers issued an address on the same chain at the same instant could be given the same master-wallet index, and so the same address. The index is now taken under a lock and checked as it is written.
• Fixed withdrawals to a deposit address belonging to one of the platform's own system accounts (such as the pool-backing treasury) moving the customer's balance into that account as an internal transfer. They are now refused.
• Fixed EIP-7702 token withdrawals signing their authorization against the last mined nonce: with another transaction from the same address still pending, the authorization could be void when mined and the withdrawal recorded as completed although the token never left. It now uses the pending nonce.
• Fixed the per-chain balance record of a customer whose EVM token withdrawal was paid from another address: the full amount was added back even when the original debit had taken less, overstating the on-chain figure on the Ecosystem dashboard's coverage and the Mirror figure on Pool backing. Existing records are not rewritten.
• Fixed withdrawals on Solana, TON and TRON describing themselves as "Pending withdrawal of …" for ever. New withdrawals read "Withdrawal of … to …".

The order book read as thin or empty

To price an order the engine read each side of the book in pages of 200 and took the first short page as the end. ScyllaDB also returns a short or empty page when it runs into many deleted rows, which market-maker re-quoting leaves behind.

• Fixed market BUY orders refused with "Order book has insufficient liquidity" (and market SELLs finding no price) while orders were visibly resting. The same short read affected limit-order fee classification, fill-or-kill checks, OCO and stop orders, copy trading and the public order-book feed. The book is now read until the database says it has ended.
• Fixed the same problem in the matching engine's re-read of a very large bid level, which could load only a few of its orders, or its newest instead of its oldest.