Running and monitoring bots

A bot is created, funded with an allocation, started, and then left alone. This page covers each of those, and — more usefully — how to tell the difference between a bot that is broken and a bot that is simply waiting.

Creating a bot

There is exactly one bot-creation form in the product, and it lives in the trade terminal's Algo tab, beside the live chart and the ECO balance that will fund the bot. That placement is deliberate: the market list comes from the ecosystem markets the engine can actually trade, the price seeds the strategy defaults, and the balance is on screen so an allocation is never typed blind.

/trading-bot/create is a resolver, not a second form. It picks a market and forwards to the Algo panel, preserving ?type= and the marketplace's ?strategyId=, so old links keep working.

A new bot is created in DRAFT and does not trade until it is started deliberately.

What an allocation is

What the bot has committed is not a counter anybody increments. It is derived, on demand, from the rows that genuinely tie up capital:

used = Σ open trades (cost + fee)
     + Σ working BUY orders (remaining × price + fee)

available = allocated − used

A SELL contributes nothing, because it commits base inventory the bot already bought and whose cost is already counted by the open trade it will close. Counting it twice would reserve the same capital twice and deadlock a grid ladder.

This is why "Insufficient allocated funds" can appear on a bot whose owner has plenty in their wallet. The message is about the bot's own cap, not the wallet.

Allocation is adjusted from the bot detail page:

Removal is limited to available capital. A bot holding an open position cannot release the part backing it — close the position first.

The platform floor is Minimum Bot Allocation on the settings screen. It only applies to an allocation that was actually supplied: a DRAFT bot with zero allocation is legal and is how the "fund it later" path works. Starting is what refuses an unfunded bot.

The six statuses

ERROR is restartable — fix the cause and start it again. LIMIT_REACHED is too, but review the strategy first; the limit fired for a reason.

Starting a bot

Starting runs a gauntlet, and each refusal has a specific message:

Stopping and pausing are deliberately not gated by maintenance mode. A user must always be able to take a bot out of the market, even when the platform is otherwise closed.

Paper versus live

Both modes use the same engine, the same strategy code and the same risk checks. The only difference is whether the order reaches the matching engine.

Paper trades a virtual account that is per user and per currency. A bot trading BTC/USDT and one trading BTC/USDC use different paper accounts. The starting balance is Default Paper Balance on the settings screen.

Changing the default balance does not retroactively change existing accounts — they keep their balance until reset.

Live trades real funds from the ECO wallet, and requires the trade_bot_live KYC feature. Live placement is asynchronous: the order goes on the book and the trade row is written from the fill that actually happens, which may arrive on a later tick. A resting limit order can sit unfilled indefinitely — it shows in the bot's orders, not its trades.

The Bot Terminal

/trading-bot/bot/{id}/terminal is a full-screen chart with everything the bot is doing drawn on the price axis: the strategy's levels (grid rungs, the DCA schedule, a trailing stop's peak and chase), working orders, filled trades, the net position, and the indicators the strategy evaluates.

It is fed by a single payload:

The terminal uses both a WebSocket and a 15-second poll, and that is not redundancy. The socket carries events — a tick, a fill, a status change — and is what makes the view feel live. It cannot carry derived state: the strategy's levels are recomputed server-side from config plus fills, so after a fill the ladder has to be re-read rather than patched. The poll is how derived state refreshes, and it is deliberately slow because the socket handles everything time-sensitive.

The dock on the terminal drives the lifecycle, including Close position, which works on a stopped bot.

Exits are real orders, so they are not instant

A live bot leaves a position the same way it entered one: with an order on the Ecosystem book. Every exit — a stop-loss, a take-profit, Close position, and every kill switch — places a market sell and the matching engine settles it from the Ecosystem wallet.

That means an exit completes when it fills, not the moment you press the button. On a liquid market that is usually a second or two. On a thin one it can take longer, and on a market with no buyers the order waits until there are some. The screens say what is actually true — exit submitted, or closing on the fill — rather than reporting a close that has not happened yet.

Two consequences worth knowing:

• A position can be briefly open after you stop the bot. Stopping stops the strategy; the exit that was already placed still has to fill. The position and its allocation clear when it does.
• A kill switch that cannot place the exit immediately does not give up. If the bot's own resting orders still hold the inventory, the request is recorded and the platform finishes it in the background, normally within about thirty seconds. You are told the flatten is pending rather than that it failed.

Paper bots are unaffected: a paper exit settles inside the click, because there is no book to wait for.

A running bot that is not trading

This is the most common report, and it is usually not a fault. Open the terminal — the cockpit names the reason. The usual ones:

None of these are errors, and none of them count towards the consecutive-error limit that moves a bot to ERROR.

Editing a running bot

Only four fields may be changed while a bot is RUNNING: name, description, stopLossPercent and takeProfitPercent. Everything else — the strategy config, position sizing, concurrency, the loss limits, the cooldown — requires stopping the bot first.

Allocation is changed only through the add and remove endpoints, which row-lock the bot and write an audit entry.

Deleting a bot

A RUNNING bot cannot be deleted; stop it first. Deletion is a soft delete, and it gives the owner their slot back under Max Bots per User. The engine is told to drop the instance before the row goes, so nothing tries to write to a bot that no longer exists.

Monitoring across all bots

Win rate is computed from settled trades — wins plus losses — not from totalTrades, which counts entries too. A bot holding only open positions has a win rate of 0.00, not NaN.

Next

• Risk management and the kill switch — the envelope every bot carries
• Strategy reference — the five families in detail
• Troubleshooting — when the answer is not on this page