Algo Trading Bots

Server-side automated trading for your platform — five strategy families, a visual rule builder, paper and live modes, enforced risk limits and a moderated strategy marketplace.

4 min readUpdated 3 August 2026trading-bot, automation, strategies, marketplace

Algo Trading Bots lets your users build, fund and run automated strategies against your platform's own order book. A user picks a strategy family, tunes it against the live price, sets a risk envelope, allocates capital and starts the bot. From then on a server-side engine evaluates that bot every few seconds and places real orders on its owner's behalf.

Nothing runs in the browser. Closing the tab, logging out or losing the connection does not stop a bot — only stopping it does, or one of the limits it was created with.

What it requires

This addon needs Bicrypto core and the Ecosystem addon. It is ecosystem-only end to end: bots trade ecosystem markets, price off ecosystem candles, and their orders are backed by the ECO wallet. Nothing in it can reach an exchange spot or futures book.

With Ecosystem disabled, no bot runs anywhere in the deployment — not even a paper bot, because a paper bot still needs a price feed. The platform raises a standing cron warning saying exactly that. There is no configuration that makes the combination work.

Requirement	Why
Bicrypto core	Wallets, KYC, notifications, permissions, the cron manager
Ecosystem addon	The markets bots trade, the candles they price off, the ECO wallet their orders hold from
At least one active ecosystem market	Bot creation is refused outright on any pair that is not one
ScyllaDB	Ecosystem candles live there; every indicator strategy and the price fallback read them
Redis	Settings cache and cron scheduling
A backend process holding the ecosystem matching lease	The engine runs there and nowhere else

Chart Engine is optional but strongly recommended — it draws the on-chart strategy geometry in the Bot Terminal.

What a bot is

A bot is a row with four things attached to it: a market, a strategy configuration, a risk envelope and an allocation. The engine holds running bots in memory and ticks them on one interval (5 seconds by default). Each tick it prices the market, asks the strategy for a signal, runs that signal past the risk manager, and places an order if it survives.

Five strategy families ship:

Family	What it does	Suits
`GRID`	Places a ladder of buy and sell rungs across a price band and books the spread between them	Ranging markets
`DCA`	Buys a fixed or proportional amount on a schedule, optionally gated by a price filter	Accumulation
`INDICATOR`	Enters and exits on RSI, MACD, Bollinger Bands and moving averages, evaluated on closed candles	Trending markets
`TRAILING_STOP`	Enters once, then chases the price with a stop that only ever ratchets upward	Riding a move
`CUSTOM`	Runs IF/THEN rules composed in the visual Strategy Builder	Anything the other four do not

Every bot runs in one of two modes. Paper trades a per-user, per-currency virtual balance. Live trades real funds. Both use the same engine, the same strategy code and the same risk checks — the only difference is whether the order reaches the matching engine.

Where things live

The only bot-creation form in the product. It sits beside the live chart and the ECO balance that will fund the bot, so allocation is never typed blind.

The user area: dashboard, bot list, Strategy Builder, marketplace, creator dashboard and an in-product guide.

The Bot Terminal — a full-screen chart with the strategy's levels, working orders, filled trades and indicators drawn on the price axis, plus lifecycle controls.

The fleet console: every bot on the install, the moderation queues, the audit trail, the settings screen and the fleet-wide kill switch.

How money moves

Two different wallets are involved, and confusing them is the single most common support ticket this addon generates.

Bot trading uses the ECO wallet. A bot's allocation is a cap, not a transfer — setting it moves no money at all. The funds stay in the user's Ecosystem wallet and are held there by the matching engine at the moment an order is placed. What the bot has committed is derived from its open trades plus its working buy orders; it is never incremented by hand.

Marketplace sales use the SPOT wallet. The buyer is debited the full price from SPOT, the seller is credited their share to SPOT, and the platform fee is routed to the Super Admin wallet and recorded as admin profit. All three moves share one database transaction.

A user with SPOT funds but no ECO balance can buy strategies all day and still be unable to run a live bot. The reverse is equally true. When someone reports "insufficient funds" on a bot that looks funded, check which wallet the money is in before anything else.

The engine runs in exactly one process

This matters on any deployment running more than one backend process — a cron split, the worker-thread entry, or a multi-node install.

The engine is a per-process singleton, and it refuses to run anywhere except the process holding the ecosystem matching lease. That is not a preference: a live order is enqueued on the matcher's in-memory queue, and an order enqueued on a read-only follower is refused outright. Every other process registers the same cron jobs and they are structural no-ops there.

One consequence surprises people: the admin dashboard does not show you the engine's own status, because an admin API request is served by whichever worker picks it up, which is almost never the engine host. Asking that worker would report STOPPED on a perfectly healthy install. The honest proxy is the fleet health split — how many RUNNING bots are ticking versus silent — which is computed from the database and is correct on any process.