Reviewing offerings

The review queue and every action on it — approve, reject, flag, pause, feature, edit, add and delete phases, delete an offering, and the Super Admin emergency cancel that refunds a live sale.

5 min readUpdated 3 August 2026admin, review, approval, moderation

Every offering — whether a creator submitted it or you created it from the admin form — arrives as PENDING and stays invisible to investors until you act. This is the gate. Nothing behind it is automatic.

The queue lives at Admin → ICO → Offers (/admin/ico/offer), with per-status views at /admin/ico/offer/status/<status> and a detail page per offering. All of them need access.ico.offer and view.ico.offer.

What to check before approving

You are the only thing standing between your users and a project that takes their money. The platform does not verify a single claim on an offering. It does not check the whitepaper, resolve the website, look up the token contract or confirm the team exists.

Work through at least these:

The blockchain and token type are real for this project, and the blockchain's stored value is one the platform validates addresses against. A mis-valued chain means buyers' addresses are barely checked.
The phases multiply out to the target. Sum allocation × tokenPrice across every phase and compare it with targetAmount. A mismatch stops the sale early in one direction or the other — see Phases and pricing.
The end date is what the creator thinks it is. It is the start date plus the sum of the phase durations, not a field they chose.
The vesting shape is one they can actually service. Multiply tranches by expected buyers. A twelve-month linear schedule is a monthly obligation for a year, executed by hand.
The links resolve — whitepaper, GitHub, Twitter, Telegram and website are all mandatory at submission, but only their format is checked.
The soft cap is survivable. At the platform default of 30%, a sale that raises a third of its target succeeds and the creator is paid. Decide whether that is acceptable for this project's target.

The actions

All six moderation actions are the same endpoint with a different action, and all need edit.ico.offer.

Approve, reject, flag, unflag, pause or resume an offering

Action	Allowed when	Effect
`approve`	Status is `PENDING`	Status becomes `ACTIVE`, `approvedAt` stamped
`reject`	Status is `PENDING`	Status becomes `REJECTED`, `rejectedAt` stamped, notes stored as `reviewNotes`
`pause`	Status is `ACTIVE`	`isPaused` set; contributions refused
`resume`	Status is `ACTIVE` and paused	`isPaused` cleared
`flag`	Not already flagged	`isFlagged` set
`unflag`	Currently flagged	`isFlagged` cleared

Each action emails the project owner and raises an in-app notification. Rejection requires notes — the request is refused without them — and the text is included in both the email and the notification, so write something the creator can act on.

There is no scheduled-activation state in practice. An approved offering is ACTIVE the instant you click, appears in the Active list, and refuses contributions with "Offering has not started yet" until its start date arrives.

If you want an offering to appear only when it opens, hold the approval.

pause is what you use when a project is under suspicion but you are not yet ready to cancel. It is enforced on the money path: a paused offering refuses every contribution.

flag is not. Flagging marks the offering for internal attention and notifies the creator; it does not stop a single sale. If you need the money to stop, use pause.

Editing an offering

Update an approved offering's editable fields

Editable: name, symbol, icon, website, target amount, token price, start and end dates, description, blockchain, total supply and the featured flag.

Not editable anywhere: the purchase currency and wallet type, the launch plan, and the vesting terms of contributions already made.

featured is what puts an offering in the featured strip on /ico. Only ACTIVE offerings with the flag appear there.

targetAmount is both the hard cap on contributions and the basis for the soft cap. Lowering it on a live offering can put a sale instantly over its cap — no further contributions are accepted — and raising it can turn a sale that would have succeeded into one that fails, because the soft cap is a percentage of whatever the target is at settlement time.

Managing phases

Append a phase and extend the offering

Remove an unsold phase and recompute the end date

Adding a phase appends it after the last one and pushes the offering's end date out by its duration. It is refused when the offering is not ACTIVE, PENDING or UPCOMING, when the name duplicates an existing phase, and when the total allocation would exceed the token's total supply.

Deleting a phase is refused the moment a single token has been sold from it. The end date is recalculated from the phases that survive.

Because a new phase always lands last, you cannot use it to reprice the round currently selling. It becomes live only once everything before it is empty.

Deleting an offering

Delete an offering

Use this for spam and duplicates. It is not a way to stop a sale that has taken money — deleting an offering does not refund anybody. For that, use the emergency cancel below.

The foreign keys from ico_token_offering to ico_launch_plan and ico_token_type cascade on delete. Removing a plan or a type takes every offering that points at it with it, including live ones with contributors.

Disable them instead — both carry a status flag that hides them from the pickers without touching anything already using them.

Emergency cancel and refund

Cancel a live offering and refund every contributor

This is the scam-response lever. It is restricted to accounts on the Super Admin role — the check is on the role name itself, so no permission grant substitutes for it — and it requires a reason of at least ten characters, which is written to the audit trail.

It sets the offering to CANCELLED, records who cancelled it and why, and refunds every outstanding contribution: escrow is debited, buyers are credited, phase supply is restored, vesting schedules behind the refunded contributions are cancelled, and the participant count is recomputed.

Contributors whose tokens were already delivered on-chain get their money back and keep the tokens. That is unavoidable — the platform has no custody of the token and no ability to reverse a transfer.

Cancel early, or not at all. The longer a fraudulent sale runs, the more of it you are simply writing off.

What you can see per offering

The offering detail page pulls together everything the addon knows:

Funding over time, computed from live contributions.
The full contribution list for that offering, with the same actions as the transaction desk.
Every vesting schedule created under it, with a summary of what is delivered and what is outstanding.
The phases, the launch plan, the token detail and its token type.
The roadmap and the creator's update posts.
The addon's own activity log for that offering.

That log is ico_admin_activity, and it records more than admin actions despite the name: offering creation, every investment, token release submissions, vesting tranche releases, settings changes and emergency cancellations, each with the acting user and a JSON detail blob. It is separate from the platform's own audit trail. Settings changes are filed against a placeholder offering id of all zeroes, so they will not appear under any real offering — query the table directly for those.

Statistics

ICO admin dashboard statistics

The dashboard at /admin/ico needs access.ico for the page and access.ico.stat for its figures. An operator holding only the first gets a dashboard with no numbers on it.