Taking copy trading offline, and offboarding a leader with a book

Every allocation in copy trading is a real transfer. When a follower subscribes, their money leaves their ECO or SPOT wallet and sits in a COPY_TRADING wallet, which has no withdrawal path and no transfer path out other than the ones this addon provides. Turning something off does not move it back.

So the question to hold in your head through this whole page is not "did copying stop" — several switches will do that in seconds. It is "whose money is still in COPY_TRADING, and what will take it out again."

The five switches, and exactly what each one stops

All five are decisions you make and then live with; four are on /admin/copy-trading/settings and the fifth is the Ecosystem extension itself.

copyTradingEnabled — the master switch

Off, it does three things: every user-facing eligibility check refuses with "Copy trading is currently disabled", and the replication backstop (processPendingCopyTrades) skips its entire run — including the binary backstop nested inside it, which is checked after the master gate.

It does not cancel open copies, does not release holds, and does not return capital.

copyTradingMaintenanceMode — pause the front door

The gentlest of the five. It refuses with "Copy trading is currently under maintenance" on the same checks the master switch refuses on, and leaves existing subscriptions, open positions, the backstop and live replication completely alone.

Use it for a maintenance window on the surrounding platform. It is not a wind-down step on its own.

copyTradingEnableSpot and copyTradingEnableBinary — the real kill switches

These are the two that actually stop replication, because they are checked on the live path as well as on setup. Turn spot off and the next leader order is not copied to anybody.

The backstop checks the spot switch once per run, before it selects any rows. With spot off it logs "Spot copy trading is disabled, skipping" and stops — the pending leader trades stay PENDING, untouched, with no attempt counted against them. That is deliberate: turning the switch back on resumes from where you were rather than burning through a backlog and parking it as REPLICATION_FAILED.

Binary is gated twice on purpose. If platform-wide binary trading is off, the binary engine would reject a copied order anyway, so the copy layer refuses up front with a message naming the real reason.

Neither switch touches a position that is already open, and neither returns capital.

Disabling the Ecosystem extension

Turning ecosystem off at /admin/system/extension makes spot copying fail closed. Every spot path re-checks that the extension is enabled — not merely that its files resolve — before it writes anything, so replication, reconciliation and stop-loss monitoring all log "Ecosystem extension not available" and skip. No copy-trade rows are written for orders that were never placed.

The three destructive actions

Suspending a leader

Sets the leader to SUSPENDED and pauses every follower behind them in one statement. Refuses if the leader is not currently ACTIVE. The reason is mandatory and is carried into the notification the leader reads.

Money is untouched — every allocation stays funded in COPY_TRADING, and it moves to the dashboard's Stranded band immediately, because the leader can no longer trade.

Deleting a leader — the only bulk refund path

This is the action that returns money, and it is the backbone of a planned wind-down.

It first refuses if that leader has any trade — their own or a follower copy — in OPEN, PENDING or PARTIALLY_FILLED, with a message naming the count. Positions must be closed first.

With refundFollowers true (the default), for every non-STOPPED follower and every active allocation it:

• computes the unused portion — baseAmount − baseUsedAmount and quoteAmount − quoteUsedAmount;
• moves it back to the wallet it came from: COPY_TRADING → ECO for a spot allocation, COPY_TRADING → SPOT for a binary stake budget;
• writes a REFUND transaction row per leg with ADMIN_LEADER_DELETED in its metadata;
• deactivates the allocation and writes down its recorded amounts to the used portion;
• sets the subscription to STOPPED.

Then it sets the leader INACTIVE and soft-deletes them. The whole thing runs in one database transaction, and each transfer carries a stable idempotency key, so repeating the deletion cannot refund a second time.

With refundFollowers false, subscriptions are stopped and nothing is refunded — every allocation stays funded in COPY_TRADING, unreachable by the customer. There is no supported reason to do this on a live install.

Deleting sends no notification. Tell the followers yourself.

Force-stopping one subscription

The Stop button on /admin/copy-trading/follower and on the subscription detail page. It takes a reason, locks the row, refuses if the subscription is already STOPPED, sets it to STOPPED, and writes an ADMIN_FORCE_STOP audit row.

For comparison, the follower's own stop at POST /api/copy-trading/follower/{id}/stop does the full teardown: it cancels live copy orders and releases their COPY_TRADING holds, then refuses outright if any position has actually filled — telling the customer which symbols and suggesting they pause instead — and only then transfers every allocation's unused balance back to ECO or SPOT, writes DEALLOCATION rows, deactivates the allocations and sets the subscription STOPPED.

That refusal is deliberate: a filled position is coins in a wallet, not an order, and nothing in a single request can unwind it. It is also why the customer path is the one that returns money cleanly, and the admin path is not.

Pausing, for completeness

Only works on an ACTIVE subscription, notifies the follower, and writes an ADMIN_PAUSE audit row. Use it while you are still working out what happened — pausing leaves the money where it is, which is what you want mid-investigation.

Note that the list screen offers Resume and Stop but no Pause button; the pause endpoint exists and is reachable from the API and the detail page.

A wind-down that finishes

The order matters, because the delete step is blocked by open positions and the positions only close while copying is still functioning.

How to prove it finished

A falling total is not proof. The dashboard at /admin/copy-trading splits allocated capital into four bands computed in one server-side pass, and they sum exactly to the total beside them.

Zero in Stranded and zero in Paused is the finish line. A total that has fallen 90% while Stranded holds the rest means the wind-down stopped halfway and somebody's money is sitting in a wallet they cannot reach.

Two further checks worth doing:

• capital.currency in the dashboard response is null whenever the open allocations span more than one quote asset. While that is the case, the totals are a correct sum of a column and not an amount in any currency — read the bands as "is it zero", never as "how many dollars".
• The at-risk leader table beneath the meter names a reason per leader: leader-inactive (reinstate or refund), dormant (ask the leader), or unreleased (the teardown did not finish). It is capped at eight rows and reports the true count, so read "showing 8 of 23" literally.

Rate limits and doing it at scale

Every route under /api/admin/copy-trading that changes something is limited to 50 actions per hour, per admin — approve, reject, activate, suspend, delete, recalculate, bulk status, the leader and subscription edit routes, pause, resume, force stop, and transaction reversal. Approving, suspending or deleting a backlog by hand will hit that ceiling, and the 51st action fails with "Too many admin actions. Please wait."

The read routes carry no limiter at all — the dashboard, analytics, audit, health, and the leader, subscription, trade and transaction lists and detail pages. Refreshing a screen while you work costs you nothing against the ceiling, so watch the capital bands as often as you like.

The bulk endpoint takes leaderIds, a status of ACTIVE, SUSPENDED or INACTIVE, and a mandatory reason, and counts as one action against the limit. Its behaviour differs from the single-action routes in ways that matter:

• SUSPENDED pauses every active follower of each leader, exactly as a single suspend does.
• ACTIVE on a PENDING leader is refused per row with "Use approve endpoint for pending leaders" — the rest of the batch still processes.
• A leader already at the target status is reported as skipped.
• Reactivating from SUSPENDED leaves followers paused, same as the single route.
• It sends no notifications at all. Not to leaders, not to followers, not to administrators. It writes BULK_<STATUS> audit rows and nothing else.

It cannot delete and cannot refund, so it is a way to clear a leaderboard quickly, not a way to return capital.

Related

• Admin console — reading the capital bands and the audit trail
• Settings — every key, and the six that are never enforced
• Notifications — who gets told what, and who does not