AI Investments 6.1.7
Latest12 August 2026
This release has upgrade notes. Read them before updating — they describe behaviour changes that need your attention.
AI Investments v6.1.7
Release Date: August 12, 2026 Tags: INVESTMENTS, SETTLEMENT, WALLETS, ADMIN, MONEY, BUG-FIXES
Overview
An investment opened from the admin table took no money and was paid out anyway. Add on the admin investments screen inserted an ACTIVE position without debiting a wallet and without writing a funding record — and the hourly settlement then found the customer's ordinary wallet by currency and credited principal plus profit into it. That is money the platform never received leaving the platform, on the first run after the end date.
The same lookup broke real investments in the other direction. A plan's currency or wallet type can be edited after customers have bought under it, and resolving the payout from today's plan sent every in-flight settlement looking for a wallet that never funded it — failing on every run, for ever, with the customer's principal held.
Read the Upgrade Notes and check your investment history before you decide this does not affect you. Requires Core v6.6.4.
Update Instructions
pnpm updatorUpdate Core first — the settlement rule these routes now share ships with it.
Restart the backend afterwards. There is no database migration. Investments already settled are not reversed.
Upgrade Notes
Check any investment you added from the admin screen
An AI investment has exactly one record of which wallet its principal came out of: the debit taken when it was bought. The admin Add form wrote none — it did not even pass the wallet type through, so for anyone who did not supply one the insert failed outright, and when it did land it produced a position that had moved no money at all.
Every door that settles an investment reads that debit. The manual Settle and Refund buttons already refused a position without one, by name. The hourly settlement did not: it fell back to finding any wallet of the right currency, and credited principal plus profit into it. Positions added this way therefore paid out in full on the first run after their end date, funded by nothing.
From this release an ACTIVE position added from the admin screen debits the customer's wallet, exactly as their own purchase would, and is refused if the wallet cannot cover it. Recording history — completed, cancelled or rejected positions — still moves no money, because none is owed.
- Fixed the settlement run paying principal and profit for positions that never debited a wallet.
- Fixed the admin Add form creating a live position with no wallet movement, and failing outright when no wallet type was supplied.
- Go and look at your investment history. Any position you added from the admin screen that has reached its end date was paid out of nothing — the transaction ledger shows a credit against it with no matching debit.
- Adding an ACTIVE position now requires the customer to hold the wallet and the balance. If you are backfilling records rather than opening real positions, record them with a settled status.
Fixed
An investment was stranded for ever when its plan was edited
Resolving the payout wallet from the plan rather than from the purchase meant that editing a plan's currency or wallet type broke every position already bought under it. Each settlement run looked for a wallet that had never funded them, threw, and tried again an hour later — indefinitely, with the principal held and the customer told nothing.
- Fixed settlement resolving the payout wallet from the plan as it stands today rather than from the wallet the principal actually left.
A tidied-up transaction record read as an investment nobody had paid for
Deleting a transaction row archives it rather than removing it. Settlement could not see an archived record, so an administrator tidying the transactions table made funded investments indistinguishable from unfunded ones — and the currency fallback that existed to paper over exactly this is what made the payout wrong. Archived funding records now count as the proof they are, and a wallet deleted since the purchase is re-created and paid into rather than blocking a payout the customer is owed.
- Fixed an archived funding record being treated as though the investment had never been funded.
- Fixed a payout being blocked because the wallet it was owed into had since been deleted.
Cancelling and refunding named the wrong wallet
Cancelling a position, and the admin refund, each resolved their destination independently. They now use the same rule as settlement, so a refund can only ever reach the wallet the principal came out of — and a position that never debited anything is refused with a message that says so, rather than refunding into a wallet picked by currency.
- Fixed a cancellation or refund crediting a wallet chosen by currency instead of the one that funded the investment.
- Changed the refusal messages on those doors to name the reason — never funded, or a funding record belonging to somebody else — instead of "Wallet not found".
The admin form accepted a market symbol it could not use
The market symbol on an investment is a key, not a label: it is split to work out
which wallet the position belongs to. The admin form took anything, so a symbol that
was not a clean BASE/QUOTE pair produced a position whose currency could not be
read. It is now checked at the form, as the customer-facing route already checked it.
- Fixed the admin form accepting a market symbol that is not a valid pair.