Core v6.8.7

Release Date: October 20, 2026 Tags: WALLET, DEPOSITS, TRADING, TABLES, XT, INSIGHTS

Overview

A wallet page no longer turns into another table, a filter holds, and a deposit reaches the pages that are open. Testers reported that My Wallets, after about fifteen seconds, showed rows of Exchange Orders with no currency under its own heading, and that a filter set on a wallet's transactions showed the filtered list for fifteen seconds and then every transaction. Both came from the store that every data table on the platform shares: an answer to an earlier question could land after a later one and replace it. The filter report also needed a wallet page that asked for its transactions before it knew the wallet. A trading bot had made 1.29 million transaction rows on one tester's account, and its transaction list takes fifteen to twenty seconds to answer, which is long enough for the page to have moved on.

The admin dashboard no longer waits for its slowest figure: on a big ledger one of them took longer than the web server's timeout, so the page never loaded. A table that fails to load now says why.

A notification about money now refreshes My Wallets, a wallet's page and Transactions History when one is open, rings, and shows a popup (not on the deposit page, which has its own), and the connection that carries it no longer gives up after ten failed attempts. A Spot or Ecosystem wallet's own page has a Convert button while Instant Convert is enabled. The Pro trade panel's Trades list follows a fill the moment History does, and its Open tab no longer counts four orders above a list of one. On a phone, the standard trade page's Orders tab now lists an Ecosystem market's orders.

On an install whose exchange provider is XT, a spot market buy can be placed again, and a limit order that rests on XT's book is recorded, held and listed under Open orders. Both failed: every market buy answered Unable to process order: xt createOrder() requires a price argument or cost, and a resting limit order was live on XT with nothing recorded, so the balance behind it could be spent a second time.

Published with this release: Ecosystem v6.6.1, Instant Convert v6.0.5, Hummingbot Connector v6.2.4, MLM & Affiliate System v6.2.5 and P2P v6.4.3. The wallet's Convert button opens Convert on the wallet's currency only with Instant Convert v6.0.5; with an older one it opens plain Convert.

Update Instructions

pnpm updator

It rebuilds the frontend and restarts the backend, so the site shows its maintenance page while it runs. No schema change, no seeder, no .env change. The new text is in English in all 90 languages until it is translated: eighteen strings, all for Instant Convert, thirteen on its Convert page and five in its admin console. MLM & Affiliate System v6.2.5 adds 168 more, five of them on the sign-up page.

Added

Convert on a wallet's page

• Added a Convert button after Transfer on the own page of a Spot or Ecosystem wallet, while Instant Convert is enabled. With Instant Convert v6.0.5 it opens Convert on that kind of balance with the wallet's currency chosen as what is given, when Convert lists that currency there; with an older Instant Convert it opens plain Convert. My Wallets has had its own Convert button since 6.8.6.

A popup and fresh balances when money moves

Most deposit, withdrawal and transfer notifications carry a link to a finance page (a dLocal deposit's links elsewhere and is not covered). Those pages read their figures once, when they opened, so a deposit credited while one was open changed nothing on it until it was reloaded, and only the notification bell, and after a first click the sound, said anything.

• Added a popup for a notification whose link is a finance page, with its title and message and no success or failure styling: the same kind of notification carries Withdrawal Failed and Deposit not credited as well as good news. The deposit page keeps its own confirmation and shows no second popup.
• Added a refresh of the balances when such a notification arrives, on the pages that read money: My Wallets, a wallet's page and Transactions History, when one is open. A burst of notifications is one refresh.

A referral code on the sign-up page

MLM & Affiliate System v6.2.5 lets an approved affiliate choose a personal referral code such as JEFF20. The parts of it that live in Core are these.

• Added an optional Referral code field to the sign-up form, opened by Have a referral code? or already filled in by a referral link. It accepts a personal code in any case, or a user id; it shows You Were Referred By and the referrer's username, or says the code is not recognised. An unrecognised code does not block the sign-up: the account is created and nobody is credited.
• Added the same lookup to the public referrer route the form calls, which now answers for a code as well as a user id. It still returns the referrer's username and avatar and no legal name, and now also the code in capitals when the reference was a code.
• Added a Referral Program link under Services and in the footer, shown only while the MLM add-on is installed and requires affiliate applications.

Changed

The homepage's Affiliate Program tile

• Changed the tile to drop its Rewards Paid figure while the MLM add-on's Show Commissions switch is off. The homepage does not know who is looking, so the figure goes for everyone; it is on the Affiliate page for approved affiliates. With the switch on, or never saved, nothing changes.

Fixed

XT: market buys, and limit orders that rest on the book

A tester on an XT install reported the error above on every spot market buy, and that a limit order did not appear under Open orders. Both are in how the platform asked for and read XT orders; neither touched the customer's balance.

• Fixed the market buy. XT counts a market buy in the currency it is paid with, and refuses one that names neither what to spend nor a price. The platform now sends XT the spend it has just priced and checked against the balance (the amount on the ticket times the last price, to the market's price precision), and books the order on what XT says it spent and received. Binance and KuCoin are unchanged: handing them a spend would turn a market sell into a sale by value.
• Fixed the limit order. XT describes an order resting on its book with no average price, and the platform's reading of an XT buy (the executed quantity divided by the average price) turned that into an amount that was not a number, which the order table refuses; a resting sell came out with an amount of 0. The booking failed after XT had accepted the order. An XT order that has traded nothing is now recorded with the amount it was placed for and a cost of 0, its funds are held, it is listed under Open orders and it can be cancelled. A second order is then refused while the first one holds the balance.
• Fixed how a filled XT order is credited. The platform has always read XT's executedQty as the amount SPENT on a buy and divided it by the average price to get the coin bought. XT's documentation calls it the "executed quantity", and nothing says which it is on a limit buy; read the wrong way round, a filled limit buy credits about 1/price of what was bought. XT states what traded on every order as tradeBase ("transaction quantity") and tradeQuote ("transaction amount"); those cannot be read two ways, so an order is now booked from them: a finished fill is the base that traded and the quote it cost, an order still open or cancelled part-filled keeps the total it was placed for (the fee and the settlements prorate by filled over total), and the order's filled is the base traded. An XT order that does not state them is read the old way, and the backend log says so, with the figures it used.
• Fixed a market order that XT kills without trading (fill-or-kill, when the book cannot fill all of it): it is stored EXPIRED with the amount and price that were asked for, instead of as an order the platform could not record.
• Changed a market order on XT whose first read still says it is new: it is read again, up to five times over about four seconds, before it is booked, so it is not held as if it were resting on the book.
• Fixed the Convert exchange hedge and the pool-backing conversions on XT. Both buy a base-currency SIZE with a market order, and XT's market buy is a spend, so on XT both were refused. The hedge's booking refuses a fill larger than the amount it ordered, and a conversion that comes back short of what it must acquire is parked for a person, so a spend would not have done either. On XT they now buy the size as an immediate-or-cancel limit order under a ceiling: the hedge's ceiling is the mid plus convertHedgeMaxSlippageBps (the limit its booking already holds a fill to), the conversion's is the ask plus the slippage a sell is already allowed (1%). Both read the fill from the trade XT states. Binance, KuCoin and every sell are unchanged.

Orders placed on XT before this update are still on XT with no row in the platform. Each one has a [CRITICAL] UNRECORDED VENUE ORDER line in the backend log with XT's order id. Nothing was debited from the customer for them, so cancel each on XT's own site. See Troubleshooting in the XT provider guide.

My Wallets turned into a table of transactions, and a filter reverted

Every data table in the browser, on the customer pages and in the admin, shared one store, and a request wrote its answer into it whenever it happened to land. The guard could not see a stale answer: it dropped a newer question while an older one was in flight (a filter set during a slow first load was never sent), and a reset let the next table ask while the old answer was still on its way.

• Fixed the shared table. A reset, an unmounting table and any newer different question now retire the request in flight: its answer is thrown away, it does not clear the loading state of the request that replaced it or blank the rows with its failure, and the request is aborted. Two calls for the same question are still one request.
• Fixed a filter set during a slow first load being dropped: it is sent.
• Fixed a table resetting and asking again whenever its page re-rendered. The wallet pages build the table's settings anew on every render, and any re-render (a store ticked, a request landed) reset the table and refetched it; on a wallet's page and Transactions History each refetch counted a bot's whole history. The table now resets when its question changes, not when the page repeats it, and a changed title or an inline button no longer resets it.
• Fixed a wallet's page asking for its Transactions before the wallet had answered, which asked for every transaction of the customer, counted and sorted. The table is mounted once the wallet is known.
• Fixed My Wallets swapping itself for a full-page spinner whenever a refresh ran, which unmounted the table under the customer. The spinner is for the first read only.

Deposit notifications that did not arrive

A tester reported that deposit notifications sometimes did not arrive with their sound and popup although the balance figures were right, that a balance sometimes did not update until the token's wallet page was opened, and once that everything came about thirty minutes late (SOL). On this side of the connection:

• Fixed the notification connection giving up for good after ten attempts five seconds apart, which left a page that looked normal and heard nothing after a backend restart, a laptop that slept or a minute without network. It now keeps trying, backing off from five seconds to a minute, and tries at once when the tab becomes visible, or when the browser comes back online while it is visible. After a reconnection the page reads its notifications again: a new unread one rings, and one about money also refreshes the balances.
• Fixed the sound being skipped until the first click on the page, and a clip that stalled (a throttled background tab never reports that it ended) silencing every later notification until the page was reloaded. The sound is tried before the first click, and the "playing" state resets after five seconds whatever happens to the clip.

The server side of the same reports is in Ecosystem v6.6.1.

The Pro trade panel: Trades behind History, and Open 4 over one row

A tester reported a fill appearing in History at once and in Trades late, or not at all until the page was reloaded, and a tab saying "Open 4", Cancel All (4) and "3 new" beside History over a list of one order.

• Fixed Trades. The panel built Trades from a snapshot alone, while History is read off the orders a live update merges, so History moved first. Trades are now derived from the orders, one row per fill, so the two agree at once. A snapshot read before the engine had written a fill also used to undo the live update: an order that had just filled went back to Open, or fell out of History and Trades, until something caused another read. A snapshot no longer takes back what a live update said: a finished or further-filled order keeps that, and a finished order the snapshot does not list yet is kept for up to a minute. A successful snapshot still drops an open order it does not list.
• Fixed the Open tab. Rows under the pointer are held still so a bot's re-quotes do not move them, and the rows that arrived meanwhile were kept behind an "N new" pill while the tab's count read live state. They are now added below the held rows in the order they arrived, so every order the tab counts is in the list, and the pill is gone.
• The standard (non-Pro) trade panel is unchanged: the reports came from the Pro layout.

A market order's row says what it did, in History and in Open orders

An Ecosystem tester reported two market buys that read BUY MARKET, CANCELLED, filled 0.000000, at 595.67 USDC in the order history, and asked whether that was expected protection and where the reason could be read. The rows were misleading whatever the engine had done. A market order's stored price is the cap its hold was sized from (for a buy, the deepest ask its sweep reached) and its stored cost is that hold; the rows printed them as the Price and the Total, so an order that bought nothing read as a trade at the cap, and nothing on the row said why it ended.

• Fixed the price and total of an Ecosystem market order in the Pro terminal's History and Open tabs and in the standard trade page's Open Orders and History tables. The Price is the volume-weighted average of its fills (labelled Avg price where the layout has room), and the Total is what they cost; an order that executed nothing shows Market and a dash. An older row whose fills were not kept falls back to the order's own average, then to its price.
• Added the reason, as one sentence under the order, when an Ecosystem market order ended cancelled or expired with something unfilled: nothing filled (nothing was on offer within its price limit by the time the order reached the book; a market order takes what is on offer at that moment and cancels the rest), or the part that did. A market sell names no limit, because its stored price is only the best bid it saw.
• Limit and stop orders, exchange (non-Ecosystem) orders and futures orders are unchanged, and so is an order that is still open or filled in full. The words are English, like the row's other labels (Trigger, Amount, Total, Filled).

Why that order was cancelled is Ecosystem v6.6.1: the matching walk had passed over the cheap ask it could have taken, because the market maker's own bid crossed its own ask.

The admin dashboard answered 502 for days, and a table that failed said nothing about why

An operator reported the admin dashboard "loading for ever" and then "Could not load analytics — Invalid response format". The web server's log shows why: every analytics request from the reporting session since October 25 was a 502. The page asked for seventeen figures at once and answered when the slowest finished. One of them, the mix of the last 28 days' completed transactions by type, groups 2.5 million ledger rows on siryx behind a 128 MB database cache, and ran for more than 175 seconds against the web server's 150-second limit. Each request also left its seventeen queries running after the web server had hung up, on the pool that wallet writes and market makers share, so every press of Retry made it worse. The 502 is an HTML page, which is why the screen could only say "Invalid response format".

• Fixed the analytics endpoint. Each figure is now remembered (a minute for the cheap ones, fifteen for the two that read the whole ledger), shared (one computation per figure however many requests ask) and bounded (three queries at a time across the whole backend, not seventeen per request). A request waits at most eight seconds for a figure it has no answer for, then answers without it and names it in a new pending list; the computation carries on behind the answer and the next request is served from memory. A figure that fails is left alone for thirty seconds before it is tried again and is logged once.
• Fixed the 28-day transaction mix itself: the same counts, read from the index that holds the type, status and date (6 seconds on siryx instead of more than 175), with the soft-deleted rows, which that index cannot see, taken off afterwards. A database without that index (an older schema) gets the plain query it always had.
• Fixed the page. A tile or chart whose figure is still being calculated shows as loading, never as a zero, and the page says which in one line under the tiles; it asks again every ten seconds for five minutes and then says the figure is not ready and leaves the refresh button to the operator.
• Fixed the message. When the web server in front of the backend gives up (502, 503, 504, or 429), the request now says so ("The server did not answer in time (HTTP 502). Try again in a moment.") instead of "Invalid response format". A request answered with our own JSON keeps its own message.
• Fixed every data table's error card, which read "There was a problem fetching the data" whatever had failed: the server's own words now appear under that line, small and shortened to 240 characters.
• Added DASHBOARD_FIGURE_WAIT_MS, DASHBOARD_QUERY_CONCURRENCY, DASHBOARD_FIGURE_FRESH_MS, DASHBOARD_SLOW_FIGURE_FRESH_MS and DASHBOARD_FIGURE_RETRY_MS; the defaults need nothing. See the environment reference.

The Ecosystem Orders list had the same kind of failure for a different reason: Ecosystem v6.6.1.

A phone's Orders tab showed no Ecosystem orders

The standard trade page's Orders tab on a phone asked the exchange's order route for the orders of an Ecosystem market, which has none (an Ecosystem order lives in the Ecosystem's own table), so an Ecosystem trader saw an empty list and could not cancel a resting order from the phone. The desktop layout already told the panel it was on an Ecosystem market; the phone layout did not.

• Fixed the phone layout to give the Orders tab the same two facts as the desktop layout: that the market is an Ecosystem market, and the market's quote asset (an exchange order list is scoped by it). The panel starts afresh when the same symbol is opened on the other kind of market.
• The Pro mobile terminal is unchanged: its Orders panel already knew its market type.

Dragging the order-size slider on a phone moved the page

A tester on a Pixel with Firefox reported that dragging the percentage slider of the order form moved the whole page, and that releasing it reloaded the page.

• Fixed the Pro mobile terminal. A drag that starts on the order-size slider, the leverage slider or an input belongs to that control: it no longer starts the swipe between the terminal's tabs, and the slider no longer scrolls the page under the finger.
• Fixed the pull-down reload. The terminal turns off the browser's pull-to-refresh and scroll chaining while it is open, and its scrolling pages contain their own overscroll, so the end of a drag cannot reload the page.

Checked in the component tests (a touch that starts on the slider is the slider's, and the page-level settings are applied and removed with the terminal); not on a physical device.

An Insights article no longer carries the colours of the page it was pasted from

A tester reported the font, text colour and background of Insights looking wrong in the light theme. An article's HTML is stored as written, and one pasted from a dark page or a document arrives with that source's colours, backgrounds and fonts in inline styles, which beat the site's theme: pale text on a white page, or a dark block in a light one.

• Fixed the article page. As it renders, the page removes the colours, backgrounds, font family, font size and CSS variables an article carries inline, so the text takes the theme's ink and the page's background in the light and the dark theme alike. Layout (widths, spacing, alignment, weight) is kept. Articles already published are fixed without being edited.
• Fixed the editor in the same way: pasted content loses those properties on the way in, so it is no longer stored, and the preview renders as the page does.
• The page builder is unchanged: a builder block keeps the colours it was designed with.