The investor flow
What a user must satisfy to contribute, how the amount and fee are taken, what the receiving address is checked against, and what every contribution status means to the person holding it.
An investor browses /ico/offer, opens an offering, enters an amount and a
receiving address, and confirms. Everything after that is the platform moving
money and the project moving tokens.
What has to be true before the button works
Eight checks run before a single figure is calculated, in this order. Each has its own message, so the one a user quotes tells you exactly where they are stuck.
| Check | Failure message |
|---|---|
| Signed in | Unauthorized |
KYC feature purchase_ico satisfied |
The platform's standard KYC-required error |
| ICO maintenance mode is off | Token sales are temporarily unavailable while the platform is under maintenance. |
| Not the offering's own creator | You cannot invest in your own offering |
Offering is ACTIVE |
Offering is <status>. Only active offerings can receive investments. |
| Offering is not paused | This offering is paused and is not accepting investments. |
| Start date has passed | Offering has not started yet |
| End date has not passed | Offering has ended |
Approval sets an offering ACTIVE immediately, whatever its start date. An
offering can therefore appear in the Active list, with a live-looking progress
bar, and refuse every contribution with "Offering has not started yet" until its
start date arrives. That is expected; it is not a fault.
The receiving address
The buyer supplies the address the tokens will be sent to. It is validated against the offering's blockchain:
| Chain value | Accepted format |
|---|---|
ethereum, bsc, polygon |
0x followed by 40 hex characters |
bitcoin |
bc1… or a legacy 1/3 address |
solana |
32–44 base58 characters |
| anything else | 20–128 characters with no whitespace |
A buyer who pastes an exchange deposit address, a contract address or somebody else's wallet gets no warning, and the tokens go where they said. The platform does not own the token, cannot reverse the transfer, and has no way to detect it.
Say so on your terms page. This is the single most common way a real user loses their allocation.
Limits and fee
Four platform-wide numbers apply to every offering:
They are read fresh on every purchase, so a change takes effect immediately. All four are in the offering's purchase currency, which means a 10 minimum is a very different thing on a BTC-denominated sale than a USDT one — the numbers are not converted.
The per-user total counts PENDING, VERIFICATION and RELEASED
contributions. Rejected and refunded ones drop out, freeing the headroom again.
A 1,000 contribution with a 2% fee debits 1,020. The balance check is against
amount + fee, and a buyer who has exactly the contribution amount is refused
with the required and available figures spelled out.
Setting the fee to 0 is honoured as written — it is not treated as "unset" and
does not fall back to a previous value.
What happens on confirm
Everything below runs inside one database transaction. Either all of it happens or none of it does.
-
The selling phase is located and locked — the lowest-sequence phase with tokens left. Its price is the price charged, whatever the offer page said a moment ago.
-
The token amount is calculated as
contribution ÷ phase price, and checked against the phase's remaining tokens and against the offering's target. -
The wallet is located and locked. It must already exist in the offering's currency and wallet type; there is no auto-create on this path. A buyer without one is told:
No <type> wallet found for <currency>. Please create a wallet first. -
The contribution row is written with status
PENDING, recording the phase, the price, the token amount, the receiving address and the fee. -
The vesting schedule is materialised, if the offering vests. See Vesting.
-
The wallet is debited for the contribution plus the fee.
-
The fee is credited to the platform, if it is non-zero.
-
The principal is credited to escrow — the Super Admin wallet.
-
The phase's remaining tokens are decremented and the participant count incremented if this is the buyer's first contribution to this offering.
After the commit — and only after — emails go to the buyer and the creator, in-app notifications are raised for both, and affiliate rewards are processed for the buyer's referrer.
Everything after the commit is wrapped so that an SMTP hiccup cannot report a completed purchase as an error. If a buyer says they were charged but got no email, the purchase succeeded — check their dashboard, not their inbox.
Retries are safe. The wallet debit is keyed on the contribution row's own id, so a resubmitted request resolves to the same wallet operation rather than debiting twice.
What the investor sees afterwards
/ico/dashboard is the personal view: a portfolio overview, an investment list,
a performance chart, a transaction tab and — where relevant — a vesting tab.
/ico/transaction is the full history, with a detail page per contribution.
The status on each row is the whole story:
| Status | What to tell the user |
|---|---|
PENDING |
Paid. The project has not sent the tokens yet. |
VERIFICATION |
The project has sent tokens and submitted a transaction hash; the platform is checking it. |
RELEASED |
Verified. Check the receiving wallet — the tokens are on-chain, not on the platform. |
REJECTED |
The delivery was refused. The contribution has been refunded. |
REFUNDED |
The sale failed or was cancelled, or an operator refunded it. The money is back in the wallet it came from. |
The token being sold is not a platform asset. There is no wallet on the site that will ever show it. A verified contribution means the transfer happened on the chain the project named, to the address the buyer gave.
This is the second most common support ticket after wrong addresses. Say it on the offer page, not just in the terms.
Refunds
There are three ways money comes back, and none of them require the investor to do anything.
The sale failed. When an offering ends below the soft cap, the hourly cron
marks it FAILED and refunds every outstanding contribution in the same pass.
The buyer is notified and the money is in their wallet.
The delivery was rejected. An operator refusing a hash refunds that single contribution, puts its tokens back in the phase that sold them, cancels any vesting behind it and re-counts participants.
A manual refund run. The offering's creator, or an administrator, can sweep
an offering at /ico/refund/process. It is refused for any status other than
FAILED or CANCELLED — you cannot hand back money on a running sale.
A refund eligibility view is available to the creator, any administrator, and anybody holding a contribution in the offering. It reports whether the offering is eligible, why, and the counts behind it.
The ledger is the authority: one completed refund against a contribution id means the buyer has their money, and every refund door checks for it before paying. A contribution an operator already rejected is skipped by a later failure sweep rather than paid again.
What the investor cannot do
- Cancel a contribution. There is no withdrawal path from a live sale. Once the money is in escrow, only the sale's outcome or an operator moves it.
- Change the receiving address. It is recorded at purchase and copied into the vesting snapshot. A buyer who used the wrong address needs the operator to reject the contribution — before the creator sends anything.
- Buy across a phase boundary. A purchase larger than the current phase's remaining tokens is refused outright rather than spilling into the next phase at the next price.