Install and enable

Activating Copy Trading — the Ecosystem and Binary prerequisites, the eight tables it creates, the four permission keys, the two KYC features, the eight cron jobs, where replication actually runs, and a smoke test.

13 min readUpdated 26 August 2026install, ecosystem, binary, cron, permissions, kyc

Activation takes a minute. Getting the prerequisites right takes longer, and getting one of them wrong produces an install where leaders can apply, followers can allocate money, and nothing is ever copied.

Before you activate

Decide first which instrument classes you intend to offer, because they have different prerequisites and you can run either one alone.

Bicrypto core installed and running — see Installing Bicrypto
Redis reachable — statistics caching, rate limits and the daily-reset marker
For spot: the EcoSystem & Native Trading add-on licensed, installed and switched on in Admin → System → Extension Manager
For spot: at least one active market at /admin/ecosystem/market, with real order-backed liquidity
For spot: a test order can be placed and matched on that market
For binary: platform binary trading enabled in core settings
For binary: at least one active market at /admin/finance/binary/market

A copied market order is priced by walking the order book, and copy trading walks real, order-backed levels only. On a market whose book is largely AI market-maker display levels there is nothing to walk, so copies price off the leader's own fill price and stop-loss monitoring reports that the market has no readable liquidity by name.

If stop-loss looks broken on one market, that is where to look — the remedy is Admin → AI Market Maker → Markets → (market) → Real Liquidity %, not a copy trading setting.

Activation

The Copy Trading card — click it to open the product page
Its switch stays disabled, reading Activate license first, until the licence is activated
EcoSystem & Native Trading — licensed, installed and on before any spot copying can work

Open the Extension Manager. Admin → System → Extension Manager. On the Extensions tab, or by searching for Copy, find the Copy Trading card — product ID 61107157 — and click it. Until its licence is activated the card reads Activate and its switch is disabled; the switch's tooltip says Activate license first.
Activate the licence. On the product page press Activate License. Paste the purchase code from your MashDiv dashboard, optionally an email address for update notifications, and press Activate License. The screen confirms License Activated! and returns you to the product page a couple of seconds later. Keep the code private; it is tied to your account. If the server has no outbound access, the License File tab on the same screen takes the licence certificate downloaded from your MashDiv dashboard instead.
1. Paste the purchase code here
2. Activate License — then wait for the redirect back to the product page
3. License File — the offline route for a server with no outbound HTTPS
Install the release. Back on the product page, now licensed, the Overview tab has a release panel. If it offers Install v…, press it; if it says Up to date on a product you have only just licensed, press Check for Updates once, then install whatever it offers. The Releases tab holds the notes for the version being offered — read them first.

Install downloads the release, verifies it and extracts it over the project root. It runs no migrations, builds nothing and restarts nothing, so finish it from a shell on the server:
```
pnpm updator
```
That is the finalise chain — stop, dependencies, schema, seed data, frontend build, start — and it is what creates the eight tables listed below. If the panel still says Up to date after the check there is nothing to download; go straight to the next step.
1. Check for Updates, then Install v… when it is offered
2. Releases — the notes for the version you are about to install
3. The Enabled switch — step 4, not yet
Switch it on. Turn the Enabled switch on — in the product page heading, or on the card in the Extension Manager, which is usable now that the licence is verified. Copy Trading appears in the admin navigation, the user area answers at /copy-trading, and the scheduler picks up the eight cron jobs on its next resync — none of that needs a restart. The live replication queue is the exception: it is started by the backend's own extension boot task, so restart the backend once after switching on and look for [CRON] Copy trading queue initialized in its log. Where replication actually runs, below, explains why that matters.

The extension's internal name is copy_trading. That is the value the admin navigation and every extension check look for.

What activation creates

Eight tables are created when pnpm updator applies the install (step 3):

Table	Holds
`copy_trading_leaders`	Leader profiles: display name, style, risk grade, trading type, profit share, status
`copy_trading_leader_markets`	Which symbols a leader offers, per instrument class, with their per-market minimums
`copy_trading_followers`	Subscriptions: copy mode, risk caps, status
`copy_trading_follower_allocations`	Per-market, per-class budgets and how much of each is currently committed
`copy_trading_trades`	Every leader trade and every follower copy, with P&L, latency and binary result
`copy_trading_transactions`	The money trail: allocations, deallocations, profit shares, fees, refunds
`copy_trading_leader_stats`	One row per leader per day — trades, wins, volume, profit, fees, all in USDT
`copy_trading_audit_logs`	The full audit trail, including admin actions and system events

If you build from source, run pnpm types:generate once the tables exist. The predev and prebuild hooks do this for you.

Permissions

Four keys. Assign them to the roles that should operate the addon at /admin/crm/role.

Key	Grants
`access.copy_trading`	Reaching the admin area at all — this is what the navigation entry checks
`view.copy_trading`	The dashboard, leaders, subscriptions, trades, transactions, analytics, health and the audit log
`edit.copy_trading`	Approve, reject, suspend, activate and bulk-update leaders; pause, resume and force-stop a subscription; recalculate stats; reverse a transaction
`delete.copy_trading`	Deleting a leader, with or without refunding their followers

A fifth key, create.copy_trading, is declared on the admin tables but nothing creates a leader, follower or trade from the admin side, so granting it does nothing.

/admin/copy-trading/settings writes through the platform's own settings endpoint (/api/admin/system/settings), so it is governed by the core settings permission, not by edit.copy_trading. A role with full copy-trading rights and no settings right can approve leaders but cannot change the platform fee.

The user area under /copy-trading carries no permissions at all. Every endpoint there is scoped to the caller's own records. Who may use the product is decided by KYC features instead.

KYC gates

Open the level you want to gate on

Two features ship with this addon and are configured per level under Admin → CRM → KYC → Levels.

Feature	Refuses
`copy_traders`	Following a leader — checked in the browser and on the server
`become_trader`	Applying to lead, once the copy-trading Require KYC setting is on

Neither feature does anything until Enforce KYC Feature Access is switched on in core settings — it ships off. While it is off, copyTradingRequireKYC still demands an approved KYC level from leader applicants, but any approved level qualifies regardless of which features it carries.

Turning enforcement on is a real tightening: an approved user whose levels omit become_trader stops qualifying to lead whatever their level number, and a user with no verification at all can no longer follow anyone.

A third feature, view_copy_trading, appears in the level builder. No copy-trading endpoint checks it, so ticking or clearing it changes nothing.

The eight cron jobs

Check them at /admin/system/cron under the copy_trading category.

Job	Every	Does
`processPendingCopyTrades`	10s	Backstop replication of leader trades the live queue lost, plus the binary fan-out backstop
`processClosedCopyTrades`	30s	Settles closed follower copies, releases their allocation and returns principal
`monitorCopyTradingStopLevels`	30s	Triggers stop-loss and take-profit on open copies by placing a real exit order
`checkCopyTradingDailyLossLimits`	60s	Pauses followers whose realised loss for the day has passed their limit
`reconcileCopyTradingOrders`	5m	Tears down copies whose underlying order was cancelled or vanished, releasing stranded holds
`updateCopyTradingLeaderDailyStats`	5m	Writes each active leader's daily row, converted to USDT
`resetCopyTradingDailyLimits`	24h	Lifts yesterday's daily-loss pauses, once per UTC day
`aggregateCopyTradingWeeklyAnalytics`	7d	Aggregates weekly leader performance

Two details worth knowing before you debug a quiet install:

processPendingCopyTrades runs to a 60-second budget. A large batch stops after a minute and leaves the rest for the next tick, deliberately without counting a failed attempt against them — so a slow batch can never park a trade as permanently failed.
resetCopyTradingDailyLimits is anchored to UTC in the handler, not to its schedule. It writes a marker row and refuses to run twice in one UTC day, so the 24-hour timer drifting does not double-reset anybody.

Where replication actually runs

There are two independent mechanisms and they live in different places.

The live queue is in-memory and per-process. It is filled by the hook that fires when a leader's order is placed, which runs on the process that serves that order — the web process under a cron split. It is therefore started from the backend's own extension boot task, not by the scheduler. A healthy backend log shows:

[CRON] Copy trading queue initialized

The cron backstop is database-driven and runs wherever the scheduler runs. It does not read the in-memory queue and is not a substitute for it: it exists for trades the queue lost to a restart.

The practical consequence is that on a split deployment you need both. If the web process never initialises the queue, every copy waits the full two minutes for the backstop. If the scheduler is not running, a restart silently costs your followers whichever trades were mid-flight.

Smoke test

Apply as a leader from a test account — go to /copy-trading/become-leader, pick a trading type, and declare one market you can actually trade.
Approve the application — at /admin/copy-trading/leader, open the pending row and approve it. The applicant's status becomes ACTIVE.
Follow from a second account — open the leader at /copy-trading/leader and allocate a small budget on that market. Confirm the money leaves the ECO wallet (or SPOT, for a binary allocation) and appears in COPY_TRADING.
Place an order as the leader — a plain order on that market, nothing special.
Watch the follower's trade list — a copy should appear at /copy-trading/trade within seconds. If it takes two minutes, the live queue is not running on the process that served the order.
Check the admin side — rows appear at /admin/copy-trading/trade, /admin/copy-trading/transaction and /admin/copy-trading/audit.

Upgrading an existing install

Run pnpm updator as usual, then read this.

Binary support needs one boot with database sync enabled

Binary copying added a marketType column and composite unique indexes to the leader-market and allocation tables, and widened the trade table. Fresh installs get all of it automatically.

On an existing install the extension self-heals on boot — it drops the legacy two-column unique indexes that alter-sync cannot remove — but only once the new column and index exist. If you deploy with DB_SYNC=none, boot once with database sync enabled after upgrading. Otherwise a leader may be unable to declare the same symbol for both spot and binary. A warning is logged if the step is skipped.

Leader profit share now arrives in SPOT, not ECO

The spot path used to credit the leader's ECO wallet while the binary path paid SPOT, so one leader had two payout destinations depending on which of their trades a follower had copied. Both now pay SPOT. Tell your leaders before they file a ticket about missing funds.

The platform fee is now actually collected

Spot profit distribution previously wrote a fee line into admin reporting and took nothing. The follower kept the money and no admin wallet was credited. The fee is now debited from the follower's COPY_TRADING wallet and booked to the admin wallet before the record is written.

Two things follow: your reported copy-trading revenue stops being fictional, and follower payouts fall by the fee that was always being reported.

Closing a position is no longer instant

A triggered stop-loss or take-profit now places a real opposite market order and settles on the actual fill. A trade reads CLOSING until that order fills, then CLOSED with the realised profit. A position on a market with no real liquidity correctly stays open instead of being settled at a price nothing could trade at.

The replication backstop was dormant on fresh installs

The cron gate read Enable Copy Trading as off whenever the setting had never been saved — and nothing saves it during installation. On a new deployment the backstop did nothing until an administrator opened the settings screen and pressed save once. An unset switch now reads as on, matching every other gate in the addon.

If you have been running an install where you never saved that screen, the backstop starts working on upgrade. Expect it to pick up any stale PENDING leader trades on its first few ticks.

If you deploy with DB_SYNC=none, run the backend once with sync enabled so the new columns and indexes land. If you build from source, run pnpm types:generate.