ICO/STO/IDO v6.1.3

Release Date: March 6, 2026 Tags: CRITICAL FIXES, SECURITY ENHANCEMENTS, MAJOR IMPROVEMENTS

Overview

Version 6.1.3 is a comprehensive security, financial integrity, and stability release for the ICO module. It addresses critical vulnerabilities including double-refund exploits, broken idempotency in token purchases, missing authorization checks, and floating-point precision errors across all monetary fields. The update also brings significant improvements to the vesting system, admin controls, and frontend store reliability.

Update Instructions

After updating, run the following command in terminal:

pnpm updator

Changed

Financial precision

• Changed every monetary figure the addon stores — token prices, transaction amounts, vesting balances, phase allocations and supply tracking — to a fixed-precision decimal. Floating-point rounding errors such as 0.1 + 0.2 = 0.30000000000000004 can no longer accumulate in stored money.
• Changed vesting milestone calculations to precision-safe arithmetic, so drift no longer builds up when several milestone release amounts are summed.

Offering lifecycle

• Changed offering success and failure to be decided by one threshold. Three different values were previously in use: the scheduled job unconditionally marked expired offerings as successful, the phase manager used 75%, and the refund manager used 30%.
• Changed phases so they can no longer be added to a SUCCESS, CANCELLED or REJECTED offering. Adding one previously reactivated a completed offering silently.
• Changed deletion so an active offering with released transactions can no longer be removed.
• Changed offerings created from the admin screen to always start as PENDING. A caller could previously set any status, including ACTIVE.
• Changed a refund to return its tokens to the phase's remaining allocation. Refunded tokens were previously lost from the phase supply permanently.
• Changed phase allocations to be validated against the offering's total supply, so phases whose combined allocation exceeds it are rejected.

Admin controls

• Changed the admin update screen to refuse a token price change on an active offering that already has investors, protecting them from an unexpected price change.
• Changed it to refuse reducing the total supply below the number of tokens already sold, which would leave an impossible supply state.
• Changed start and end dates to be validated: the start must fall before the end, and a new offering cannot be dated in the past.
• Changed flagging so flagging an already-flagged offering, or unflagging one that is not flagged, returns an appropriate error instead of silently succeeding.
• Changed deleting an offering so it no longer removes that offering's admin activity records. Those audit entries are preserved for compliance and historical reference.
• Changed the admin transaction and creator launch screens to report the original error rather than turning every failure into a generic server error.

Data model

• Changed the offering, transaction, update, roadmap, team member and admin activity tables to carry indexes on the columns the ICO screens filter and sort by, so those screens stay responsive as the data grows.
• Changed each purchase to record the offering phase it was made against, so per-phase allocation can be tracked accurately.
• Changed new offerings to initialise consistently — pending, with no participants and not featured — and phase records now carry created and updated times for the audit trail.
• Changed six records that could be created with required fields missing, which is no longer possible.
• Changed review notes to a long-text field, so longer review content and structured data fit.

Wallet address validation

• Changed Bitcoin address validation to accept Bech32 (bc1q…) and Taproot (bc1p…) addresses in addition to the legacy formats.
• Changed a wallet address submitted for an unrecognised blockchain to return a clear validation error instead of being accepted as any string.

Other improvements

• Changed the portfolio screen to read its figures in a single database query instead of four, so the numbers on it cannot disagree with one another.
• Changed the "ALL" timeframe in portfolio performance to cover ten years rather than two, so it captures the full investment history.

Fixed

Refunds could be paid twice

• Fixed a refunded transaction staying in the rejected state, so the automatic refund processor picked it up again on its next run and credited the wallet a second time. A refunded transaction is now closed with its own status.

A legitimate repeat purchase was silently discarded

• Fixed the purchase deduplication key being built from the amount and wallet address, so a genuine repeat purchase with the same details was treated as a duplicate and dropped. Each purchase now carries its own key.

Any visitor could read any transaction

• Fixed the transaction detail endpoint requiring no authentication, so anyone could read any ICO transaction by its id, exposing wallet addresses and user data. Access is now restricted to the transaction owner, the offering creator and admins.

A failed notification crashed the purchase it followed

• Fixed the email and activity logging that run after a purchase has been committed being able to bring it down. A failure there attempted to roll back an already-committed transaction, which crashed and hid the original error. Those steps now handle their own failures.

Admin verify and reject wrote balances directly

• Fixed admin verification and rejection adjusting wallet balances by hand instead of going through the ordinary credit path. Each credit is now recorded as a wallet transaction with an audit trail, and cannot be applied twice.

Cancelling and refunding could create money

• Fixed the cancel-and-refund action refunding contributions whose tokens had already been released and whose seller had already been paid. That credited the investor while the seller kept their payment — money from nothing.

Funding totals were counted in the wrong unit

• Fixed the total raised being summed as a quantity of tokens and then compared against a target denominated in currency, so an offering was wildly over- or under-counted depending on its token price. Amount and price are now multiplied for the purchase, refund and eligibility checks alike.

Vesting releases never moved any tokens

• Fixed a vesting release marking itself complete and telling the investor their tokens were "available" without crediting anything. The tokens are now transferred to the investor's wallet.
• Fixed the claim flow looking for a status the release process never set, so a claim found nothing to claim.
• Fixed milestone schedules being accepted when their percentages did not total exactly 100%. A schedule totalling 80% or 120% was silently created.

Concurrent purchases overwrote each other

• Fixed the participant count being read and written back, so two purchases arriving together lost one of the counts. It is now incremented in the database itself.
• Fixed a phase's remaining allocation being decremented the same way, which let concurrent purchases oversell a phase against a stale figure.
• Fixed the funding-cap check not locking the offering row, so two concurrent purchases could both pass it.
• Fixed refund processing not locking the offering row, so concurrent refund requests could process the same transactions.

Frontend

• Fixed the statistics screen requesting a mistyped address, which returned a 404 that nothing reported, so no statistics ever loaded.
• Fixed purchases and transaction fetches having no loading indicator, and their errors being swallowed silently.
• Fixed the statistics view having no loading or error state at all.
• Fixed the updates, roadmap and team member caches treating an empty result as "never fetched", so every access refetched.
• Fixed the launch plan cache recording a failed fetch as a completed one, which prevented any retry after a transient error.
• Fixed token detail parsing mutating the data it was handed, which produced unexpected side effects wherever the same data was used.
• Fixed the pagination fallback missing its total, which produced an undefined error when the API returned an empty response.
• Fixed the "updates this month" filter comparing the month but not the year, so January 2025 updates appeared among January 2026's.

A single failed refund undid the successful ones

• Fixed the cancel-and-refund action rolling back the whole batch when any one refund failed, discarding refunds that had already succeeded. The batch is now rolled back only when all of them fail.