ICO Launchpad
A token-sale launchpad for Bicrypto — creators list an offering, investors contribute from their platform wallet, and the platform escrows the money while the project delivers tokens on-chain.
The ICO Launchpad turns your Bicrypto install into a place where third-party projects run token sales. A creator pays for a launch plan, describes their token, sets up priced phases, and submits the offering for review. Once you approve it, your users contribute from the platform wallet they already hold, and the platform holds that money in escrow until the project has delivered.
There are three people in every sale, and the docs are organised around them:
- The creator — the project selling the token. They fill in the launch form, answer to the review queue, send tokens on-chain and record what they sent.
- The investor — one of your users, contributing from a spot, fiat or ecosystem wallet. They supply a receiving address at purchase.
- You, the operator — you approve or reject offerings, verify deliveries, release escrow to the creator, and refund when a sale collapses.
What this addon requires
This is an addon, not a standalone product. It needs a working Bicrypto install — users, roles, wallets, the wallet service, notifications and the cron process — because every one of those is load-bearing here. Nothing else is required.
There is no ScyllaDB dependency, no exchange connection and no blockchain node. The addon never talks to a chain.
The one thing to understand first
An ICO here escrows the payment currency, not the token. When a sale settles, the creator sends the tokens from their own treasury, on-chain, to the address the buyer supplied — and then records the transaction hash on the platform so the delivery can be verified.
Nothing is minted, deployed or transferred automatically. If a creator vanishes after taking contributions, your only lever is refusing to release escrow and paying the money back. Review offerings properly before approving them.
That model explains almost every design decision below, including why "vesting" here means a dated schedule of obligations rather than a locked balance.
How the money moves
Every contribution takes four ledger legs, all inside one database transaction:
| Leg | From | To | When |
|---|---|---|---|
| Purchase | Investor wallet | — | At purchase |
| Platform fee | Investor wallet | Super Admin wallet | At purchase, if the fee is non-zero |
| Escrow hold | — | Super Admin wallet | At purchase |
| Escrow release | Super Admin wallet | Creator wallet | When you verify the delivery |
| Escrow refund | Super Admin wallet | Investor wallet | On rejection, failure or cancellation |
The Super Admin account is the escrow. If no Super Admin exists, purchases fail with a 500 rather than silently losing the money — see Install.
The fee is charged on top of the contribution. A user contributing 1,000 USDT with a 2% fee needs 1,020 USDT available.
The lifecycle of an offering
| Status | Meaning | Set by |
|---|---|---|
PENDING |
Submitted, awaiting review | Creation (both the creator form and the admin form) |
ACTIVE |
Approved; accepting contributions once the start date has passed | Admin approval |
REJECTED |
Refused at review; notes explain why | Admin rejection |
SUCCESS |
Ended at or above the soft cap | The hourly cron |
FAILED |
Ended below the soft cap; contributions refunded automatically | The hourly cron |
CANCELLED |
Killed by a Super Admin; every contribution refunded | Emergency cancel |
Both values exist in the schema and the offer filters, but no creation path and
no admin action ever sets them. Approving an offering makes it ACTIVE
immediately, even when its start date is weeks away — the purchase route is what
refuses early contributions, with "Offering has not started yet". Do not expect
an "Upcoming" queue to fill itself.
Contributions have their own lifecycle, which is the part operators most often misread:
| Status | Meaning |
|---|---|
PENDING |
Paid. The buyer's wallet was debited and the money is in escrow. Tokens not yet sent. |
VERIFICATION |
The creator has sent tokens and submitted a hash; awaiting your check |
RELEASED |
You verified it; escrow paid out to the creator |
REJECTED |
You refused the delivery; the buyer was refunded |
REFUNDED |
Swept back by a failed sale, a cancellation or a manual refund run |
It means paid and undelivered, which is the normal state of every contribution
for as long as the sale is running. All three of PENDING, VERIFICATION and
RELEASED count towards "amount raised" and towards the soft cap.
Where the screens are
Users get /ico — a landing page with platform stats and featured
offerings, an offer browser at /ico/offer, a personal dashboard at
/ico/dashboard with investments and vesting, a transaction history, and a
Creator area (/ico/creator) with the launch form, a token simulator and
per-offering management.
You get /admin/ico — a dashboard, the offer review queue, the transaction
desk and a settings page with six tabs. Every screen is permission-gated; see
Roles and permissions.
Where to go next
Licence, enable, seed the three reference tables that ship empty, grant permissions and confirm the cron runs. The addon cannot host a single sale until all of that is done.
The ten-step launch form, what the launch plan actually limits, and what a creator can still change after submission.
How the selling phase is chosen, why phase durations are display-only, and the two independent caps that end a sale.
Linear, cliff and milestone schedules, how tranches are generated and frozen, and what the creator has to do every month.
Eligibility, limits, wallet addresses, and what a buyer sees between paying and receiving.
Approve, reject, flag, pause, feature, edit phases, and the Super Admin emergency cancel.
The escrow ledger leg by leg, verifying a delivery, and the refund paths.
Every key the backend actually reads, plus blockchains, token types and launch plans.