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.

7 min readUpdated 3 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 extension activated at /admin/system/extension
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

Buy and download the addon — note the CodeCanyon username and licence code that come with the purchase. Keep the code private; it is tied to your account.
Open Admin → System → Extensions — the screen lives at /admin/system/extension.
Activate — click the Copy Trading entry, enter your CodeCanyon username and licence code, and confirm. The platform verifies the purchase before enabling anything.
Confirm the surfaces appear — Copy Trading shows up in the admin navigation, and the user area answers at /copy-trading.

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 automatically:

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

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 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.

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.

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.

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 cron gate read Enable Copy Trading as off whenever the setting row had never been written — and nothing writes 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.