Core v6.6.7

Release Date: August 16, 2026 Tags: KYC, COMPLIANCE, DATA-INTEGRITY, P2P, SUPPORT, PRIVACY, WEBSOCKETS, TRADING, BUG-FIXES

Overview

Two unrelated repairs. Saving a verification level quietly rewrote parts of it, and one of them was the country list: any value reading as a yes-or-no word — no, yes, on, off, 0, 1 — was stored as true/false instead of the text you typed. Norway's code is no, so on most installs the country question has held a broken Norway option since the day the level was saved, and applicants could not get past it. Repairing levels you have already saved is a manual job, described in the Upgrade Notes.

The second is peer-to-peer chat. Your support staff could not see a trade's conversation at all — the case screen said "Live" and received nothing — and a trader whose browser cannot hold a live connection never received a single reply.

Internal notes your staff wrote on a trade were also being transmitted to both traders. No screen displayed them, so this is not something a customer would have noticed, but it is worth knowing what was on the wire before you assume nobody read it. That is in the Upgrade Notes too.

Update Instructions

pnpm updator

Restart the backend afterwards. No database change and no script to run — but read the Upgrade Notes and check your verification levels.

Upgrade Notes

Check every KYC level you have saved, and repair its country list

Levels saved before this release keep whatever was written to them, and saving one again does not repair it — the broken value is no longer text, so the conversion that damaged it has nothing left to act on.

Open each level under Compliance & Verification → Verification Levels and look at every question that offers a list of choices. The one to check first is the country question: press Load Countries to replace the list with a fresh one. For any other choice list, open each option and retype its value; typing it back in stores it as text again, and from this release it stays that way.

The values worth hunting are the ones that read as yes-or-no words. On a country list that is Norway (no) alone. On a hand-written yes/no question it is both options, which is why a required question of that kind blocked the whole level.

There is no repair script, and that is deliberate rather than an omission: the conversion collapsed four different pieces of text onto each true/false value, so nothing in the database records which one you originally wrote. A script could only guess, and a guess in a compliance record is worse than a value an operator corrects by hand.

• Open each verification level and repair any choice whose value reads as a yes-or-no word.
• Press Load Countries on the country question to restore the full list.
• Fixed verification levels having their text rewritten when saved.

Applicants refused for answering "no"

The same rewrite ran over submitted answers, so a free-text field answered no, yes, on, off, 0 or 1 arrived as a true/false value and was refused with "must be text". A customer who answered a question truthfully with one word was turned away with a message that made no sense to them, and repeating the answer could not help.

If you have applicants stuck in a rejected or incomplete state, they can now resubmit and their answers will be accepted. Nothing needs to be reset for them.

• Fixed free-text verification answers of one yes-or-no word being refused.

Your staff's internal notes on a trade were sent to both traders

A P2P trade keeps one record holding its status history, the chat between the two traders, and the internal notes your staff write on it. The trade room's opening payload has always removed the internal notes before sending it to a trader. The messages sent afterwards, when the trade changed state, did not — they carried the whole record.

So from the moment an operator wrote an internal note on a trade, every later change to that trade sent that note to both the buyer and the seller: the text, and the name and account id of the operator who wrote it. The changes that did it are the ordinary ones — a buyer marking payment sent, a seller releasing funds, an operator cancelling or resolving the trade, and the automatic cancel and dispute sweeps. A resolved dispute additionally sent the account id of the operator who ruled on it.

Nothing on the customer's screen displayed any of it. There is no screen in the trade room that draws that record, so a trader would have had to open their own browser's developer tools and read the raw connection to see it. That is what makes this worth stating plainly rather than filing quietly: it is not a leak anybody would have reported to you, so the absence of complaints is not evidence it went unread.

From this release the internal notes and the operator's identity are removed before the message leaves the server, on every path, for every trader. Your staff's own case screen is unaffected — it reads the full record through its own door.

• If your staff have written anything in an internal note that you would not want the two traders to read, treat it as having been readable by them on any trade that changed state after the note was written.
• Fixed internal operator notes and the deciding operator's identity being sent to both traders on every trade status change.

Fixed

Identity verification

• Fixed the verification screen in the mobile app failing to open at all, with a developer error message in place of the page, on any install whose country question carried the broken Norway option.
• Fixed a malformed request to the verification endpoints returning a server error containing internal detail, instead of a plain refusal.

P2P support and the trade chat

Support could not follow a trade at all. Opening a case showed the conversation as it stood at that second and then never moved again — no new messages, no status changes — while the screen's own indicator said Live, because the connection was open and it was the subscription to the trade that had been refused. The refusal hit the Super Admin account specifically: Super Admin carries no individual permissions, since it bypasses permission checks entirely, and this one check asked for the permissions rather than the role. On most installs that is the account support actually uses.

The second repair is for traders. When a browser cannot hold a live connection to your server, the room says Delayed and falls back to polling — but the polling refreshed the trade and never the conversation, so the chat was one-way: a trader saw their own messages appear and no reply ever arrived, until they reloaded the page. It now refreshes the conversation every fifteen seconds as well. If your traders see Delayed at all, the usual cause is a reverse proxy in front of the API that is not forwarding WebSocket upgrades; fixing that restores instant delivery, and the chat works either way in the meantime.

• Fixed support seeing no messages, no status changes and no live transcript on a trade, while the case screen reported itself as live.
• Fixed support being unable to open a receipt or screenshot a trader had attached to the conversation as evidence.
• Fixed the trade chat never showing the other trader's replies when the browser could not hold a live connection, until the page was reloaded.
• Fixed a trade that the platform automatically disputes — hours after payment was marked sent, when the seller has not released — leaving both traders looking at a room that still said funds were on their way. On installs that run the scheduler as its own process, that change never reached either screen at all.

The Pro trading terminal

On a screen that is wide but not tall — most laptops, and any ultrawide monitor — the buy/sell ticket did not fit the space it was given, and what it dropped was the bottom of itself: the estimated fee and the total cost. Those two figures sat at the end of a region that scrolled, so the fee line was sliced through the middle and the total was pushed off the panel entirely, while the Buy button underneath stayed where it was and stayed enabled. An order could be placed without its cost ever having been on screen.

None of the numbers were wrong and nothing was hidden on purpose — the panel was short by about the height of one row. That is why resizing the window a little made the missing figures come back, and why it read as the display glitching rather than as the ticket running out of room.

The cause was the orders table along the bottom of the terminal. Its height was chosen from the width of the window, so the wider the screen the more height it claimed, and it took that height from the row holding the chart, the order book and the ticket. A wide, short window therefore gave the most space to the table and the least to the ticket, which is the worst arrangement of the two.

The cost summary and the Buy/Sell button are now fixed to the bottom of the ticket and no longer scroll: on a short panel it is the input fields above them that give up room, and those scroll back into view. The orders table now reads the height of the window rather than its width, so it no longer takes that room on a short screen. It keeps its own scrolling, so it shows fewer rows there, not fewer orders.

• Fixed the estimated fee and the total cost being cut in half or missing entirely from the trading ticket on screens that are wide but not tall.
• Changed the cost summary and the order button to hold their place at the bottom of the ticket instead of scrolling away with the form.
• Changed the orders table at the bottom of the terminal to take its height from the height of the window instead of its width, so it stops crowding the ticket on a short screen.