Settings reference
All 26 Algo Trading Bots settings keys — what reads each one, what it does when you change it, the shipped defaults, and the three that can stop a fleet trading the moment you save.
Everything this addon does is configured on one screen: Admin → Trading Bot →
Settings (/admin/trading-bot/settings). Six tabs, 26 keys, and every one of
them is read by live code.
Two dozen of these fields used to be accepted, saved, and read by nothing. If your install predates that fix, a value you set months ago and assumed was decorative starts enforcing itself the moment you upgrade. Open this screen once after upgrading and read every tab.
The settings table stores every value as text. An OFF switch is the literal
string "false", not a boolean — which is why every read goes through a coercion
that treats 1/yes/on/true as on and 0/no/off/empty as off. Never
compare the raw row.
Platform
Maintenance Mode is not the same as switching the addon off. It refuses create, start and resume only; stopping, pausing, deleting and every read stay open, so a fleet can always be wound down while it is on. It also suspends the engine without writing anything to a bot's row — the rows keep the status their owners chose, and the engine re-adopts them when maintenance clears. A ten-minute window does not force every user to restart their bots afterwards.
Enable Live Trading is your only way to halt real-money bots without disabling the whole addon. It is checked at creation, at start and at resume.
Changing Default Paper Balance does not change existing paper accounts — they keep their balance until the user resets.
Bots → Engine
These three are what the tick loop itself reads. Change them when the host is struggling, not otherwise.
Anything faster than one second hammers the price service on every tick, so the engine enforces a 1000 ms floor regardless of what is stored.
A bot refused for want of capacity is retried every 30 seconds and refused again —
forever. Its row stays RUNNING while nothing drives it, and within five minutes
the watchdog flips it to ERROR, which no adoption path picks up again.
There is one exception, and it exists because the cap must never strand exposure: a bot holding an open position or a working order is adopted even when the engine is over the cap. Capping a host's fan-out is a performance preference; abandoning a funded position with no stop-loss enforcement is not a trade the cap is allowed to make.
Bots → Limits, Allocation and Behaviour
Max Bots per User is enforced at the single creation choke point, so it cannot be sidestepped by buying a strategy instead of building a bot.
Max Active Bots per User is enforced on both start and resume — otherwise a user at the cap would simply pause and resume.
Max Concurrent Trades seeds a new bot's own open-position limit, which its owner can then edit. Max Concurrent Ticks is how many bots the engine evaluates in parallel. They sit on the same tab and setting one to change the other is a common and expensive mistake.
Minimum Bot Allocation applies only to an allocation that was actually supplied.
A DRAFT bot with zero allocation is legal — that is the "fund it later" path — and
starting is what refuses an unfunded bot.
Marketplace
Enable Marketplace closes selling, buying and reviewing. It deliberately leaves browsing, strategy authoring and running existing bots open — see Marketplace for exactly where the line falls.
Auto Approve Strategies excludes anything a human already rejected. A rejected strategy goes back in front of the reviewer who rejected it rather than being waved through on resubmission.
The price band is checked at listing time, at update time and again at submission, because a draft can sit for months and outlive the setting.
Trading
Raising this refuses every order below it, and a grid bot with many rungs on a small allocation produces exactly those. The bot keeps ticking and simply trades nothing — no error, no notification. If bots go quiet after you touched this tab, this is the first key to check.
The strategy layer sizes against the same value, so the two can never disagree. If they did, a bot would emit signals that could only ever be refused.
Maximum Trade Amount applies to entries only. Lowering it can never trap a position: exits are always allowed, so a bot holding more than the ceiling can still close. It is enforced literally, with no "0 means unlimited" escape — the screen floors the field at 1, so a zero can only come from a hand-written row, and refusing with a visible reason beats silently ignoring what you stored.
Disabling an order type refuses those signals before any other risk check runs.
Risk defaults
These seed a new bot's own limits. They do not retroactively change existing bots.
The create form sends none of these fields, and all four columns are nullable with
no database default. Two of them were previously passed straight through with no
fallback — and the risk manager gates the daily-loss and drawdown checks on
truthiness, so a NULL skipped the check entirely.
A bot built through the form had no daily loss cap and no drawdown cap
whatsoever and could never reach LIMIT_REACHED. New bots now inherit these
values. An explicit 0 is still honoured as a deliberate "no limit".
Fees
Platform Fee alone decides the marketplace split. There is no separate creator payout percentage and there deliberately never will be: two independent percentages could only disagree, minting money when they summed over 100 and stranding it when they summed under.
The default is 10% because 10% is what the purchase path has always actually charged, even when the screen displayed 20%. The rate in force at the time of a sale is written onto that sale, so changing it never re-prices history.
Both percentages are clamped to 0–100 on read, so a typo cannot mint or strand money on every sale.
Trading Fee is charged on top of the maker/taker rate the market itself already charges, on entries, exits and grid fills alike. It is taken from the user's Ecosystem wallet in the market's quote currency and recorded as platform profit, and the total of both fees is what the bot records against the trade — so a user's profit and loss reflects what they actually paid.
It ships at 0%, so nothing changes until you set it. Before you do:
- Collection is best-effort, by design. A bot's capital is held by the matching engine while its orders are working, so a user who has allocated their whole Ecosystem balance may have nothing spare to pay the fee from when a trade settles. The trade always stands — refusing a fill that already happened on the book would be far worse — and the shortfall is recorded against the trade and logged as an error naming the bot, the amount and the currency. If you set a non-zero rate, watch for those lines: a steady stream means users are fully allocated and the fee is not being collected.
- Paper bots pay it in simulation. The virtual balance is reduced by the same rate so a paper run predicts live costs honestly, but no real money moves and nothing is credited to the platform.
Two things that are gone
Require KYC. It was stored, read by nothing, and shipped OFF. Wiring it up
literally would have removed a gate rather than adding one, because live bots are
already refused unless the user's KYC level grants trade_bot_live. The four
trading-bot features under Admin → CRM → KYC are the real control.
Creator Payout. See Fees above.
Where these values are read
Every key is read through the platform settings cache, which has two coherence paths — a Redis invalidation bus and a durable version poll — so a change reaches the engine host without a restart. There is no in-process snapshot; a module-level copy would defeat both and pin the engine on stale settings forever.
The retired trading_bot JSON blob is still read once, as a migration source,
for a field that has no flat row yet. Nothing writes it any more, and the moment you
save this screen the flat row wins for that field.
liveTradingEnabled and marketplaceEnabled are not migrated from the legacy blob,
because the retired writer baked a phantom false into it for both the moment any
partial update was sent — and "never chosen" and "chosen false" are the same bit
there. Honouring it would mean an install that did nothing but turn the engine on
comes back from the upgrade with every live bot refused and the whole marketplace
closed, caused by the upgrade rather than by the operator, and invisible on a
settings screen showing both switches ON.
The API
The PUT accepts the short field names (enabled, maintenanceMode,
maxBotsPerUser, …) rather than the prefixed storage keys, leaves omitted fields
unchanged, and returns the full resolved settings rather than only what you sent.