AI Investment v6.1.1

Release Date: July 28, 2026 Tags: SECURITY, MONEY FLOW, ADMIN, DATA LOSS, REPORTING, PRIVACY, KYC, DESIGN

Overview

Version 6.1.1 makes the addon safe to operate. Cancelling an investment was impossible, deleting a duration destroyed the live investments that used it along with the users' money, deleting a plan stranded them forever, and several admin actions paid a second time or paid a rate the platform never advertised.

Settled investments now also reach platform profit and loss, and an investment can require a verification level before it opens.

Two of the steps below look for records a past deletion has already damaged. Run them.

Requires Core v6.5.8.

Update Instructions

pnpm updator

Then, in this order:

1. Find investments stranded by a past plan deletion

SELECT i.id, i.userId, i.amount, i.symbol, i.createdAt
FROM ai_investment i
LEFT JOIN ai_investment_plan p ON p.id = i.planId AND p.deletedAt IS NULL
WHERE i.status = 'ACTIVE' AND i.deletedAt IS NULL AND p.id IS NULL;

Any rows returned are investments whose plan was deleted while they were live. Before this release the hourly settlement run failed on every pass over them, so they looped forever: permanently ACTIVE, principal locked, invisible to the user as anything but a stuck investment.

No manual action is required. Settlement now clears them as a DRAW — the principal is returned in full and no profit is invented from a plan that no longer exists. They will clear on the next hourly run. Run the query first only so you know which users to expect a refund for.

2. Check for investments destroyed by a past duration deletion

SELECT id, duration, timeframe FROM ai_investment_duration;

Before this release, deleting a duration permanently removed every investment that referenced it. Those rows are gone and cannot be recovered. If you suspect this happened, the funding debits survive and are the only remaining record:

SELECT t.userId, t.amount, t.currency, t.createdAt, t.referenceId
FROM transaction t
LEFT JOIN ai_investment i ON i.id = t.referenceId
WHERE t.type = 'AI_INVESTMENT' AND i.id IS NULL;

Each row is a user who was debited for an investment that no longer exists. Reconciling them is a manual decision; this release makes the deletion impossible going forward but cannot undo one that already happened.

3. Restart the backend

Optional: MAIL_DISABLED

MAIL_DISABLED=true in .env stops the platform attempting any outbound delivery. Useful when exercising these flows, since settlement emits a completion email per investment. Leave unset in production.

Upgrade Notes

Breaking changes

None in setup. Two pieces of information were deliberately withheld, and two behaviours changed:

• A plan's configured outcome and default profit are no longer sent to users. They are admin-only, matching how forex plans have always behaved. The advertised profit percentage is what users see.
• The result, return rate and profit of an active investment are withheld until it settles. All values appear as normal once it does.
• Deleting a plan or duration that any investment references is now refused. Deactivate instead.
• Deleting an investment no longer refunds unconditionally — only when the principal is genuinely still outstanding.

Added

Verification level can be required to open an AI investment

Operators who enforce per-feature verification can now require a verification level before a user opens an AI investment. The purchase panel shows what is required in place of the form, and a purchase attempted anyway is refused with the same explanation.

• To turn it on: enable KYC Verification, then Enforce KYC Feature Access (Admin -> Settings -> Features, under Verification). Both are needed, and the second is off by default.
• To grant it: tick AI Investments on each verification level that should be allowed to invest, in the level builder under Admin -> CRM -> KYC.
• Nothing changes by default. With enforcement off, every signed-in user invests exactly as before.

Changed

Settled investments are now booked to the platform's profit and loss

Every settlement now records the platform's own side of the bet, not just the user's. Before this release the addon wrote only the user's leg, so a desk could run thousands of AI investments and none of them would appear in platform revenue reporting at all — no cost when it paid a profit out, no revenue when it kept a forfeited stake.

• A win records the profit paid to the user as a platform loss.
• A loss records the forfeited part of the principal as platform revenue.
• A draw records nothing — the principal is returned and nothing else changes hands.
• Applies to both automatic settlement and the admin Complete action. Both write the same entry, so it no longer matters which one settles an investment.

Fixed

Deleting a duration destroyed live investments and the users' money

The admin "delete duration" action permanently removed every investment using that duration, including live ones whose principal had already been taken from the user. The money was gone: no refund, no investment record, and nothing on any screen to reconcile against. One click, no confirmation beyond the standard delete prompt.

• Fixed so that deletion is refused while any investment uses the duration, and says how many. Deactivate it instead so it stops being offered while existing investments run their course.
• Applies to both the single and the bulk delete action.

Deleting a plan stranded live investments forever

Deleting a plan did not remove its investments, but settlement could no longer read the plan's terms — so every affected investment failed on every settlement run, forever. Permanently active, principal locked, and unrecoverable from any screen.

• Fixed in two places: plan deletion is now refused while investments depend on it, and settlement no longer depends on a plan that is gone. An investment already orphaned by an earlier deletion settles as a draw — principal returned in full, no profit invented — instead of looping.

Cancelling an investment was impossible

Every cancellation failed with "Validation error". No user could ever cancel an AI investment, and no admin could cancel or reject one. The principal was not lost, but the money stayed locked until the investment matured.

• Fixed so that cancellation works from both the user and the admin side.

Deleting an investment refunded the principal a second time

The admin delete action refunded the original amount without checking the investment's state. Deleting an investment that had already paid out refunded the principal again, on top of the payout the user had already received. Deleting one the user had already cancelled refunded it a third time. The bulk action did the same for every investment selected.

• Fixed so that a refund is issued only when the principal is genuinely still outstanding.

"Restore" permanently destroyed the record and issued a refund

The admin table's Restore action on a cancelled (already-refunded) investment ran the delete path instead — permanently destroying the record and crediting the principal again.

• Fixed so that restore restores.

Deleting an investment erased the audit trail

Deleting an investment destroyed its original funding record, leaving a refund in the ledger with no matching charge — a payment that appeared to come from nowhere.

• Fixed so that the funding record is preserved.

Admin "Complete" paid a different rate than the automatic settlement

The admin completion action and the automatic settlement read two different profit fields on the plan. Whenever those two differed, the same investment paid a different amount depending on which one completed it. Admin-completed investments were also recorded in an older format that later screens read incorrectly.

• Fixed so that both use the same rate and record it the same way.

The AI Investments tab was permanently empty

The tab showed nothing regardless of how many investments the user held.

• Fixed so that the tab lists them. Note that the tab is part of the Pro trade workspace; the standard trade panel has no AI tab.

"Expected profit" quoted a rate the platform does not pay

The purchase panel calculated the expected profit from a different field than the one settlement actually pays, while the plan card next to it showed the correct figure — so the same screen could display two different numbers, and the one shown against the amount was the one that would not be paid.

• Fixed so that the display uses the rate that is actually paid.

A cancelled investment was still recorded as active

An investment cancelled by the user was indistinguishable from a live one in reports, and the admin overview's cancelled count never counted them.

• Fixed so that cancelled investments are recorded as cancelled.

Editing a plan retroactively changed what running investments would pay

Nothing about the deal was recorded on the investment at purchase, so settlement re-read the plan hours or days later. An admin changing the plan's profit rate or outcome silently rewrote the terms of every investment already running. A user could be quoted one figure at purchase and paid another.

• Fixed so that the payout rate and the outcome are recorded on the investment when it is created, and the quote is binding. Investments created before this release have no recorded terms and continue to settle from their plan, exactly as before.

An active investment disclosed its outcome before it settled

Because the terms are now recorded at purchase (see above), the investment knows whether it will win or lose from the moment it is created — and that was being sent to the browser for investments that had not matured yet. The plan's configured outcome was also visible, which meant the answer could be read before an investment was even placed. The screen showed "-" for an active investment, so it looked right while the data behind it did not.

• Fixed so that the result, the return rate and the profit are withheld while an investment is active, and the plan's configured outcome is never sent to a user at all. Everything is disclosed as normal once the investment settles: this is about timing, not about hiding what a user was paid.

The bulk status action changed status without paying anyone

It flipped live investments to Completed with no payout and to Cancelled with no refund, and automatic settlement then skipped them forever. The record said the investment had been completed and the user was never paid. It also allowed a completed investment to be moved back to active and paid a second time.

• Fixed so that both status actions pay or refund properly. The bulk action reports which investments succeeded and which failed, and errors rather than claiming success when nothing moved.

The admin investment edit form could never save

Every save was rejected.

• Fixed so that the form saves. It still refuses changes to the amount and the owner, and now also refuses the wallet type (the principal was taken from the original one) and the status (use the status action, which pays or refunds with it).

The edit drawer's Status and Type selects were silently discarded

Both were shown as required fields and neither did anything. An admin could set "Completed", save, see a success message, and nothing would happen — no status change and, more to the point, no payout.

• Fixed by removing both from the edit form. Status changes go through the status action, which moves the money with them.

The admin dashboard counted losses as profit

Losses were added to the platform's profit figure instead of subtracted. On one database this was checked against, the reported total was +1102 where the true figure was −48.

• Fixed so that wins add, losses subtract, and draws contribute nothing.

A failed balance lookup was displayed as a zero balance

When the wallet could not be read, the panel showed "Available 0.00" as a fact and blocked the form with "insufficient balance". An outage was indistinguishable from an empty wallet.

• Fixed so that a failed read is shown as "unavailable", loading is distinguishable from both, and trying to invest while the balance is unknown explains why rather than telling the user they are short of funds.

A failed admin dashboard load was displayed as a dashboard of zeros

When the AI Investment admin dashboard could not load its figures, it rendered every one of them as 0 — no error, no message, nothing on screen to say the numbers were not real. A platform with a failed load was indistinguishable from one that had never sold an investment.

• Fixed so that a failed load is shown as a failure, with the reason and a Try again button.

Cancelling could collide with the maturity payout

A cancellation arriving at the same moment as the automatic payout could refund a principal that had already been returned — crediting the user twice.

• Fixed so that whichever arrives second sees the other and stops.

Smaller corrections

• Fixed an already-paid investment failing settlement every hour. An investment whose payout had already been recorded — for example one an admin completed and the old bulk status action then moved back to active — failed on every hourly settlement run instead of clearing, so its status stayed active and its principal stayed locked indefinitely. Settlement now treats an existing payout as proof the money was already paid: the investment is marked completed and is not paid a second time. Anything already stranded that way clears on the next hourly run, and the status action now refuses to move an investment that is not active, so nothing new can enter this state.
• Fixed an admin duration list that could be read by any signed-in user. The admin list of configured investment durations checked only that the caller was signed in, not that they held a staff permission, so any signed-in account that requested it directly could read it. It now requires the same duration-viewing permission as the other duration screens. The exposure was small: the list holds duration labels such as "30 DAY" and nothing else — no customer, account or financial data — and the same durations are already published to users for active plans.
• Fixed the admin screens ignoring the platform theme. The dashboard's hero, headings and figures, the investment status and WIN/LOSS/DRAW badges in the admin tables, and the plan tag chips were all drawn from fixed colours of their own, so a customised theme was ignored and the same status could be one colour here and another elsewhere in the admin area. They now use the active theme and the platform-wide status palette, the dashboard uses the same stat tiles as every other admin dashboard, and figures are set in tabular numerals so columns of numbers line up. Three hues change as a result: Active is green rather than amber, Cancelled is red rather than grey, and Draw is neutral rather than amber; Win and Loss are unchanged. Purely visual — no figure and no behaviour changes.