Install and enable

Licensing and enabling the ICO Launchpad, the three reference tables that ship empty, the escrow account it needs, the permissions to grant and the cron jobs that settle every sale.

13 min readUpdated 26 August 2026install, licence, permissions, cron, escrow

Installing the addon is the easy half. The half that catches people out is that a freshly enabled ICO Launchpad cannot host a single sale: three reference tables ship empty, and the launch form is unusable until you fill all three. Work through this page in order.

Licence and enable

The addon is licensed separately from core, through the same Extension Manager as every other Bicrypto addon. The order is fixed: activate the licence, install the release, then switch it on. A newly licensed addon's files are not on the server until Install is pressed, and nothing it installs takes effect until pnpm updator has run.

The Token ICO card — click it to open the product page
Its switch stays disabled, reading Activate license first, until the licence is activated

Open the Extension Manager. Go to Admin → System → Extension Manager. On the Extensions tab (or by searching for ICO) find the Token ICO card — product ID 36120046 — and click it. Until its licence is activated the card's chip reads Activate and its switch is disabled.
Activate the licence. On the product page press Activate License. Paste the purchase code from your MashDiv dashboard, optionally an email address for update notifications, and press Activate License. The screen confirms License Activated! and sends you back to the product page a couple of seconds later. If the server has no outbound access, the License File tab on the same screen takes the licence certificate downloaded from your MashDiv dashboard instead. Activation is what writes the machine-bound licence file lic/<productId>.lic in the install root.
1. Paste the purchase code here
2. Activate License — then wait for the redirect back to the product page
3. The License File tab, for a server with no outbound HTTPS
Install the release. Back on the product page, now licensed, the Overview tab has a release panel. If it offers Install v…, press it; if it says Up to date on a product you have only just licensed, press Check for Updates once, then install whatever it offers. The Releases tab holds the notes for the version you are being offered — read them first.

Install downloads the release, verifies it and extracts it over the project root. It runs no migrations, builds nothing and restarts nothing, so finish it from a shell on the server:
```
pnpm updator
```
That is the finalise chain — stop, dependencies, schema, seed data, frontend build, start — and it is what creates the addon's thirteen tables and loads its routes and screens. If the panel still says Up to date after the check there is nothing to download; go straight to the next step.
1. Check for Updates, then Install v… when it is offered
2. Releases — the notes for the version you are about to install
3. The Enabled switch — step 4, not yet
Switch it on. Turn the Enabled switch on — in the product page heading, or on the card in the Extension Manager, which is usable now that the licence is verified. This is what makes Token Sales appear under Admin → Extensions → Investment Products (the Admin → ICO screens the rest of this page refers to) and Token Sales at /ico in the user navigation, and what puts the two settlement jobs on the cron schedule. It takes effect without a restart — the cron process picks up a newly enabled addon on its own within a minute or so.

Two separate mechanisms decide whether the addon works, and they fail in different ways:

Mechanism	What it controls	Symptom when missing
The licence, activated on the product page	Every request to `/api/ico` and `/api/admin/ico`	API calls refused with Extension license required; screens load but stay empty
The Enabled switch	Whether the addon exists to the platform at all — its menu entries, its routes and its cron jobs	The ICO links vanish from the site footer and nav, and every `/api/ico` request answers 404

The licence check is cached for five minutes, so a freshly activated licence can take that long to take effect on a running backend. A restart clears it immediately.

Copying an install to a new server, or changing the machine it identifies itself by, invalidates the licence. Re-activate from the product page in the Extension Manager on the new box rather than copying lic/ across.

Database tables

The addon adds thirteen tables. They are created by the schema step of pnpm updator once the release is installed — there is no separate migration step and no SQL to run.

Table	Holds
`ico_token_offering`	One row per sale: name, symbol, status, target, dates, participant count
`ico_token_detail`	Supply, blockchain, description, links, use of funds, vesting terms
`ico_token_offering_phase`	Priced phases: allocation, remaining, duration, sequence
`ico_transaction`	One row per contribution
`ico_token_vesting`	One row per contribution that vests — the whole promise
`ico_token_vesting_release`	One row per tranche of that promise
`ico_launch_plan`	The packages creators pay for
`ico_blockchain`	Chains creators may launch on
`ico_token_type`	Token standards creators may pick
`ico_team_member`	Team profiles on an offering
`ico_roadmap_item`	Roadmap milestones on an offering
`ico_token_offering_update`	Project update posts
`ico_admin_activity`	The addon's own audit trail

ico_token_offering carries foreign keys to ico_launch_plan and ico_token_type with ON DELETE CASCADE. Deleting a launch plan or a token type that offerings point at deletes those offerings. Switch a plan off (its status) instead of removing it.

Seed the three reference tables

ico_launch_plan, ico_blockchain and ico_token_type are created with no rows. The launch form's first step is a plan picker with nothing in it, and the token-configuration step needs a blockchain and a token type before it will advance. A creator hitting this sees an empty dropdown and no explanation.

All three live under Admin → ICO → Settings, on their own tabs.

Blockchains

Each row is a name and a value. The name is what a creator sees; the value is what gets stored on the offering and used for validation.

nametype: string

Display name shown in the launch form and on the offer page

valuetype: string

The stored identifier — this is the string address and hash validation keys off

Wallet addresses and transaction hashes are validated against a fixed table of chain names, compared lowercase: ethereum, bsc, polygon, bitcoin, solana. Any other value falls back to a loose check — an address is accepted if it is 20 to 128 characters with no spaces, and a transaction hash is accepted unconditionally.

So a blockchain named "Ethereum" with the value eth gets no address validation, and a buyer can typo their address into an unrecoverable transfer. Use the exact five values above wherever they apply.

Token types

Name, value and a description. Nothing is enforced against the value — it is descriptive metadata shown on the offer page (ERC-20, BEP-20, SPL and so on). Create at least one, or no offering can be submitted.

Launch plans

Blockchains is one of the six tabs on this page

The package a creator buys to list. Price, currency, wallet type and a JSON feature block.

Field	Effect
`price`	Charged from the creator's wallet at submission. `0` is allowed and skips the charge entirely
`currency` + `walletType`	Which wallet the fee comes from — and the currency every contribution to that offering is paid in
`features.maxTeamMembers`	Hard limit, enforced at launch and when adding members later
`features.maxRoadmapItems`	Hard limit, enforced at launch and when adding items later
`features.maxOfferingPhases`	Hard limit, enforced at launch
`status`	`false` hides the plan from the picker without deleting it

maxUpdatePosts, supportLevel, marketingSupport, auditIncluded, customTokenomics, priorityListing and kycRequired are collected by the plan form and displayed on the plan card, but nothing in the backend reads them. Only the three max* limits above are enforced. Do not sell a plan on the promise that kycRequired gates anything — KYC is decided elsewhere, in the level builder.

The plan's currency is the most consequential field on the page. It is copied onto the offering as purchaseWalletCurrency / purchaseWalletType, so a plan priced in USDT on the SPOT wallet means every investor in every offering bought with that plan contributes in spot USDT. If your users hold fiat, they cannot participate. Create one plan per currency you want sales denominated in.

The escrow account

Every contribution is held on the Super Admin account's wallet until the sale settles.

The purchase route resolves the Super Admin account to credit escrow. If none exists it throws:

ICO escrow is not configured: no Super Admin wallet available to hold contributed funds.

The buyer's wallet is never touched — the whole purchase rolls back — but the error reads like a server fault, not a configuration problem. Confirm one account holds the Super Admin role before you approve the first offering.

The escrow wallet itself is created on demand in the offering's currency and wallet type, so you do not need to pre-create wallets. What you do need is for the account to exist and to be the one the platform's fee collection already uses.

Permissions

Fifteen ICO keys are seeded with core. None of them are granted to any role — Admin and Support ship empty. Grant them on Admin → Roles.

Key	Grants
`access.ico`	Opens the ICO admin dashboard
`access.ico.offer`	Opens the offer list and the per-status views
`view.ico.offer`	Loads offer rows, funding charts and per-offer vesting
`create.ico.offer`	Opens and uses the admin "create offering" form
`edit.ico.offer`	Approve, reject, flag, pause, resume, edit, add and delete phases
`delete.ico.offer`	Deletes an offering
`access.ico.transaction`	Opens the transaction desk and a transaction's detail page
`view.ico.transaction`	Loads transaction rows
`edit.ico.transaction`	Verify, reject, and add or remove notes
`access.ico.settings`	Opens the settings page
`view.ico.settings`	Reads the investment-limits endpoint
`edit.ico.settings`	Saves settings, blockchains, token types and launch plans
`access.ico.stat`	Loads the admin dashboard's statistics
`manage.system`	The Super Admin emergency cancel-and-refund

Grant access.ico.offer without view.ico.offer and the operator gets the offer page, the filters and a permanently empty table — no error, no banner. Tick both keys for every screen. create.ico.transaction and delete.ico.transaction are also seeded but no route asks for them; granting them does nothing.

Two of the settings endpoints additionally check the caller's role name rather than a permission, and accept only Admin or Super Admin. An operator on a custom role holding view.ico.settings will still be refused there.

KYC gating

Token-sale participation and token-sale creation are KYC features, decided once in the KYC level builder — not on the ICO settings page.

Token Sale Participation (purchase_ico) — lets a verified user contribute to an offering.
Token Sale Creation (create_ico) — lets a verified user submit an offering.

Open Admin → CRM → KYC, edit the levels that should carry them, and tick both features on the levels you want to hold them.

Edit the level that should carry token-sale access

Neither is enforced unless the platform KYC switch and per-feature enforcement are both on. With both off, anybody signed in can buy and launch.

Earlier builds had one on the ICO settings page. It wrote a key nothing read, while the offer page was already hiding itself from the same user through the shared gate — so the UI refused what the server allowed. It has been removed; the settings page now links to the level builder instead.

Cron

Two scheduled jobs do all the settlement work. Both run hourly and both live in the cron process — the PM2 app started with CRON_MODE=only on port 4001.

Job	What it does
`processIcoOfferings`	Activates offerings whose start date has passed, then closes ended offerings as `SUCCESS` or `FAILED` and refunds every contribution on a failure
`processIcoVestingReleases`	Announces vesting tranches that have come due, closes finished schedules, cancels schedules behind refunded contributions

Run now forces a settlement pass; it is safe to repeat

processIcoOfferings is the only thing that decides whether an offering succeeded or failed, and the only automatic path that pays contributors back when it failed. If the cron app is not running, ended offerings sit at ACTIVE forever, refuse new contributions because the end date has passed, and hold every contributor's money in escrow indefinitely.

Check it on Admin → System → Cron. Both jobs report per-run status there, and a failed run is reported as failed rather than swallowed.

Settlement runs one database transaction per offering, deliberately, because refunding a large failed sale takes row locks on every contribution and on the escrow wallet — the single hottest row on the platform. A 3,000-contributor refund in one transaction would block staking, investment and P2P settlement for its duration.

Verify the install

Work down this list on a fresh install. Every item is something that fails later, and quietly, if you skip it.

The Token ICO card in the Extension Manager reads Verified with its switch on, and pnpm updator has been run since the release was installed.
One account holds the Super Admin role.
At least one blockchain exists, using one of the five recognised value strings if it is one of those chains.
At least one token type exists.
At least one launch plan exists and is switched on, in the currency and wallet type you want sales denominated in.
The ICO permissions are granted to whichever role your reviewers sit on.
purchase_ico and create_ico are on the right KYC levels — or platform KYC is deliberately off.
Admin → System → Cron shows processIcoOfferings and processIcoVestingReleases with a recent successful run.
Contribution limits on Admin → ICO → Settings match the size of sale you expect. The defaults are a 10 minimum, a 100,000 single-contribution maximum and 50,000 per user per offering.

Then submit a test offering with a zero-price launch plan, approve it, contribute a small amount from a second account, and walk it through delivery and verification. That exercises every leg of the ledger before real money does.