How leader and follower statistics are computed

There is no stored statistics counter anywhere in this addon. copy_trading_leaders has no totalTrades, no winRate, no totalProfit column; neither does copy_trading_followers. Everything a screen shows is recomputed from copy_trading_trades — the single source of truth — and then held in Redis for a few minutes.

That matters for two questions operators get constantly. "Why does Recalculate change nothing?" — because there is no stored number for it to fix. And "is this leader's headline figure real?" — because it is arithmetic over real rows, but the arithmetic has a denominator and a denomination, and neither is what most people assume.

Which function answers which screen

Closing a trade calls invalidateTradeRelatedCaches, which deletes the leader key, the follower key and the allocation key together. The :v2: and :v3: version markers in the key names are load-bearing — they exist so that a deploy cannot serve an older entry whose shape lacked a currency field.

What each figure actually is

All leader figures are computed over rows where isLeaderTrade = true and status = 'CLOSED'. Follower figures are computed over rows for that followerId with status = 'CLOSED'.

Two of these are routinely misread.

Denomination: profitCurrency is not decoration

A trade settles in the quote asset of its own market, and the row records that in profitCurrency. A leader running BTC/USDT and NEO/ETH has two kinds of money in one column, so the calculator buckets per denomination before it adds anything.

• One denomination — the ordinary case. The total is that currency's bucket, profitCurrency is that ticker, and no rate is fetched at all. This is deliberate: making the common case depend on a populated rate table would replace a correct figure with a zero on an ecosystem-only install.
• More than one — rates are fetched, everything is converted, profitCurrency becomes the literal string USD, and anything with no usable rate is listed in unpricedCurrencies (leaders) or unpricedProfitCurrencies (followers) and left out of the total, making the figure a stated lower bound. A missing rate is never treated as zero.

Totals are rounded to eight decimal places, not two, because rounding a BTC-quoted result to cents destroys it outright.

For a follower, roiAvailable is a separate flag and false means "not known", not "zero". When a denomination cannot be priced, its profit leaves the numerator while its allocation stays in the denominator, so the ratio would read low with nothing on screen saying why. In that case roi is 0 and roiAvailable is false — render a dash.

Where conversion happens, and what happens when it fails

Two places convert, and they behave differently.

The statistics calculator (leaderboard, profiles, subscriptions) uses the platform rate table. A currency with no rate drops out of both the profit and the volume halves together, keeping ROI a ratio over one population, and is reported as unpriced.

The cron jobs (updateCopyTradingLeaderDailyStats, aggregateCopyTradingWeeklyAnalytics, checkCopyTradingDailyLossLimits) use convertToUSDT, which prices through the ecosystem matching engine's ticker with a 60-second Redis cache. When that throws, the handler logs Currency conversion failed for {currency} at warn level and adds the raw, unconverted value instead.

The two statistics cron jobs

Both are in Admin → System → Cron under the copy_trading category.

The daily job upserts on (leaderId, date) with the date key taken from UTC midnight, the same clock the window start uses. It only walks leaders whose status is ACTIVE, and it counts trades created that day.

Two consequences worth planning around:

• A missing day stays missing. The job only ever writes today's row. If the scheduler was down for a day, nothing backfills it — the 14-day sparklines on the landing page simply have a gap, and the row will not appear later.
• A leader who is suspended mid-day stops accruing rows. Their historical rows survive; no new one is written while they are not ACTIVE.

The weekly job's name promises more than it does. In its current form it computes weekly totals, broadcasts them to the cron log, and returns — statistics moved to on-demand computation and this job was not removed. Nothing downstream reads a weekly aggregate, so a failed run costs you a log line.

What Recalculate does

The Recalculate Stats button on the leader detail page /admin/copy-trading/leader/{id} does exactly three things:

1. Reads the current statistics so the response can show you a "before".
2. Re-queries that leader's closed trades and returns the recomputed figures in the response body, along with follower-copy totals, total allocated, max drawdown and average trade duration.
3. Deletes one Redis key — copy:leader:stats:v2:{id}.

It writes nothing to any leader, trade or statistics row.

One caveat on the response itself: the newStats block is computed with bare sums over profit and cost with no currency bucketing, while oldStats comes from the currency-aware calculator. On a single-quote leader the two agree. On a multi-quote leader the changes block is comparing two different kinds of number and should be ignored.

Every recalculation writes a RECALCULATE_STATS audit row against entity type LEADER, with both figure sets and the acting admin.

The historic SELL-copy return defect

profitPercent on a follower copy is the trade's return, and for a SELL copy it was divided by trade.cost — which on a sell row holds the base quantity, not a quote notional. A 1% move on a $60,000 asset therefore rendered as 60,000%.

The close path now divides by entryPrice × amount on the sell side, so every trade closed since is correct.

What the admin dashboard does not get from this path

GET /api/admin/copy-trading computes its money figures itself, server-side, in one grouped pass over copy_trading_follower_allocations joined to the subscription. None of it comes from the cached statistics path, so nothing on the capital meter is ever up to five minutes old — it is as of generatedAt in the response.

That pass produces the four capital bands (Being copied, Paused, Dormant, Stranded), the at-risk leader table, totalAllocated, inUse, and the underwater-follower count. Because it is one scan, the four bands sum to totalAllocated exactly. capital.currency is sent only when every open allocation shares one quote asset and is null otherwise, with capital.quoteAssets giving the count. The dormancy threshold is sent as capital.dormantDays (7) so the page states the definition it was computed with.

Platform revenue on the same response is grouped by currency for the same reason, and revenueCurrency is null when profit share has been booked in more than one asset.

Everything else on that page — leader and follower counts, today's trades, volume, failure rate, the seven-day timeline and the sparklines — is a plain count or sum, not a statistics-calculator figure.

See Admin console for how to read the bands, and Settings for the thresholds named above.