Copy Trading v6.2.0

Release Date: August 11, 2026 Tags: FOLLOWERS, LEADERS, PROFIT SHARE, ALLOCATIONS, FEES, WALLETS, ORDERS, AFFILIATE, ADMIN, RELIABILITY, PERFORMANCE, DATABASE, INDEXES, STATISTICS, DASHBOARDS, BUG-FIXES

Overview

This began as a reliability and performance release and became a money release. A leader advertising a 0% profit share had twenty percent taken from every follower's profit anyway; a platform fee turned down to zero still collected two percent; and an exit that filled in more than one piece was settled on the first piece alone.

From this release forward it also opens the paths money could not get out of — a winning follower's realised profit, an allocation an administrator force-stops, the funds behind a copy order that could never fill. The performance pass this release started life as is still in it: the same numbers, computed in a fraction of the queries.

Nothing here corrects records already written, and money already stranded stays where it is until you move it. Read Upgrade Notes first; several items need you to go and look at what you already hold.

Requires Core v6.6.3.

Update Instructions

pnpm updator

No setting changes. Two indexes are built the first time the backend starts after updating, and several items below need you to inspect existing records — see Upgrade Notes.

Upgrade Notes

Followers of a leader charging 0% were charged 20%, and you should reimburse them

Until this release, a profit share of exactly zero was read as "not configured" and replaced with twenty percent, at every point a follower's profit is divided. The money genuinely moved from the follower to the leader.

• Look for leaders whose profit share is 0, and for the profit-share payouts recorded against their followers' closed trades. Every one of those payouts was taken at 20% of the profit remaining after the platform fee. Nothing in this update reverses them.

A platform fee of zero collected two percent into your own revenue

The same defect in the operator's own setting. An installation with copyTradingPlatformFeePercent set to 0 still took two percent of every profitable copy and credited it to platform profit.

• If you deliberately run a zero platform fee, the copy-trading platform-fee rows in your revenue are money you told the system not to take. Decide what to do with them before your next reconciliation.

Followers an administrator force-stopped still hold funds you must return by hand

The admin force-stop wrote the subscription to stopped and left every allocated balance in the follower's copy-trading wallet, which has no withdrawal path and no transfer path out. From this release the route returns those balances first — but it refuses a subscription that is already stopped, so it cannot repair the ones that came before it.

• List followers whose subscription is stopped and whose allocations still carry a non-zero balance. Their funds are in the copy-trading wallet and need to be moved back by hand.

Spot allocations settled before this update no longer agree with the wallet behind them

Every settled spot copy credited or debited the shared copy-trading wallet without moving the figure the refund routes read, so the two drifted apart in both directions: a follower who won had winnings the platform would not give back, and a follower who lost had a claim larger than the wallet, which made their attempt to stop following fail outright. Settlements from this release forward keep the two in step; earlier ones are still apart.

• A follower who reports that stopping fails, or that a profit never arrived, is this. Compare the allocation balances against the copy-trading wallet before you conclude anything else is wrong.

Positions closed on a partially filled exit were recorded at the wrong price

A market exit that filled in more than one piece was settled on the first piece alone — realised profit, the leader's share and the platform fee all computed from a fraction of the trade, and the remaining proceeds recorded nowhere.

• Closed copy trades whose exit crossed several price levels carry a realised result that is not what the position actually made, and the profit share paid on them was sized from it. This update does not restate them.

Affiliate rewards for copy-trading follows were sized on a meaningless number

The reward paid to a referrer when someone followed a leader added the two sides of every allocation together — different currencies — and handed the total over labelled as US dollars. On a low-priced base asset that inflated the referrer's reward enormously; on a high-priced one it fell under the minimum and paid nothing.

• Check referral rewards recorded against copy-trading subscriptions. Percentage-based conditions are where this did the most damage.

Copy orders may still be resting in the book from before this update

A follower who allocated only the quote side of a market had no wallet for the currency a purchase pays into, so their copy order was created, funded and placed, crossed a real quote, and could never settle. It rests in the public book with its cost and fee locked away.

• Cancelling such an order releases the cost and the fee it holds back into the follower's copy-trading balance, and nothing else recovers them. New copies place correctly.

The first start after updating builds two indexes on your trade history

Two indexes are added over the copy-trading trade history, one for each of the background checks below: a leader's trades by date, and a follower's closed trades by date. The schema sync creates them when the backend starts.

• On an installation with a long trade history, that first start takes longer than usual. It is one-off work, it does not repeat on later restarts, and nothing is wrong — let it finish rather than restarting into it again.

Changed

A leader can no longer raise their profit share while copied positions are open

The rate is read at the moment a position closes and is never recorded on the trade, so whatever the leader had set by then applied to the whole gain. A leader could advertise nothing, gather followers, let a copied position run thousands into profit, raise the share to the maximum and close — taking half of a gain earned entirely under the advertised rate. It is the headline term on the market page and in the follow dialog.

• Changed a profit-share increase to be refused while the leader has copied positions open, with a message naming the current rate, the requested one and how many positions are in the way. A cut is unconditional, at any time — it can only ever be in the follower's favour.

Public figures that add up several currencies no longer wear a dollar sign

The landing page's headline volume, and the total profit on the featured leader card, are sums over trades that each settled in whatever asset their market was quoted in. Adding those together produces a number, but not a number of dollars — and it was printed publicly with a $ in front of it.

• Changed both to print the magnitude without a currency mark. The figures themselves are unchanged.
• Changed the landing page's abbreviations to show a dash rather than a figure when the value is not a number at all.

The two background checks that run on their own

Both of these ran a query per row: one per active follower every sixty seconds, one per active leader every five minutes. On a busy installation that is the dominant database load of the whole add-on, and none of it is in front of a customer.

• Changed the daily loss-limit check to read the day's losing trades for every active follower in one pass, rather than one query per follower. The same followers are paused for the same losses.
• Changed the leader statistics update the same way, and to ask for an exchange rate once per currency per run instead of once per trade — so a rate that moves mid-run no longer prices one leader's day at two different prices. It also reads only the leader identifiers it actually uses rather than each leader's whole record.
• Changed the trade history to carry an index for each of those two reads. Without them, finding one day of trades meant scanning that leader's or that follower's entire history.
• Changed the replication fan-out to stop loading each follower's account record alongside the follower. Nothing in that path ever read it.
• Changed the leader tick to fall back to the per-leader queries it used before if that batched read fails, rather than abandoning the run.

A follower's own statistics

• Changed follower statistics — trade count, win rate and profit — to be counted and totalled in the database instead of by loading every closed trade the follower has ever made. A follower with a long history loaded every one of those rows to produce a handful of numbers; the result is now one row per currency and market they have traded in. The numbers themselves are unchanged, including how a denomination with no realised movement is treated.

The admin copy-trading overview

• Changed the seven-day trade chart and the four sparklines above it from forty-nine queries to five. Each day of each line was its own query over the same week of rows, with only the cut-off moving. Every point keeps the day boundaries and the labels it had before.

Fixed

A leader who charges nothing had twenty percent taken from their followers anyway

A profit share of zero is a rate a leader is entitled to choose, and the market page and follow dialog advertise it as one. Every place that divided a follower's profit treated it as an unset value and substituted twenty percent instead — the share calculation, the settlement tick and the binary copy path, which between them are every route a follower's profit can take, and the preview that quotes a share back before it is charged.

• Fixed a 0% leader taking nothing, so a follower keeps their whole profit less the platform fee. Money already taken at 20% from followers of a 0% leader is not returned by this update — see Upgrade Notes.

A platform fee set to zero still collected two percent

The admin control for the platform fee accepts zero, and a stored zero reached the calculation intact — where it was read as an absent setting and replaced with the two percent default. This was never only a display problem: the fee was debited from the follower's profit and credited to platform revenue.

• Fixed a platform fee of zero taking nothing.

The follow dialog quoted a platform fee that was not yours

The rate shown to a follower in the last screen before they commit was the literal text 2%, regardless of what the setting held, so an operator running five percent showed every follower two.

• Fixed the quoted platform fee to come from your setting.
• Changed the leader's share on the same panel to be labelled as a share of what remains. The two charges compound — the platform fee comes off the gross first, the leader's share off the rest — and presenting them as a flat pair invited a follower to subtract both from the gross and expect less than they get.

A leader's own dashboard reported zero across the board

The leader profile screen read its scoreboard from a nested block the endpoint has never sent, so every number it pulled out was missing and every missing number rendered as zero — and because those zeros were written after the correct values, they overwrote them. A leader saw 0% return, no followers and no trades on their own dashboard while the public leaderboard showed the same figures correctly. Return was also being taken from total profit, which is an amount of money, and printed with a percent sign after it.

• Fixed the dashboard reading the figures the endpoint actually sends, and reading return from return rather than from profit.
• Fixed the same screen re-zeroing itself after every profile edit — the transform existed twice, and the copy that runs after an edit was as wrong as the one that runs on first load, so repairing either alone was not a repair.

A quote-only allocation placed copy orders that could never fill

Allocating only the quote side of a market — the ordinary way to copy a leader's buys, and what following writes when no base amount is given — created a copy-trading wallet for the quote currency and none for the base. The order was created, funded and placed, it crossed a genuine resting quote on price, and then settlement could not find the wallet the purchase pays into. The matching engine treats that as permanent and passes the order over on every cycle, so it rested in the public book indefinitely with its cost and fee locked away, recoverable only by cancelling it. Nothing recorded it as a copy-trading fault.

• Fixed placement to create the wallet the fill pays into before the order exists, for both directions — a purchase receives the base currency, a sale receives the quote.

The first piece of a split exit settled the whole position

An exit that filled in several pieces was settled on the first one. The matching engine sends one message per fill carrying that fill's own increment, and the position was closed the moment the first arrived: realised profit was computed from a fraction of the size at a price the rest of the trade never got, the whole reservation was released, the leader was paid a share of that figure, and every later fill was turned away because the trade was already closed. A one-unit position bought at 60,000 and exited 0.2 at 61,000 then 0.8 at 59,000 booked a +200 profit on a trade that lost 600.

• Fixed settlement to fold every fill of an exit order together and record the position once it is done, at the quantity-weighted average price and the full exited quantity.
• Fixed a cancelled exit order being silently ignored; it is now logged as a position still open and still needing an exit.

A winning follower's profit had no way out, and a losing follower could not stop

What a follower may take back is a claim on a wallet they share with their other allocations, and every refund route reads it and only it. The binary side of the add-on kept it honest; the spot side released the reservation and recorded no result at all. So a follower who won had their profit sitting in a copy-trading wallet with no withdrawal route and no transfer out, and a follower who lost had a claim larger than the wallet — which made the transfer fail and rolled their whole attempt to stop following back, leaving them unable to leave.

• Fixed each settled spot copy to move the follower's claim by what they actually realised, net of the leader's share and the platform fee — the same figure the product already charges on. Nothing is moved by this; the proceeds are already in the wallet.
• Fixed the claim being stored at more precision than the database can report back. Until now that figure only ever held round amounts a customer had typed; a realised profit puts a long fraction in it, and roughly half of those read back higher than the money they stand for — enough to make stopping fail on a rounding step. It is written rounded down, so the error always falls short rather than over. On a claim near a million that costs about ten units, and the honest repair for that is a wider number type rather than more arithmetic.
• Fixed a partly failed distribution being read as "nothing was charged". Where the leader's transfer had already landed, that miscount made the follower's claim exceed the wallet by exactly the leader's share and wedged their stop. A failed distribution now charges nothing and records that the follower may be short by that amount and needs settling by hand.

Adding funds twice, or removing them twice

Both routes derived their transfer's uniqueness token from the content of the request and nothing else, and those tokens are permanent. Adding funds included the amount, so a second top-up of the same size — 500 on Monday, 500 on Friday — rebuilt Monday's token, moved no money, and answered "Successfully added 500". The money was still in the source wallet. Removing funds did not include the amount at all, so the first withdrawal from an allocation burned the only token it would ever have and every later one, any amount, any day, failed with an error and moved nothing. An allocation was a one-way door.

• Fixed both to scope the token to the request, so two deliberate moves of the same size are two moves. Both accept an idempotency-key request header and will report a genuine retry as already applied rather than pretending a second move landed.
• Changed removing funds to lock the allocation and re-check the balance inside the transaction, and to floor the deduction at zero. The old permanent token had been the only thing serialising two simultaneous withdrawals; making it per-request would otherwise have let a double submission pass both balance checks, drive one allocation negative and spend a sibling allocation's budget out of the shared wallet. A request that arrives second is now refused with what the allocation actually holds.

Stopping a follower from the admin panel left their money behind

The route wrote the subscription to stopped and did nothing else — a comment in its place said the funds would be returned when the allocations were removed, and no route removes them. A follower with ten thousand allocated and no open orders was force-stopped for a policy review and their ten thousand stayed in the copy-trading wallet, which has no withdrawal route and no transfer out. Their own stop route then answers that the subscription is already stopped, and adding or removing funds both refuse a stopped subscription. The money was unreachable from every surface the platform has.

• Fixed the admin force-stop to cancel the live copy orders, return every allocation balance to the wallet it was funded from, and only then mark the subscription stopped — the same sequence the follower's own stop already used. The reply and the audit entry both list what was returned.
• Fixed it silently stopping a follower who still holds filled positions. Unwinding those needs a real exit that settles on a fill, which cannot finish inside the request, so the stop is now refused and names the markets involved. Pause the subscription to halt new copies and stop it once those positions have closed.

The affiliate reward for a new subscription was sized on a number that meant nothing

When a referred customer followed a leader, the reward paid to their referrer was sized by adding the base and quote sides of every allocation together and passing the total to the affiliate engine labelled as US dollars. They are different currencies. Following on a low-priced pair with five million of the base asset — around fifty dollars — declared an allocation of five million dollars, and a five percent condition minted a reward of two hundred and fifty thousand. The mirror case underpaid just as badly: half a bitcoin declared as 0.5, below the fifty-dollar minimum, paid the referrer nothing.

• Fixed each side of an allocation to be priced in its own currency before the total is taken. A price that cannot be looked up now skips the reward rather than paying one out against an indefensible figure.

A leader's first profit-share statement opened at a balance that wallet never held

The payout looked the leader's spot wallet up through a helper that, when there was no such wallet, quietly answered with an ecosystem wallet instead — and created one as a side effect of being asked. The payment itself was always correct, because the transfer routes on the wallet types it is given. The record was not: the ledger entry for a leader's first payout was stamped with an opening and closing balance taken from a different wallet, and every later entry read against a running balance inherited the discrepancy. A leader who trades the ecosystem and holds no spot balance is exactly the shape that made it look deliberate.

• Fixed the payout to resolve the leader's spot wallet as a spot wallet, so the statement opens at the balance that was actually credited and no stray wallet is created.

Pausing, resuming or stopping a follower explained nothing when it refused

Each of those three actions checks the follower's state before it does anything, and refuses with a reason when the state is wrong. The reason never arrived. The check cleaned up after itself and then raised its refusal; the error handler that received it cleaned up a second time, which fails, and that failure is what was reported — before the handler had even looked at the refusal it was holding.

So an operator was told a transaction had a state, on a control that had refused them for an ordinary and correctable reason, and the message is identical whichever reason it was.

• Fixed all three reporting their own refusal.

Following a leader, or applying to become one, could succeed and report failure

Both of these save their record and then keep working — updating a leader's figures, re-reading the result, sending the notifications. A stumble anywhere in that later work ran a cleanup step against a record that had already been saved. That step fails on its own, and its failure — an internal server error naming a transaction state — is what reached the customer, on work that had in fact completed.

• Fixed following a leader and applying as a leader reporting an internal error after the record had been written. Nothing refuses a second subscription to the same leader, so a follower who took that error at its word and tried again could end up following twice, with a second set of allocations funded out of their wallet.
• Fixed profit-share distribution, the fill monitor and the background job reporting a transaction state in their error logs instead of the real cause. Where the work had already committed, a completed run was logged as a failure — which is what an operator reads when deciding whether the last distribution ran.