Core v6.8.3

Release Date: October 1, 2026 Tags: SECURITY, PAYMENTS, ACCOUNTS, WALLETS, TRADING, ADMIN, MOBILE

Overview

A money and security release. Update promptly, and read Upgrade Notes first. It closes a dLocal payment confirmation that could credit a large unpaid deposit from a small paid payment, which 6.8.2 did not fix, and a dLocal status check that returned any payment's record to any signed-in customer. A spot order the exchange accepted is no longer lost when recording it fails. Wallet operations no longer fail because their audit row could not be written, a fault the last 6.8.2 build introduced.

It also adds money restrictions: an admin can stop withdrawals, transfers or both on one account without blocking it. A restricted account is not a blocked one; Upgrade Notes lists what it can still do.

One new table is created at first start. If you have used dLocal, there are past deposits to review.

Update Instructions

pnpm updator

This release adds one table. pnpm updator starts the backend once before seeding, and that start creates it. Nothing is dropped, renamed or rewritten, and there is no separate migration command.

Published with this release, each with its own notes: Ecosystem v6.5.7, Copy Trading v6.2.8, ICO/STO/IDO v6.3.2, Staking v6.2.8, E-commerce v6.2.4, Forex Investment v6.2.4 and Instant Convert v6.0.2. All seven need this release. Update Core first, then the add-ons in the same window.

Upgrade Notes

If you have used dLocal: review past deposits

Until this release a customer could open a large dLocal deposit, leave it unpaid, pay a small one, and confirm the large deposit with the small payment. The wallet was credited the large amount, in the small payment's currency. An install is exposed only if dLocal's credentials are set and the dLocal gateway is switched on. This release closes the route; it does not find or reverse deposits credited that way.

• Look for one dLocal payment id recorded on two deposits of the same customer. In an abused pair both deposits show completed, only one credit exists, and its amount is the larger deposit's.
• For any pair you find, compare the amount credited with what dLocal collected, in dLocal's own dashboard.

A restricted account is not a blocked account

The new switches stop withdrawals and the Transfer screen. They do not stop every way a balance can leave a wallet.

• The two switches are independent. Withdrawals disabled alone leaves the customer free to transfer to another user; Transfers disabled alone leaves them free to withdraw. Holding an account's money needs both. The Frozen badge appears as soon as either is on.
• Transfers disabled also refuses moves between the customer's own wallets on the Transfer screen. Funding a copy-trading allocation, a forex account or a stake is not a transfer and stays open.
• With both switches on, a customer can still sell on P2P and release the escrow, pay a payment-gateway merchant, make an NFT offer, buy a trading-bot strategy, contribute to an ICO, fund a copy-trading allocation, and spend on store purchases, forex deposits, staking, investment plans and binary options. Trading stays open by design.
• Payouts already handed to the exchange, to TransFi or to the chain are not recalled.
• The customer is not notified. They learn of it when a request is refused, in English, whatever their language.
• Ecosystem withdrawals and transfers and Instant Convert's Convert & Send obey the switches only once Ecosystem v6.5.7 and Instant Convert v6.0.2 are installed. Until then they stay open and nothing warns you.
• Any role that can edit users can set and lift a restriction. Review who holds that permission.
• To stop one balance moving at all, disable that wallet, as before. That also stops deposits into it.

One new table at first start

• user_account_restriction is created by the backend's start-up schema sync. It starts empty; no account is restricted until you restrict it.
• If .env sets DB_SYNC="none", the table is not created. The card reads "Money restrictions are not available until the backend restarts and creates its table", cannot be saved, and no account is restricted. A plain restart does not help there: start the backend once without DB_SYNC="none", or create the table yourself.

Spot orders: a new message, and log lines that need a person

When the exchange accepts an order and the platform then cannot record it, the order is now saved as an open order waiting to be recorded, and the customer is told "Your order was placed on the exchange, but your balances could not be updated yet. It has been saved and will be completed automatically; do not place it again." The website shows that sentence as a success message; the mobile app reports the order as placed. The spot order job retries the recording every minute.

• While an order waits, the customer's funds are not reserved. They can trade or withdraw them, and nothing stops them placing the order again. Cancelling it answers "This order is still being recorded — try again in a minute".
• Search the log for could not be booked after 30 replays. That order was given up after about half an hour, which is what happens when the funds are no longer there. Your exchange account holds a fill or a live order the customer has not paid for, and nothing settles it until you do.
• Search the log for [CRITICAL] UNRECORDED VENUE ORDER. That order is on the exchange and could not be saved at all; the line carries what is needed to record it by hand.
• If your install has no Super Admin, every order with a trading fee logs [CRITICAL] Dropped platform fee — no Super Admin configured. about thirty times before the fee is given up. Before this release it logged it once.
• This release cannot find orders lost before it: they left no record. If your log shows "Error creating order" lines from before the update, compare the exchange's own order history with your order list.

Wallet audit rows

• After updating, search the log for WALLET_AUDIT_PERSIST_FAILED. A steady stream means the wallet audit table is out of step with the code and audit rows are being lost. Wallet operations themselves now complete.

Added

Money restrictions on one account

Until now the choices were blocking the whole account or disabling its wallets one at a time, which also stops money arriving. See Upgrade Notes for what a restriction does not stop.

• Added a Money restrictions card on the admin user page's Security tab, with two switches, Withdrawals disabled and Transfers disabled, and an internal reason that anyone who can view users can read. The account can still sign in, trade and deposit. A switch applies to the customer's next request.
• Added the refusal a restricted customer gets: "Withdrawals are disabled on your account. Please contact support." on spot and fiat withdrawals, on requesting or entering a withdrawal code, and on selling crypto for fiat through TransFi; "Transfers are disabled on your account. Please contact support." on every transfer and on requesting or entering a transfer code or PIN. No code is sent and no PIN or 2FA attempt is used.
• Added a hold on withdrawals already waiting for approval. Approving one, or marking it completed, is refused with "Withdrawals are disabled on this account. Lift the restriction first." A bulk approval skips those rows, reports them and pays the rest. Rejecting is still allowed and returns the money to the wallet.
• Added a record of every change in the admin audit log: who, which account, what changed, and the reason. The card shows the last change.
• The card is read-only for Super Admin and system accounts, and an admin cannot change the restrictions on their own account.
• There is no list of restricted accounts; the state shows on each user's page. The card's labels are in English in every language for now.

Instant Convert's dashboard labels

• Added the labels for the movement-review row that Instant Convert v6.0.1 added to its dashboard, which showed in English until this release.

Changed

Payment providers

Several return-page confirmation and status routes acted on any of the caller's transactions the request named, not only that gateway's own deposits. No way to gain money through the routes below was found.

• Changed the Mollie and Adyen confirmations to check which deposit a payment was made for and how much was paid, as dLocal's now does. On Mollie a mismatch ended in an error, not a credit, unless the payment came from outside the install; the Adyen route is not known to have completed any payment.
• Changed the Mollie and eWAY status checks to answer only for one of the caller's own deposits at that gateway. Through a manual deposit claim, the Mollie check could be pointed at any Mollie payment whose id the caller knew.
• Changed the Authorize.Net confirmation to touch only Authorize.Net deposits. On any install, a signed-in customer could mark one of their own pending transactions as failed, with the description "Failed Authorize.Net deposit: …". Nothing refunds a transaction because it is marked failed.
• Changed the Paysafe confirmation to compare the amount and currency Paysafe reports with the deposit, and its status check to leave other transactions alone.
• Changed the iPay88 status check to compare the reference, amount and currency of iPay88's answer with the deposit, and its confirmation to compare the currency.
• Changed the Klarna and Paystack routes to read only that gateway's own deposits, and the PayU confirmation to credit only the amount PayU reports.
• The Paystack status check no longer credits anything. Paystack deposits are settled by the return-page confirmation and the webhook, as before.

Database deadlocks during a fee

• Changed an operation whose database transaction is ended by a deadlock while its fee or loss is being recorded to fail at once with the real error. Before, the fee step reported only that the fee had failed and the operation failed a moment later with an unrelated-looking database error. Nothing was committed either way, and nothing retries it.

Spot order recording

• Changed the spot order job to first record any order still waiting to be recorded and collect any trading fee still owed. Every five minutes, and once after each restart, it reads the whole spot order table to find them.

Fixed

dLocal: a small payment could complete a large deposit

The dLocal return-page confirmation settled whichever payment the request named against whichever of the customer's deposits the request named, at the deposit's amount and in the payment's currency. It never checked that the payment was made for that deposit or for that amount. 6.8.2 fixed only rejected and refunded deposits on this route. See Upgrade Notes for the review this calls for.

• Fixed the dLocal confirmation crediting a deposit from a payment made for another one. It now credits only when dLocal's record names that deposit and the amount and currency agree. Otherwise the customer gets "Payment verification failed: dLocal payment does not match this transaction".

dLocal: the status check returned any payment's record

• Fixed the dLocal status check returning dLocal's record of any payment whose id the caller supplied, to any signed-in customer, and looking deposits up by order id without checking the owner. It now answers only for a payment dLocal ties to one of the caller's own deposits. The caller needed to know a payment id, and past reads left no record.

A spot order the exchange accepted could be lost

An order is sent to the exchange first and recorded second. When the recording failed, on a database deadlock or a lost connection, or when a second order from the same account had just used the balance, nothing was saved: the order stood or filled on your exchange account, the customer's balance did not move, no order appeared in their list, and they saw an error and could place it again.

• Fixed a failed recording leaving nothing behind. It is retried up to three times, and if it still fails the order is saved and recorded by the spot order job. See Upgrade Notes for what the customer sees and what to watch.
• Fixed a trading fee the customer had paid being dropped when collecting it failed. It is kept on the order and collected later, once.
• Not fixed: if the exchange accepts an order and the platform's follow-up read of it fails, the customer still gets an error and nothing is recorded.

Wallet operations failed when their audit row could not be written

The last 6.8.2 build made a wallet operation fail whenever the database refused its audit row. That needs a wallet audit table that is missing or older than the code, because schema sync is off or the database was restored or altered by hand. With the table missing, every deposit credit, withdrawal, transfer and order hold failed.

• Fixed the operation failing. Only the audit row is lost now: the operation completes and its ledger entry is written. The audit row is not written later.
• A wallet operation still fails, whole, when the failure ended its database transaction: a deadlock or a lost connection.

Fees and losses that failed part-way

A database error in the middle of collecting a platform fee or recording a platform loss could leave it half-recorded. The customer's own operation was not affected.

• Fixed a fee reaching the platform wallet with no profit entry, so the Profit page under-counted it, and a treasury payment recorded against a loss marked as unfunded. A fee or loss that fails part-way is now undone whole, and the customer's operation still completes.
• A fee undone this way is not collected later. The customer has still paid it, the platform wallet is not credited, and the log carries Failed to collect fee.

Mobile app: no deposit networks on XT

• Fixed the mobile app showing "… is not available for SPOT deposits. Please select a different cryptocurrency." for every coin on an exchange that publishes no deposit minimum, as XT does. The website was not affected. Apps already installed work without a new build.