AI Market Maker v6.1.5

Release Date: July 29, 2026 Tags: MONEY PATH, POOL, LIFECYCLE, ANALYTICS, SECURITY, PRICE ENGINE, ORDER FLOW, RISK, BINARY SETTLEMENT, ORDER BOOK, DATABASE CHANGE

Overview

A full review of the addon: every admin screen, the price engine and the pool money paths.

The pool is real money. Its base and quote balances are the only thing between an admin's ecosystem wallet and the market's inventory: a deposit takes from the wallet and raises the pool, a withdrawal lowers the pool and credits the wallet, and real user trades settle against those same two balances.

Three findings against that, two of them severe:

1. A pool could be funded exactly once, ever. Every top-up after the first failed with "Duplicate operation detected".
2. The rebalance action created currency — it converted pool base into pool quote at a price the operator chose, with no trade behind it, and a withdrawal then paid that out for real.
3. The market list exposed the secret value that determines the entire future price path.

It also replaces the two layers that decide what a market actually does. The price engine is new — seven timescales running at once, from twenty minutes out to three years — so a chart carries genuine trend, regime and intraday structure instead of the same noise texture at every zoom level. The layer that decides when a bot trades, how large, and on which side is new with it, and it fixes the single worst behaviour in the addon: a market spent its whole daily trading allowance 33 minutes into each UTC day and then printed nothing at all until midnight.

It also fixes the addon's most expensive defect, which is not in the price engine at all: the market maker never cancelled its own quotes. Every print appended a new resting order to the real ecosystem order book and nothing reliably removed the previous one — no refresh cycle, no cancel-before-replace, no ceiling. One live market reached 704,353 open orders, which was enough to stop the API binding its port at startup. Fixed here, with a hard limit on resting orders so it cannot recur silently. Orders already accumulated need one cleanup command — see Clearing accumulated AI Market Maker orders in the Core v6.5.8 notes.

It also turns on safety limits that shipped as working features and had never once run. Daily loss limits, the per-market loss auto-pause, the high-volatility pause and all four global kill switches on the settings screen were inert, and the risk figures shown to operators were not measurements of anything. Two further findings sit outside the engine entirely: every AI trade deleted real users' and copy-trading followers' resting orders from the aggregated order book, and a binary order could settle at one price while the chart showed a different price for the same minute. Both are fixed here.

This release does change the database structure — four new fields, three on a market and one on a bot. Installations that let the platform apply structure changes automatically need to do nothing; see Upgrade Notes. Everything else below applies as soon as you update.

Upgrade Notes

Database structure

This release changes the database structure: four new fields are added, three on a market and one on a bot.

They hold the market's price seed, a periodic snapshot of the engine's price state, the time that snapshot was taken, and the moment a bot's cooldown expires. All four are load-bearing — without them the engine cannot persist its seed on first start, cannot resume its price state across a restart, and restoring a bot from cooldown fails.

Orders already accumulated do not disappear on update

• Changed: the engine stops creating uncancelled resting orders; the ones already resting stay resting.

Changed

The price engine and the trading tape

A new price engine

The price a market publishes is now produced by a multi-horizon process rather than a layered noise field. Seven timescales run at once, from twenty minutes to three years, so the series carries structure at every zoom level a trader actually looks at.

• Real multi-timeframe structure: multi-month trends, multi-week regimes, day/night shape and intraday waves — instead of the same texture repeating at every zoom.
• Fat tails and volatility clustering: quiet stretches and violent ones, with volatility that persists rather than being redrawn from scratch each tick.
• Volatility is measured against the clock, not the tick. Price now integrates against wall-clock time, so a market's realised volatility matches what was configured regardless of how often the engine happens to tick, and a restart resumes on the correct distribution instead of starting a fresh one.
• Directional edge is bounded. How much an observer watching the series can extract on a short-dated bet is capped at 1.5%. That matters most on markets that settle binary options.

A market went silent 33 minutes into every trading day

Every market ran out of trading allowance inside the first hour of each UTC day and printed nothing at all until midnight. Six bots on a moderate market carried 100 trades each; both sides of every print consumed one, and the engine spent them at a flat rate of roughly one trade a second. That is 300 trades of capacity, gone in about 33 minutes. Conservative markets lasted 50 minutes, aggressive ones 33.

Max Daily Trades is now a daily budget rather than a fuse. The allowance is paced across the whole UTC day along a 24-hour activity curve — roughly one trade every 10 seconds across the US/EU overlap and every 35 seconds overnight — so it lasts until midnight instead of burning out before lunch.

Newly created markets are also seeded with far larger defaults, sized from measured density rather than nominal arithmetic: 1,200 for a conservative market, 3,500 for a moderate one and 9,000 for an aggressive one, against the old 50/100/200. A moderate market now prints around 3,500 trades a day, one every 25 seconds on average.

Existing markets keep the values they were created with, and are strictly better off regardless — the same allowance now lasts all day.

Bot personalities had no effect on trading

The five bot personalities — scalper, swing, accumulator, distributor and market maker — were configuration that changed nothing. Every bot traded on the same flat coin flip once a second, and every order size was drawn from a uniform band of ±20% around the configured average, which is the most obvious synthetic-tape tell an addon can have.

Personality now shapes the tape. Accumulators sit on the bid far more often than distributors, scalpers print small and fast, swing bots print larger and slower. Order sizes follow a realistic distribution — mostly small, occasionally large, snapped to round lots — and arrivals follow a 24-hour activity curve instead of a constant rate.

The flow layer decides only when a trade prints, how large it is and which bot takes each side. Price remains the sole responsibility of the price engine, so nothing but the price engine can put a hand on the series that binary options settle against.

A restart jumped the price and rewrote history

Restarting the backend printed a step change on every timeframe of every chart. The engine kept no state at all, so it began each start on a fresh price path rather than resuming the one it left, and it seeded the order book around the configured target price rather than the live price.

It also wrote a candle on startup, which rewrote the close of the in-progress candle on all thirteen intervals — including the daily and the weekly.

The engine now checkpoints its price state every two minutes and resumes from it, the order book is seeded around the live price, and startup writes nothing into the candle history.

Quiet markets keep their chart and order book alive

With cadence now driven by bot activity, "no trade this tick" is the normal case rather than an exception — and a market that is simply quiet would otherwise let its chart stall and its depth expire underneath it.

Every non-trading path now publishes a price heartbeat, so the chart stays continuous and the order book keeps showing depth when a market is quiet, when the daily volume cap has been reached, when the volatility guard is active, or during a global pause.

• Volume is not inflated: a heartbeat carries no volume.
• No allowance is consumed: the cap that gated the tick is not spent by the heartbeat.

The recorded price history was not the price anyone traded at

The engine recorded a price history, but recorded the wrong series: an external exchange reference that the chart never shows, rather than the price the market published and users traded against. It was also only written on ticks that produced a trade — which, after the cadence changes, is now the minority of ticks.

The history now records the published price, on every tick. Everything reading it — the admin performance chart and the volatility measurement among them — agrees with the visible market.

Trade attribution and tick direction were wrong

A trade decision that failed to publish still advanced the engine's reference price, so the next tick's up/down labelling was computed against a price nobody ever saw. Only a trade that published advances the reference now, and the tape's direction matches the actual movement.

The bots credited with a trade were also not always the bots that made it — the execution layer re-picked two bots at random rather than using the pair the flow layer had chosen. A bot's daily trade counter now reflects the trades it genuinely made.

Other engine changes

• The engine now warns when a market's settings make it predictable. Two configurations make a market readable by anyone watching it: following an external price closely, and setting a price range too narrow for the configured volatility. Both are legitimate choices, and both are dangerous on a market that settles binary options, because a predictable price is a free bet. The server log now warns in concrete terms — the percentage edge an observer would hold over the next hour — the first time an external tether engages on a market, and at startup when the configured range is too tight for the configured volatility. The tether warning recommends switching that market to autonomous pricing if it settles binary options. These are log warnings; nothing about them appears in the admin panel.
• A slow exchange can no longer stall a tick. The external price fetch moved off the price step itself onto a cached refresh.

The admin area was restyled onto the platform's design system

The AI Market Maker admin screens now follow the platform's design system instead of their own hardcoded colours. They pick up the operator's theme, including any palette change made from the design panel, in both light and dark.

Colour literals, multi-stop gradients and drop shadows across all twelve screens were replaced with the platform's own theme values, and the analytics price chart moved onto the platform's shared charting style.

Fixed

Pool money paths

A pool could only ever be funded once

The first quote deposit a pool ever received worked; every one after it failed with "Duplicate operation detected", permanently, with nothing in the message to suggest the cause was the platform itself. Withdrawals had the identical problem, which meant whatever was left in a pool after its first withdrawal could never be taken out.

Both now work every time. A double-clicked button still settles once.

Rebalance converted assets that were never traded

The rebalance action calculated the balances a requested ratio would need and simply wrote them onto the pool, under a note reading "In a real implementation, this would execute actual trades. For now, we just update the balances (simulated rebalance)."

Those balances are not a projection. The exploit was three clicks:

deposit 20 BASE          -> pool holds 20 BASE, 0 QUOTE
rebalance to ratio 0     -> pool "holds" 20 x target price in QUOTE
withdraw QUOTE           -> a real credit on a real ecosystem wallet

The target price and the price range are both operator-settable, so this was a conversion between any two ecosystem tokens at any rate the operator chose, with no counterparty.

The automatic rebalancer already refused to do this and documents exactly why. The admin action now matches it: it reports the movement the target ratio would require and changes nothing. The supported way to shift a pool's composition is to move real assets — withdraw the surplus, trade it, deposit the proceeds back — and the response says so.

The admin button is now Calculate rebalance, and shows the required change in each currency instead of a "Pool rebalanced successfully" message.

Funding a pool no longer needs a live blockchain

Funding a pool is an internal transfer between two balances the platform already holds. It needs no deposit address and no configured chain — but it was being routed through the deposit-address machinery anyway. An admin holding a perfectly good balance in a token whose chain is not configured on that server got an opaque error and could never fund the market. Funding now reads the wallet directly, and where a wallet genuinely has to be created the failure is explained in terms you can act on.

Capital basis

The pool's starting capital was recorded only on the first deposit and never updated. A pool funded ten times reported its return on a tenth of the money, and one that had been drained still reported the original capital. It now rises on deposit and falls on withdrawal.

The engine could run twice

Running the backend as more than one process — cluster mode, a rolling restart whose old worker has not exited, or two development shells — gave two price engines driving the same markets.

This was found live during the review, and the symptoms read as bugs somewhere else entirely: the price moved twice as far as configured, stopping a market from the admin panel left it publishing, and synthetic order book levels came back after being cleared. Both engines were also writing the 1-minute candle that binary options settle against.

Only one process now drives the markets, and it hands over cleanly on restart. The market status screen also reports whether the engine is genuinely attached, so starting a market on a process that is not the active one says so instead of turning the badge green while nothing runs.

Lifecycle

A market the engine had lost could not be stopped

If a market failed to start — because it was below the minimum-liquidity setting, or hit the concurrent-market cap, or a restart could not reload it — the admin panel could no longer control it. Stop reported "stoped successfully" (sic) without changing anything, and pause returned a server error. The market stayed active, and because withdrawals and rebalancing both refuse an active market, the pool was locked with no way to reach it from the admin panel at all.

Both now record the change properly, and stopping also clears any synthetic depth the market left on the order book.

Emergency stop did not stop the engine

Emergency stop marked every market stopped, paused every bot and flipped the global switch — and never touched the running engine. The global switch suppresses trades and nothing else, so every market kept advancing its price, kept writing candles, and kept republishing its synthetic order book. It now halts the engine as well, and says so.

It also counted only active markets while stopping everything, so an emergency stop that halted a dozen paused markets reported "0 markets stopped" and recorded no history for them.

Recovery from an emergency stop now works on the first start, rather than depending on a later scheduled pass happening to notice.

Ten unrelated errors, at any point in a market's life, froze it permanently

A market kept a lifetime error count that was never reset. Ten transient failures — spread across a day, a week or six months — put it into an error pause it could never leave: the engine had stopped it, while the database still said Active, and activating an already-active market is refused.

A market now pauses only on a sustained run of consecutive failures, clears that run on every successful price step, and retries on its own after a minute. A pause an operator applied is never auto-resumed.

An operator's pause could be silently undone

The job that resumes auto-paused markets looked only at the single most recent auto-pause record. If an operator paused a market that had been automatically paused earlier, the job found the automatic one and put the market straight back into trading — which also silently re-blocked pool withdrawals and rebalancing, both of which refuse an active market.

It now reads the recent history rather than one record and stops on any later decision, so an operator's pause stands.

Separately, a market paused by the engine's own loss protection stayed frozen indefinitely: the resume check matched one exact reason, and loss protection writes a different one. Those markets now resume the next day as intended.

The market maker never cancelled its own quotes

Every simulated print appended a brand new resting LIMIT order to the real ecosystem order book, and nothing reliably removed the one it replaced. There was no quote-refresh cycle, no cancel-before-replace, and no limit on how many orders one market could leave resting. On a live installation that reached 704,353 open orders on a single market.

At that size it stops being a tidiness problem. The backend loads open orders at startup, so that one market made the API take minutes to bind its port — the site served connection refused while the log filled with successful startup messages. Reading the aggregated book on every fill exceeded a JavaScript engine limit outright. Counting the market's orders timed out at the database. And the orders were live, hittable liquidity, so none of it could be ignored.

Five defects compounded, and any one alone would have been survivable:

• No cancel-before-replace. The tick loop placed and never pulled.
• The owner was never recorded. Real-liquidity orders are written into the book under the bot's identity, and the orders table is keyed by that owner. The tracking row had a column for it from the start but never wrote to it, so after any restart the addon rebuilt its list using the AI-layer order reference instead — and every cancel it issued looked up a key matching nothing.
• A failed cancel reported success. The cancel step returned nothing at all, including on the paths where it gives up without writing, so callers could not tell "cancelled" from "found nothing". The addon marked its tracking row cancelled either way, and an order that was never cancelled became invisible to every future sweep while still resting.
• The expiry sweep discarded what it could not cancel — removing orders from tracking regardless of the result, deleting the last reference to orders that were still live.
• The sweep was skipped on busy markets. It ran inside the per-tick timeout guard, so any tick over five seconds skipped that minute's cleanup — the markets placing fastest were swept least.

All five are fixed. Cancels now report whether they cancelled anything; the owner is recorded and used, and rows written before this release are skipped rather than cancelled under a guessed key; the sweep keeps and retries what it fails to cancel, with backoff and a warning naming the likely cause; and it also runs after a failed tick.

Added on top, because those are corrections to a mechanism that can still be interrupted: a hard ceiling on resting real orders, default 500 per market. A market that reaches it stops placing new real orders until existing ones fill or expire, and says so once. It refuses to place rather than force-cancelling the oldest quote — cancelling mid-tick races the matching engine's settlement, and a maker sitting at its ceiling is something you should see rather than have quietly worked around. Configure per market, or globally with AI_MM_MAX_RESTING_REAL_ORDERS.

If you already run this addon, orders you accumulated do not disappear on update. See Upgrade Notes.

Other lifecycle fixes

• A failed start left six active bots on a stopped market.
• Status messages said "stoped" and "resumeed".
• Creating a market recorded it as a start event, which the performance chart then read as a price observation. It is recorded as a configuration change now.
• Creating a market checked for a duplicate before checking the rest of the form, so every malformed request aimed at an existing market came back "AI Market Maker already exists" — true, but not the reason the request was wrong.

The secret price seed leaked through the market list

Each market carries a secret value that generates its entire future price path; anyone holding it can compute the price in advance, which on a market that settles binary options is the whole game. It was correctly stripped from most responses — but the market list handed it, and the engine's internal state, to every caller. Both are now excluded.

Analytics reported numbers nothing produced

Profit and loss was structurally zero

The P&L report added up a figure nothing had ever recorded. So daily, weekly, monthly, all-time, the win/loss split and both averages were a hardcoded 0 presented as a measurement, no matter how the market had actually performed.

Two real sources exist and are now used: the running total each bot accumulates on every fill against a real user (authoritative for the lifetime figure), and a per-trade record that is now written for the first time — the table for it shipped with the addon and had never had anything writing to it.

Trades between the platform's own bots are deliberately excluded from both: both sides are the house, so they have no profit or loss to report.

Invented bot statistics were presented as measurements

The bot list reported every bot's success rate as 50% and its profitable trades as exactly half its total. The individual bot screen reported a 65% win rate, successful and failed trade counts derived from that same 65%, and a total volume calculated by multiplying the daily trade count by the average order size.

None of it was measured. A trade between two of the platform's own bots has no profit or loss at all — both sides are the house — so most bots had never had a single trade capable of winning or losing, and were still shown a confident win rate.

Both screens now show the real count of fills against real users and the real profitable count, and show nothing where there is nothing to measure.

Daily summaries recorded zeros, for the wrong 24 hours, twice

Every daily summary the addon has ever written recorded zero volume, zero buys and zero sells. It totalled values nothing writes, and split buys from sells on a figure that is always the same.

The day it covered was the server's local day rather than the UTC day the rest of the addon uses, nothing stopped a second summary being written for a market that already had one, and markets that had not traded at all still got a row of zeros.

Summaries now record real notional volume — amount × price — for the correct UTC day, one summary per market per day, and only for markets that actually traded. Figures that cannot be recovered from the underlying records are left out rather than reported as zero.

Other reporting fixes

• Target achievement rate was a hardcoded 85% rendered as a performance figure. A market that had never gone near its target reported 85% as confidently as one tracking it perfectly. It is now measured, and shows nothing when there is nothing to measure.
• Current price showed as 0 on any market that had never started.
• Unrealised profit valued the pool's opening inventory at a price of 1. A pool funded with 40 base on a market at 100 had its opening capital valued at 40 instead of 4,000, and the engine wrote a roughly +3,960 "unrealised profit" to it every minute for a position that had never traded.
• Total value locked added two different currencies together instead of valuing them.
• The pool return percentage did the same, so 5 base plus 10,000 quote on a market at 100 — 10,500 of capital — was treated as "10,005".
• The trades list filtered by bot after paging, so a filtered request returned whatever fraction of one 20-row page belonged to that bot, while the total still counted every bot's trades.
• The performance chart is now bounded. An aggressive market records about 9,000 trades a day, and an unbounded 30-day query pulled a quarter of a million records to draw a chart with a few hundred points. It is capped now, and says when it truncated.
• The admin pool panel valued the base side using a field the pool does not have, so a pool holding 40 base and 90,000 quote on a market at 100 displayed as 0.04% base — and the slider then invited a rebalance toward a number that was never true.

Validation

• Editing any field on a market with a 9–10 price range was refused with "Price range low must be less than price range high" — about a range that is perfectly valid. The two numbers were being compared as text rather than as numbers.
• The same screen recorded a configuration change on every save, whether anything changed or not.
• Maximum daily volume and volatility threshold were not validated on create or update.
• Invalid bot settings came back as a server error. Sending a bot configuration outside the allowed range produced an opaque server error instead of a refusal explaining what was wrong — average order size, max daily trades, trade frequency and preferred spread had no validation at all. All four are validated now, and an out-of-range value comes back with the range it needed to be in. This affects direct API callers; the admin form never produced a value in the affected window.

Real users' orders and binary settlement

Every AI trade deleted real users' resting orders from the order book

Each time an AI bot traded, the engine rebuilt the market's aggregated order book by deleting every level for that symbol and writing its own back. Real users' resting limit orders — and copy-trading followers' — were deleted along with them, and only reappeared when a periodic repair pass restored them minutes later.

While a level was missing it could not be matched against, so a user's order sat in a book that no longer showed it. Anything pricing off that book was reading the same gap, including copy trading's effective-price and slippage calculation.

The rebuild now tells the engine's own levels apart from order-backed ones and removes only its own. The same correction applies everywhere the book is cleared — on shutdown, on emergency stop, and in the fallback after a failed batch write. The engine's own levels now expire by themselves after two minutes as well, so a bot that stops quoting cannot leave depth behind.

A binary order could settle at one price while the chart showed another

Binary options settle on the 1-minute close of the expiry minute, and three different things write that candle. The market maker was overwriting the close the binary engine had just settled against, usually within one to ten seconds — leaving the user's order history and the chart permanently disagreeing about the same minute, with nothing that could reconcile them afterwards.

Once the binary engine publishes the close it settles against, that value is now fixed for the rest of that minute. Later market-maker writes still update the candle's high, low and volume, and the high and low are widened rather than replaced, so no malformed candle is written and nothing is lost. The claim is shared across every process the backend runs, so it holds no matter how the backend is deployed.

Order history and the chart now agree.

The Binary AI Engine's only lever over the market price did nothing

When the binary engine wants to steer an ecosystem market's price toward a target, it has exactly one lever. That lever wrote the requested target into the market's configuration and stopped there — the price path never read it, so the market was never moved a single time.

Steering is live now. A requested target is applied as a bounded drift over roughly five minutes rather than a visible ramp, capped at 6% of price so the tape does not become readable. Binary options on ecosystem markets therefore settle against a price the engine can genuinely influence.

When the market's configured price range clamps the request, that is now reported back and logged instead of being silently swallowed. The audit entry used to record the price that was asked for regardless of whether the market was ever moved toward it; it now records what was requested and what was achieved.

Bot liquidity could never be withdrawn from the public book

On markets configured to place real liquidity, a bot's order could be placed but never cancelled. The engine recorded a timestamp of its own for the order rather than the one the order was actually created with, and the cancel then matched no order at all.

What operators saw was ladders of identical small levels at round prices that nothing backed and nothing could remove, surviving restarts. Bot liquidity is now genuinely withdrawn when it should be.

Applies to markets with a real-liquidity percentage above zero.

Risk limits that had never run

Daily loss limits, the loss auto-pause and the circuit breaker had never run

The addon's trade-level risk layer existed in full — a per-trade risk assessment, a per-market loss limit, a global circuit breaker, a volatility-proportional reduction in trade size — and nothing called any of it. The risk level and global loss percentage shown to operators were not measurements of anything.

A market's Max Daily Loss was in the same position from a second direction: it presented as a working safety limit for the entire life of the addon while protecting nothing, because the daily profit-and-loss figure it compared against was summed from a value no part of the platform has ever written. It was always exactly zero, so the limit was never reached, no matter how badly a market performed.

All of it is wired now. Risk is assessed before every trade, the outcome of every trade is reported back, daily loss is measured from each bot's running realised total against a baseline taken at UTC midnight, and the figures on the risk panel are real.

The behaviour changed where it was wrong, too. Five consecutive losses used to trip the global breaker and gate every market on the platform on one market's bad run. A market that loses more than its own limit is now paused on its own, and only a book-wide loss halts everything. The global loss percentage was a currency amount divided by 100 and labelled a percent; it is a real percentage of capital now.

Only fills against real users produce a profit or loss — a trade between two of the platform's own bots has neither, because both sides are the house — so the figures are computed per bot from real fills, which means adding or removing a bot cannot fabricate one.

Every global kill switch on the settings screen was inert

Enable AI Trading, Global Pause, Maintenance Mode and Enable Stop Loss in the AI Market Maker settings screen did nothing at all. Each was compared against a true/false value while the platform stores settings as text, so the comparison could never match no matter which way the switch was flipped. All four read as working controls and had no effect on anything.

All four now work, and accept every form the settings screen and the API actually produce: true/false, on/off, yes/no, 1/0.

Pause on high volatility never ran once, and spreads were stuck at the minimum

The high-volatility auto-pause checked a setting that does not exist on a market, so the check never ran a single time regardless of how the switch was set.

Underneath it, the engine's measured volatility was permanently zero on every market it drives. Volatility was only ever sampled inside the branch that handles a successful external exchange price — a path a synthetic market never reaches. Two features read that number: the auto-pause, and the spread the engine quotes on real-liquidity orders, which was therefore pinned at its minimum no matter how violently the price moved.

Volatility is now measured from the engine's own price on every tick and scaled to a daily percentage using the real spacing between samples, so the documented 0–100 Volatility Threshold finally means something. Both consumers are live.

A risk auto-pause changed a badge and nothing else

When a market tripped a risk limit, the only thing that happened was the status badge in the admin panel turning to Paused. The running market was never told, so it carried on trading. Clearing the pause was equally cosmetic — the market had never stopped, so there was nothing to restart, and a market that genuinely had been paused stayed paused.

Tripping a limit now stops the market, and clearing it restarts it.

Other risk changes

• A tripped circuit breaker can now be cleared without waiting for midnight. When the platform-wide daily loss limit trips, it gates every market at once and clears itself at the next UTC midnight. An operator who has resolved the cause can now clear it directly, and gets back whether the breaker was tripped, why it tripped, and whether the engine was running at all. There is no button for this in the admin panel — it is available through the API only — and clearing the breaker does not reset the daily loss figure that tripped it.
• A global pause no longer freezes every chart. With the global kill switches working for the first time, turning on Global Pause or Maintenance Mode would otherwise have halted the engine outright — every market's price frozen, every chart flat, and a visible gap the moment the pause was lifted. A global pause now suppresses trading only, so prices and charts keep advancing and nothing jumps when the pause ends. Nobody ever saw a frozen chart from this, because none of the global gates could fire before this release; this is the companion change that makes turning them on safe.

Configuration changes now reach the running market

Configuration changes did not reach a running market

Changing a market's volatility, bias, price mode, target price, price range or forced phase — or any of a bot's settings, or its status — showed a success message, updated the database, and left the running market behaving exactly as before. The change only took effect on the next full reload, which in practice meant up to 24 hours.

All of those now apply to the live market immediately.

A second defect sat behind it. The engine replaced its configuration wholesale on a refresh, while the parts of it that place orders and execute trades were still reading the copy they were handed at startup — so after the first refresh they were working from stale settings. That is why Max Daily Volume and the per-bot trade limits stopped being enforced once a market's configuration had been touched at all. The refresh now updates the configuration in place.

The bot configuration form saved almost nothing, and failed on nine of ten slider positions

Editing a bot's trade frequency, order size or risk tolerance in Bot Management showed a success message and discarded every one of those changes — the form sent names the server does not read.

Risk tolerance was worse. The slider ran 1 to 10 in whole steps while the server accepts 0.1 to 1, so nine of the ten positions were refused outright — and because the request fails as a whole, they took Max Daily Trades down with them, the one field that did work.

The form now posts the values the server actually reads, over the ranges it actually accepts, and the change applies to the running market immediately.

Preferred spread and order size variance were read by nothing

Both settings were persisted, validated and documented, and no part of the engine ever consulted either. Every bot quoted from the same fixed base spread, so all five personalities stacked onto the same two levels of the book. Risk tolerance did not affect trade size.

Preferred spread is honoured now, bounded to a sane range, so personalities quote at visibly different distances from mid. Risk tolerance scales trade size across a half-to-one-and-a-half multiplier.

Order Size Variance and Preferred Spread are also editable in Bot Management for the first time, and a change to either is recorded in the audit trail. Two tiles that could only ever read N/A — the bot's next scheduled trade and its behaviour seed — were removed.

Forcing a market phase changed a stored value and doubled the volatility

Market Phase Control on a market's configuration screen wrote the requested phase and nothing more. The running market never saw it, and the expiry the operator set was not honoured either. Forcing a phase now changes the live market, and expires when told to.

The phase change was also applying its volatility multiplier twice — once inside the price engine and once written into the market's own volatility setting — so a forced phase ran at roughly 2.25× the volatility intended. Only the engine applies it now; the market's volatility setting stays the operator's own.

Cooldown was a one-way door

Putting a bot on cooldown took it out of trading and left it there. Nothing recorded when the cooldown was supposed to end, and nothing brought the bot back, so it stayed out until an operator noticed and reactivated it by hand.

A cooldown now has an expiry — the minutes the dialog asks for, or 15 by default — and a bot returns to active on its own when it passes. Setting any other status clears the cooldown.

Activating a paused bot did nothing until the next day

A running market only ever loaded its active bots, so a paused bot had no presence in the engine to reactivate. Pausing and activating individual bots on a running market now takes effect right away.

Scheduled jobs and performance

Daily counters could be handed out twice in the same day

Two separate things reset the daily counters, and they did not agree on when the day starts. On days when the scheduled reset drifted away from UTC midnight, a market was handed a second full allowance mid-session — so Max Daily Volume and the per-bot Max Daily Trades could each be exceeded by up to double.

Both are hard daily caps now: the scheduled reset checks whether the day has already been reset before handing out a fresh allowance.

The external price deviation alert never fetched a price

The check that warns when a market's target price has drifted away from the outside world built its symbol out of a value the market does not have, so it gave up before fetching anything. It has never fired once.

Operators are now warned when a target price drifts more than 10% from the external reference. Three things were added alongside it, because the check runs every 30 seconds:

• Alerts no longer flood. A permanently offset target could previously write a record on every pass; alerts are now limited to one per market per hour.
• The price cache is useful. It expired after 10 seconds against a 30-second cadence, so it could never once be hit. It now holds for five minutes, and a symbol the exchange does not offer is remembered for an hour instead of being requested over and over.
• A slow exchange cannot carry one pass into the next. The whole pass is bounded to 20 seconds.

Two background jobs reported success while doing nothing on a fresh install

The pool rebalancer and the external price sync both required the global trading switch to be explicitly set before they would do anything — and it is not set on a fresh install. Both reported completed on every pass while doing nothing at all, until an admin happened to open and save the settings screen once. Every other scheduled job in the addon already treated an unset switch as on.

Both now do the same.

Loading the bot list scanned the entire trade history

Opening Bot Management ran an unbounded scan of the market's whole trade history, to feed three diagnostic log lines and nothing else. It is gone.

Two background jobs were also competing with the engine's per-second tick as trade history grew, which is what pushed busy markets past their tick timeout:

• The volatility calculation, which runs every ten seconds for every market, was loading every price record from the last hour in full. It now reads the most recent 200 values, and only the one value it needs.
• The analytics aggregation, which runs every fifteen minutes, was pulling every trade from the last seven days for every market to produce a figure nothing used. It has been removed.

A failed request showed a success message

A failed deposit, withdrawal, rebalance calculation, configuration save or delete showed a green success message. The screens only treated a request as failed when it broke down entirely, which is not how these failures arrive — the server returns the reason in its reply — so every one of those actions reported success regardless of what the server said.

They now report the failure and show the server's own message. A failed page load shows an error instead of an empty market list.

Covers: pool deposit, withdrawal, rebalance and wallet balance; save configuration, bias, price mode, volatility, forced phase, daily-count reset and price configuration; market delete; and the overview and market detail page loads.