Creating an offering

An offering is created by a creator — an ordinary signed-in user, not an administrator. They pay for a launch plan, fill in a ten-step form, and submit for review. Nothing goes live without an approval.

You can also create an offering on a creator's behalf from /admin/ico/offer/create. That path skips the payment step and nothing else: it still lands in the review queue as PENDING, and it still needs approving.

Before a creator can start

Four things must already be true, or the form dead-ends:

• Platform KYC is satisfied — the create_ico feature, if enforcement is on.
• The ICO module is not in maintenance mode.
• At least one active launch plan, blockchain and token type exists.
• The creator holds enough balance in the plan's currency and wallet type.

If a creator reports that the first step is an empty dropdown, the reference tables have not been seeded. See Install.

Step 1 — the launch plan

The plan does far more than set a price. It decides:

• The launch fee, charged from the creator's wallet when they submit.
• The currency and wallet type of the entire sale. The plan's currency and walletType are copied onto the offering as purchaseWalletCurrency and purchaseWalletType. Every investor contributes in that currency, escrow holds that currency, and the creator is paid out in it.
• Three hard limits: the maximum number of team members, roadmap items and offering phases.

Everything else in the plan's feature block — support level, marketing support, audit included, custom tokenomics, priority listing, maximum update posts, a kycRequired flag — is displayed on the plan card and enforced by nothing. Treat it as the sales copy for a service you deliver by hand.

Steps 2 to 7 — the project

Step	What it captures	Constraints that are enforced
Token Details	Name, symbol, icon	Name ≥ 2 characters; symbol 2–8 characters, uppercased on save
Token Configuration	Token type, blockchain, total supply, description	Description 50–1,000 characters; token type must be an existing UUID
Token Resources	Whitepaper, GitHub, Twitter, Telegram, use of funds	All five are required, and the four links must be valid URLs
Team Members	Name, role, bio, socials	Bio ≤ 500 characters; count capped by the plan
Roadmap	Title, description, date, completed	Description ≤ 1,000 characters; count capped by the plan
Contact Information	Project website	Must be a valid URL

The blockchain chosen here is the one every buyer's receiving address is validated against, and the one the creator's delivery hashes are checked against. See Install for why the blockchain's stored value matters more than its name.

totalSupply is recorded, and copied into tokensForSale as-is. It is not compared against the phase allocations at launch — that check exists only on the admin "add phase" route, which refuses a phase that would push total allocation past totalSupply.

Step 8 — the offering structure

This is where the sale is actually defined: a target amount, a start date, the phases, and optionally a vesting schedule.

Each phase carries a name, a token price, an allocation in tokens, and a duration in days. They are stored in the order entered, with sequence starting at 0, and remaining initialised to the allocation.

The offering's headline tokenPrice is copied from the first phase. That is the number shown on listings; the price actually charged is always the current phase's price.

Vesting, if switched on here, is validated before anything is written and then frozen for the whole sale. Read Vesting before advising a creator to use it — the delivery obligation it creates is monthly and manual.

Step 9 — payment

The launch fee is taken when the offering is created, inside the same database transaction that writes it. If any part of the creation fails, the fee is not charged.

The fee is a real wallet debit routed to the platform, so it appears in the creator's transaction history and in your platform revenue. A plan priced at 0 skips the charge entirely — useful for a first test offering.

A creator whose balance is short gets "Insufficient balance for the launch" before the form submits, and again at transaction time if their balance moved in between.

Step 10 — review and submit

Submission creates the offering with:

• status = PENDING
• submittedAt = now
• participants = 0
• isPaused = false, isFlagged = false

The creator gets an in-app notification pointing at /ico/creator/token/<id>, and the offering appears in your review queue. See Reviewing offerings.

What the creator can change afterwards

Once submitted, the offering itself is read-only to its creator. The surrounding content is not.

Thing	Editable by the creator	Where
Team members	Add, edit, delete — up to the plan's cap	Creator token page, Team tab
Roadmap items	Add, edit, delete — up to the plan's cap	Creator token page, Roadmap tab
Project updates	Add, edit, delete, unlimited	Creator token page, Updates tab
Launch plan	Upgrade to another plan	/ico/creator/token/<id>/plan/upgrade
Name, symbol, price, target, dates, phases	No	Administrator only
Vesting terms	No	Fixed at launch, and frozen per contribution at purchase

Upgrading a plan raises the caps on team members, roadmap items and phases. It does not change the sale's currency and it does not retroactively alter anything already sold.

The creator's ongoing job

Approving an offering is not the end of the creator's work — it is the start of it. For as long as the sale runs and until every allocation is delivered, they have to:

1. Watch /ico/creator/token/<id> for new contributions.
2. Send tokens on-chain, from their own treasury, to the address each buyer supplied.
3. Record the transaction hash against the contribution, which moves it to VERIFICATION.
4. Wait for you to verify it, which is when they get paid.

For a vesting sale, step 2 and step 3 repeat once per tranche, per buyer, for the life of the schedule. A twelve-month linear schedule across 200 buyers is 2,400 individual transfers. Make sure the creator understands that before you approve it.

The token simulator

/ico/creator/token-simulator is a token-economics modelling tool with three views — distribution, vesting schedule and projection. It runs entirely in the browser: it writes nothing, creates no offering and is not connected to the launch form.

Its value is that a creator can see the shape of a vesting schedule before committing to it. Point creators at it before they tick the vesting box, and at Phases and pricing before they write their phase allocations, because the two caps on a sale are easy to set against each other.