ICO Launchpad v6.2.7

Release Date: August 27, 2026 Tags: LANDING PAGE, SERVER RENDERING, LOCALISATION, TRANSACTIONS, COMPLIANCE

Overview

A landing-page release for the public token sale. The page now arrives from the server with its offerings and figures already in it, instead of shipping a screen of grey placeholders that filled itself in after the browser had painted — which is what a search-engine crawler was served too.

One consequence needs a look before you call the upgrade done. Start dates on upcoming offering cards are now read in UTC, and on an install whose offerings were scheduled from a time zone ahead of UTC a card can now advertise a day earlier than the day it was scheduled for. See Upgrade Notes.

The one backend change corrects a figure printed in a purchase note. No balance, fee, token quantity, vesting entitlement or phase supply moved. Requires Core v6.7.3.

Update Instructions

pnpm updator

Restart the backend and ship the frontend build. There is no database change and no configuration.

Upgrade Notes

Start dates on upcoming offering cards are now read in UTC

Nothing was repaired here, and the day printed on a card can move. Before this release the card never rendered on the server at all, so its date was only ever drawn once, in the visitor's own browser and in the visitor's own time zone. What changed is which calendar day the card names. Start dates are captured through a day picker, so the instant recorded for an offering is the creator's local midnight — a creator two hours ahead of UTC who picks 1 September records ten in the evening on 31 August UTC. Read in UTC, that offering's card now advertises 31 August to every visitor in the world: one day earlier than the day the creator picked, and one day earlier than the same offering's date on the offerings list, on the offering detail page and on the creator's own screens, none of which changed.

• Changed the start date on an upcoming offering card to be read in UTC rather than in each visitor's time zone.
• If your offerings are scheduled from a time zone ahead of UTC, open the landing page after upgrading and compare the advertised start day on each upcoming offering against the day it was scheduled for. If it now reads a day early, this change is why.
• At or behind UTC the effect is the opposite: cards that used to read a day early to visitors further west now agree with the scheduled day for everyone.

Changed

Number grouping on the token sale landing page

• Changed the figures on the landing page — total raised, investor and participant counts, and each upcoming offering's target — to group in the US style for every visitor rather than following the convention of the visitor's own browser. On a non-English install these now read 1,234,567 where they previously read 1.234.567. A single fixed grouping is what keeps the newly server-drawn HTML identical to what the browser paints over it.

Fixed

A landing page of grey placeholders

Every visit to the public token-sale page was served the page's waiting state as HTML — pulsing grey bars where the hero figures, the four headline metrics and three featured offering cards belong — because the page could only ask for its data after the browser had already painted it. The real payload arrived a beat later and the placeholders were swapped for content. Those placeholders were measured against what they stood in for, so the top of the page held still; what did move was anything whose settled size differs from one row of three cards — a fourth offering onwards, the "View all projects" button appearing, and, on an install with no activity at all, the hero figures and the entire metrics strip vanishing. Search-engine crawlers received that same empty page.

• Fixed the landing page to fetch its offerings and figures on the server, so visitors and crawlers receive the finished page.
• If the backend cannot be reached during the server render the page falls back to exactly the old behaviour — it fetches from the browser and fills itself in — and an outage is still told apart from an install that genuinely has no offerings open.

A purchase note claiming the wrong decimal scale

A purchase record's note stores the token's decimal scale and a raw token figure computed from it. A token whose ecosystem record legitimately declares zero decimals had that zero rewritten to eighteen, so the note claimed a scale the token does not have and the raw figure was inflated by a factor of a billion billion. Nothing about the purchase itself was wrong — the amount debited from the buyer's wallet, the fee, the token quantity credited, the vesting entitlement, the phase's remaining supply and every notification all use a separate figure that never touches the decimal scale, and no calculation anywhere in the product reads the note back. The note is on display, though: it is printed word for word in the Notes tab of the buyer's own transaction page and of the admin transaction page, and in the expandable Notes panel of both admin transaction lists.

• Fixed the decimal scale recorded on a purchase to use the token's own declared value, including zero.
• Purchases recorded before this upgrade keep the inflated figure in that text, so a buyer opening an old purchase of a zero-decimal token still sees a raw figure far larger than the tokens they actually hold. Because nothing was ever derived from it, no balance, fee or supply number needs correcting.

Removed

The "Compliance — Guaranteed" claim on the About page

• Removed the Compliance: Guaranteed badge from the ICO About page hero, leaving Security: First and Transparency: Always. It was a translated string, so that unqualified guarantee had been on display to customers in all 90 shipped languages, not just English.
• The paragraph beneath the badges still describes the platform as secure, transparent and regulated, so an operator auditing what their site promises should review that sentence separately.