Ecosystem v6.4.7

Release Date: August 26, 2026 Tags: ORDERS, OCO, TIME-IN-FORCE, TRAILING-STOP, ORDER-BOOK, CORRECTNESS

Overview

Three order instructions this engine has claimed to support for years now actually work, and an order that vanished from the Pro list can be cancelled again.

timeInForce has been declared on the orders table since the beginning and the placement path bound the literal string GTC into every row, so an order marked IOC rested until cancelled like everything else. One-cancels-other and trailing stops did not exist at all — the connector endpoint that professional counterparties read said so, in a field they price against. All three are real here, enforced at placement rather than recorded and ignored.

The fix to read first is the cancel door. The Pro terminal's open-order list is served from a materialised view that nothing repairs when an update is lost, and the cancel route demanded a timestamp only that list could supply — so an order the view had dropped could not be listed, could not be cancelled, and rested in the book holding the customer's quote with no door left, while every other reader went on showing it. Requires Core v6.7.2.

Update Instructions

pnpm updator

Restart the backend and ship the frontend build. There is no database change and nothing to run.

Added

One-cancels-other orders

A trader holding a coin wants two exits and only two: take the profit above the market, or cut the loss below it. Whichever happens first, the other has to stop existing — and placing both by hand means being awake to cancel the loser.

• Added an OCO instruction that places a resting limit and a protective stop as one order, and cancels the survivor the moment either side resolves.
• Added a single hold across both legs. Two ordinary orders would each reserve the full amount, so a trader holding exactly 1 BTC could not place an OCO on it at all — the second leg would be refused for insufficient funds against balance the first leg was holding. The resting leg takes the reservation and the protective leg is funded by its sibling, which is safe because the two must be the same side, the same market and the same size.
• The sibling's hold is released before the triggered leg is placed. Doing it the other way round refuses the real order for insufficient funds against money held by an order that is about to be cancelled anyway.
• Finding the other leg walks the account's partition to the end rather than reading one page. A busy account whose OCO limit had slipped off the first page would otherwise exit the position twice.

Time in force is enforced, not recorded

• Added real enforcement of GTC, IOC, FOK and PO. Every order placed before this release was good-till-cancelled whatever the client asked for.
• IOC takes what the book offers now and cancels the rest; FOK fills the whole amount or does not trade; PO is refused rather than filled if it would cross, because a post-only order that takes has cost its owner the maker fee it was placed to earn.
• An order with no time in force is GTC, so every existing order, every bot, the copy-trading mirror and the AI market maker behave exactly as before.
• IOC and FOK reuse the market order's existing remainder sweep rather than a new one — the same snapshot, the same copy-trading exclusion, the same refundability guard and the same ledger-durable ordering. Reimplementing it would have been four chances to get one of them wrong on a money path.

Trailing stops

• Added a stop that follows the market at a fixed distance and never moves back toward it: below the highest price seen when it is protecting a long, above the lowest when it is protecting a short.
• The distance can be a percentage or an amount in quote units, and it is capped. A trail wider than the cap is not protection — it is a stop that never fires, and the trader who set it believes they are covered while the position runs to zero.
• A stop with no trailing settings is a fixed stop, which is what every stop placed before this release is.

Monero and TON transaction history

• Fixed the chain registry entries for both, which carried a "not supported yet" refusal. It was unreachable — the master-wallet screens have always taken a different path — but it would have refused the first caller that did not know to, on chains sold as paid add-ons.
• Monero's history is read from your own wallet's transfer log rather than by address, because Monero is private by design and there is no such thing as "transactions for this address".

Changed

A market with a market maker on it cannot be bulk-deleted

• Changed market deletion to refuse while an AI Market Maker still names the market. Its pool balance, its running engine, its resting orders and its published depth all survive a row being deleted, so a cascade produced a maker that had been removed from the database while still quoting and still holding money. The market maker's own delete door unwinds it in order and reports what it could not do.

Cancelling one leg of an OCO retires the other

• Changed the cancel path to retire a protective stop whose funding leg has just been cancelled. That stop holds nothing — its funds were the hold that was released — so leaving it armed leaves an order that fires and is refused for insufficient balance, at three in the morning, on the leg a trader is relying on absolutely.
• The sibling is retired after the cancel has completed and the money is back. A failure retiring it is logged and left to the stop monitor to reconcile rather than thrown, because it must never undo a cancel that has already succeeded.

Fixed

An order missing from the Pro list could not be cancelled

The cancel route required the order's creation timestamp, which is its clustering key. That value can only come from a listing — and the listings do not all see the same orders. The Pro panel's open list is served from an asynchronous materialised view that nothing repairs when an update is lost, while the bot console, cancel-all and the matching engine read the base table.

The two facts compounded. An order the view had dropped could not be listed, so it could not be cancelled, so it rested in the book holding the customer's quote with no door left — while every base-table reader went on showing it. That is the state this route was reached in.

• Fixed the route to accept the timestamp as an optimisation rather than a requirement. Where it is absent or does not match, the order is found by id inside the caller's own partition, which can only ever find the caller's own orders.
• Fixed the two writes that followed to use the row's own timestamp rather than whatever the client sent. A formatting difference in an ISO string selected no row at all.
• Fixed the failure report for the state this route exists to avoid — the hold released and the order still open. It answers 503 and names the condition in the operator log, instead of reading to the caller as an ordinary conflict.

Diagnostics

An order doctor for the case a repair script cannot answer

fix-ecosystem-orders.mjs answers "is this order funded". It cannot answer the question that matters when an order is unreachable — resting on the book, listed by the bot console, and absent from the customer's own panel with no door left to cancel it.

• Added pnpm eco:order:doctor --order <id>, which reads all six stores that must agree about an order — the base table, the symbol view, the matcher's index, the aggregated book level, the wallet and the ledger rows — and reports which of them disagree. It is read-only.
• It also reports phantom rows: rows with no symbol, which a partial write bound to a timestamp that does not exist creates instead of updating. Such a row is excluded from the symbol view by the view's own condition, so it is invisible to every symbol-scoped read while every base-table read still returns it.