Phases and pricing

How the selling phase is chosen, why phase durations are display-only, the two independent caps that can end a sale, and what soft cap failure does to every contribution.

5 min readUpdated 3 August 2026phases, pricing, soft-cap, target

A phase is a tranche of tokens at a fixed price. A sale is a list of them, usually rising in price: private round, pre-sale, public. Every contribution is priced by exactly one phase, and the row records which one.

Field	Meaning
`name`	Displayed on the offer page and stamped on every contribution made in it
`tokenPrice`	Price per token in the offering's purchase currency
`allocation`	Tokens the phase started with
`remaining`	Tokens it has left — decremented on every sale, restored on every refund
`duration`	Length in days. Display only — see below
`sequence`	Order, starting at 0

The rule that decides everything

Not the phase whose date window contains today. The lowest sequence with remaining > 0, full stop.

This is the definition the purchase route takes money on, and every screen that shows a price uses the same one. If they ever disagreed, the offer page would advertise one price and the buy button would charge another.

Two consequences follow, and both surprise creators:

A phase that sells out early hands over immediately. If the pre-sale allocation is exhausted on day three of a thirty-day window, the next phase starts selling on day three — at its own, usually higher, price. The window does not hold it back.

A phase whose window closes with stock left keeps selling. If the pre-sale still has tokens on day thirty-one, it stays the selling phase. The public round behind it does not open until the pre-sale is empty.

The durations are still meaningful, just not as gates. They do two things: they add up to the offering's end date, and they drive the "ends in N days" countdown shown per phase on the offer page.

A contribution attempt against an offering with no phase left returns "No tokens available for sale". The offering stays ACTIVE until its end date and then settles normally on whatever it raised.

Two caps, and they are independent

A sale can be stopped by either of two limits, and they are measured in different units:

Cap	Unit	Enforced
Phase allocation	Tokens	Per purchase — a contribution larger than the current phase's `remaining` is refused
`targetAmount`	Purchase currency	Per purchase — the sum of every live contribution plus this one may not exceed it

The "sum of every live contribution" counts PENDING, VERIFICATION and RELEASED. Refunded and rejected contributions drop out of it, and the tokens behind them go back on the shelf.

Nothing checks that the phases can raise the target, or that the target can absorb the phases. Both mismatches are easy to create and neither is reported:

Phases too small. Three phases of 1,000,000 tokens at 0.01 raise at most 30,000. With a target of 100,000 the sale sells out at 30% and then refuses every further contribution with "No tokens available for sale" — while the progress bar reads 30%.
Target too small. The same phases with a target of 20,000 stop taking money with two-thirds of the tokens unsold, refusing contributions with "Investment exceeds target amount. Only X remaining."

Multiply out allocation × tokenPrice for every phase before approving an offering, and compare the total against targetAmount. They should be equal, or the target should be the smaller of the two on purpose.

The last contribution into a phase is also capped by that phase alone. A buyer wanting 50,000 tokens when the current phase has 10,000 left is refused with "Only 10000 tokens remaining in current phase" — the purchase does not spill over into the next phase at the next price. They have to buy the 10,000 and then buy again.

The soft cap decides success or failure

When the end date passes, the hourly cron settles the offering:

Total raised at or above targetAmount × soft cap → SUCCESS.
Below it → FAILED, and every outstanding contribution is refunded on the spot.

The soft cap is a platform-wide percentage, not a per-offering number.

Share of an offering's target it must raise to count as funded

At the default 30%, a sale targeting 100,000 succeeds on 30,000. Change it on Admin → ICO → Settings → Investment. It applies to every offering, including ones already running, because it is read at settlement time.

The failure sweep returns every contribution still owed back — PENDING, VERIFICATION and REJECTED rows. A creator who delivered tokens on-chain to a VERIFICATION buyer before the sale failed has sent tokens and had the money handed back.

That is the correct behaviour for a failed raise, but it means a creator should not start distributing until the sale has closed successfully, unless they are willing to wear that risk. Say so when you approve a sale whose target looks optimistic.

Refunds are sourced from the escrow wallet holding the principal, credited to the buyer, and recorded as a REFUND on the ledger. Phase supply is restored and the participant count is recomputed from live contributions, so a fully refunded offering does not keep advertising its head count.

Editing phases after launch

Only an administrator can change phases, from the offering's admin page.

Adding a phase appends it after the highest existing sequence and extends the offering's end date by its duration — measured from the current end date, or from now if the offering has already ended. It is refused if:

the offering is not ACTIVE, PENDING or UPCOMING;
a phase with the same name already exists;
the resulting total allocation would exceed the token detail's totalSupply.

Because a new phase lands at the end of the sequence, it cannot be used to reprice the round currently selling. It becomes the selling phase only once everything before it is empty.

Deleting a phase is refused if a single token has been sold from it — that is, if allocation - remaining > 0. The offering's end date is recalculated from the phases that remain. It is allowed on ACTIVE, PENDING, UPCOMING and SUCCESS offerings.

Every contribution records the phase it was priced by. Rejections, failures and manual refunds all put the tokens back into that specific phase — not the first one. Without that, a rejected sale would permanently burn its allocation and the tokens could never be sold to anybody else.

Reading the numbers on the admin screens

The offer list computes currentRaised per offering by summing amount × price over live contributions, so it always matches the soft-cap maths. The per-offering funding chart on the admin detail page draws from the same rows.

If a progress bar looks wrong, check the contribution statuses first. A large REJECTED or REFUNDED balance is invisible in the raised figure by design — that money is not the project's.