Token ICO v6.2.4

Release Date: August 11, 2026 Tags: OFFERS, PHASES, INVESTMENTS, VESTING, REFUNDS, ESCROW, PORTFOLIO, LAUNCH-PLANS, COMPATIBILITY, RELIABILITY, BUG-FIXES

Overview

Two of the fixes in this release move money, and both live in what happens to a sale that misses its soft cap. A failed offering handed every contributor the whole purchase price back — including those whose tokens the creator had already sent on-chain, who kept the tokens and the money. Separately, deleting an unsold phase from a live offering could push its end date into the past, which the settlement job reads as a finished sale: below its soft cap it was failed and every investor refunded, out of an admin's tidy-up.

Two more are quieter. The step that unwinds a half-finished action could fail on its own and become the answer — stopping the settlement sweep at the first offering it could not settle, and answering with an internal error on a refund run and an admin offer edit that had both already been saved. And a launch plan's team member and roadmap allowances were not applied at all on some databases, so the paid tiers bought a creator nothing.

Refunds you have already paid may need checking — see Upgrade Notes. The shared cleanup step ships in Core, so update Core first. Requires Core v6.6.3.

Update Instructions

pnpm updator

No settings to change. Two refund behaviours are different afterwards, a launch plan limit now holds that did not before, and some existing records are worth a look — all covered below.

Upgrade Notes

• If an offering has failed and been refunded while its contributors were already taking delivery of tokens, check those refunds. Each of those buyers was paid the full purchase price and kept the tokens already sent to them; the creator sent those tokens and has nothing to show for it. You are looking for contributions marked refunded on a failed offering that have released vesting tranches recorded against them. Refunds written from now on record how many tokens were delivered and how many the refund covered; rows refunded by the old code carry only the amount.
• Those same refunds put the buyer's entire allocation back into the phase's remaining supply, including the part already delivered. Check the remaining supply on the phases of any offering that has been through a refund before you sell from it again — it can be advertising tokens that are already in somebody's wallet.
• If a refund run on a failed offering ended in an internal error, check whether it had in fact paid. The error could be raised after the refunds were committed, so those contributions may already be marked refunded and the money already gone. Running the refunds again is safe either way: a contribution that has already been paid back is skipped rather than paid a second time.
• If the settlement sweep has been reporting a failure, look at the offerings that were due to end after the one it named. A failure it could not recover from ended the whole run, so offerings later in the list were left active past their end date and offerings due to start were left waiting. They will settle and start on the next run after the update.
• Check whether any offering carries more team members or roadmap entries than its launch plan allows. Those two allowances were not being applied at all on installs whose database hands stored lists back as raw text, so a creator could add as many as they wanted whatever plan they had paid for. Nothing already recorded is removed; the limit is applied to the next addition, so a creator who is over their allowance will be refused until they delete some or move up a plan.

Fixed

A failed sale refunded money for tokens the buyer had already received

A contribution moves into verification the moment the creator records its first vesting tranche on-chain, and verification is one of the states a collapsed sale refunds. A schedule with a day-one unlock — an ordinary arrangement, and the release date is allowed to be the purchase date — therefore had part of the tokens in the buyer's wallet before the sale had even closed. When the sale then missed its soft cap, the sweep paid back everything they had contributed.

• Fixed a failed offering refunding a contributor in full for tokens that had already been delivered to them. A contributor is now paid for the tokens they did not receive, at the price they paid for them, and what they were sent is netted off.
• Fixed the same refund returning the buyer's whole allocation to the phase's remaining supply. Only the undelivered tokens go back; tokens that have left on-chain cannot be sold to anybody else.
• Added the delivered and refunded token counts to the refund record kept against each contribution, so support can answer "why did I get back less than I paid?" without rebuilding the vesting schedule by hand.
• A contribution an admin has rejected is still refunded in full, deliveries and all. Rejecting a contribution is a statement that the recorded delivery did not really happen, and that door already paid the whole amount.
• A contribution whose tokens were delivered in full is now passed over instead of paid. It keeps its current status rather than being marked refunded, and the run writes a log line naming it as fully delivered so it is not mistaken for a refund that failed.

Deleting an unsold phase could end the sale and refund every investor

The offering's end date is recalculated as its start date plus the durations of the phases that remain, which can land behind today. A sale forty days into a sixty-day run whose remaining phases add up to twenty days gets an end date twenty days in the past, and removing the last phase collapses it all the way back to the start date. Nothing downstream treats that as an edit: the settlement job sweeps every active offering whose end date has passed, and a sale under its soft cap is failed and refunded to every contributor on the spot.

• Fixed deleting an empty phase from a live offering ending the sale immediately and unwinding everybody's investment. The delete is now refused when it would move the end date into the past, and the refusal names the date it would have moved to, so the remaining phases can be extended deliberately first.

An action that had already been saved could still answer with an error

These routes save their record, commit it, and then keep working — reading the record back, notifying somebody. If any of that stumbled, the error handler tried to undo a transaction that had already been committed. That undo fails on its own, and its failure is what the caller received: an internal server error naming a database transaction state, on an action that had gone through. Where a route had already been taught to skip the undo after its commit — an investor's contribution and a creator's vesting tranche among them — the same handler still fired when the commit itself failed, and replaced the real cause with the same unreadable message.

• Fixed the settlement sweep stopping at the first offering it could not settle. Each offering is settled in its own transaction so that one collapsed sale cannot hold up the rest; when one of those failed, the recovery step failed too and took the whole run with it, so no later offering was settled and no offering due to start was activated. A failure is now recorded against that offering and the run carries on.
• Fixed a refund run on a failed offering answering with an internal error after the refunds had been paid and the contributions marked refunded. The notification that goes out once the run is committed was not shielded, and a failure there was reported as a failed run.
• Fixed an admin's edit to an offering answering with an internal error after the edit had been saved — so an operator who re-applied a change they believed had not taken was editing a record that already carried it.
• Changed every launchpad route that opens a database transaction onto the same shared undo step, so a failure now answers with what actually went wrong instead of a transaction state. That covers an investor's contribution, a creator launching an offering, a submitted release hash, a vesting tranche release, an admin creating an offering, adding or deleting a phase, saving the launchpad limits and acting on a contribution. None of those has been found reporting a completed action as failed; they are changed because the same handler stood between a real failure and its message.

Offering pages and launch plan limits depended on which database you run

An offering's stored lists — its milestone delivery schedule, the attachments on a project update, and the allowances that come with a launch plan — are all held as JSON. Some database servers hand those back already unpacked and others hand back the raw text they were saved as, and nothing in your configuration tells you which you have. A screen written for one of the two answers was right on one installation and wrong on the next, with no difference between them a support conversation could find. They are now unpacked once on the way out of the database, so every screen gets the same answer everywhere.

• Fixed the team member and roadmap entry allowances that come with a launch plan not being applied at all where the raw text came back. The cap read as no cap, so a creator on the cheapest plan could add as many team members and roadmap entries as they wanted and the paid tiers bought them nothing. Both limits now hold on every install — see Upgrade Notes before a creator hits one.
• Fixed an offering that delivers its tokens at milestones telling a prospective buyer that the tokens arrive at set milestones and then naming none of them, on the same page the buyer decides to contribute from.
• Fixed the attachments on a creator's project update never appearing, and the edit form for that update opening with none attached — so a creator who went back to reword an update saved an empty attachment list over the files, and they were gone from the record for good.
• An offering's links and its use of funds are held the same way, but the public offering page already unpacked both in the browser before drawing them, so what a buyer saw was right on either database and is right still. The admin offering view unpacks the use of funds a second time on its own, and now falls through to printing the entries run together into one word — where the database served raw text that panel used to show them as separate tags, and where it served them unpacked it has been running them together all along.

The investor portfolio showed a loss on a portfolio that had lost nothing

Profit and loss was the value of the released holdings minus everything contributed. A contribution still awaiting release has no market value yet and contributes nothing to that value, so each one was counted as a total loss: $1,000 released at par beside a $500 contribution awaiting release read a loss of $500 and −33.33%, with a red arrow, on a portfolio that had lost nothing at all.

• Fixed the portfolio's profit and loss counting every un-released contribution as a loss. It is now measured against the released holdings only, which is the same basis the current value is built on.
• Fixed the figure printing without its sign, which left the colour and the arrow as the only things separating a loss from a gain of exactly the same size — nothing at all in a screenshot, a high-contrast theme, or for a colour-blind reader.

The Total Tokens card added up different tokens

The card summed the token quantities of every released contribution whatever offering they came from, so 1,000 of one token plus 5,000 of another printed as "6,000" of nothing. The list behind it is fetched fifty rows at a time, so an investor with more transactions than that was reading a partial figure presented as a total as well.

• Fixed the card adding quantities of unlike tokens together. It now shows the quantity with its symbol when the holdings are all one token, and how many offerings they span when they are not.
• The fifty-row fetch is unchanged, so a single-token quantity can still be short of an investor's full history. What it can no longer be is a sum of unlike things.

Portfolio totals left out assets the platform cannot price, without saying so

The portfolio figures exclude any offering whose purchase currency has no usable USD rate rather than guessing at one, so every total is a lower bound whenever that happens. The screen did not mention it, and a holder of an unpriced offering read a short total as a complete one.

• Added a line beneath the portfolio cards naming the currencies left out of the totals, shown only when there are any.