Settings

Every ICO setting the backend actually reads, plus the three reference lists — blockchains, token types and launch plans — that decide what a creator can launch and what currency they sell in.

5 min readUpdated 3 August 2026admin, settings, launch-plans, blockchains

Admin → ICO → Settings (/admin/ico/settings) has six tabs. Three are key/value settings; three are record lists with their own endpoints.

Opening the page needs access.ico.settings. Saving anything on it needs edit.ico.settings.

Every key documented here is one the backend reads. Keys that only ever wrote a value nobody consulted have been removed from the page over time, and none are listed below.

Investment

The contribution limits, the platform fee, the soft cap and the vesting switch. All are read fresh on each purchase, so changes take effect immediately without a restart.

Contribution limits

Smallest contribution accepted on any offering, in the offering's purchase currency

Largest single contribution accepted on any offering

Total one user may contribute to a single offering, across all their purchases

The same three values apply to every offering, in whatever currency that offering sells in. A minimum of 10 is reasonable on a USDT sale and absurd on a BTC one.

If you intend to run sales in more than one currency, set these to the values that make sense for the currency you actually use, and be aware that a BTC-denominated launch plan will inherit them unchanged.

The per-user total counts a user's PENDING, VERIFICATION and RELEASED contributions to that offering. Rejected and refunded ones drop out and free the headroom again.

Fees

Percentage taken from each contribution as the platform's fee

Charged on top of the contribution, not deducted from it: a 1,000 contribution at 2% debits the buyer 1,020 and the project still receives 1,000. It is routed to the Super Admin wallet as platform revenue.

A value of 0 is honoured as written. It is not treated as "unset" and does not fall back to a previously configured percentage.

Funding

Share of an offering's target it must raise to count as funded

Read at settlement, so a change applies to offerings already running. Offerings that finish below it are marked FAILED and every outstanding contribution is refunded in the same pass.

Vesting

Let creators deliver a sale in dated tranches instead of one transfer

Duration pre-filled on the launch form when a creator switches vesting on

Turning vesting off blocks new launches from using it. Offerings that already vest are unaffected, and existing schedules keep running — those obligations exist and cancelling them would strand buyers.

icoDefaultVestingMonths is a form default only. The creator can change it, and nothing enforces it.

Compliance

Verification requirements

This tab does not carry a KYC switch, and deliberately so. Token-sale KYC is one decision, taken in the KYC level builder: enable Token Sale Participation (purchase_ico) and Token Sale Creation (create_ico) on the levels that should hold them.

Neither is enforced unless the platform KYC switch and per-feature enforcement are both on. The card on this tab links straight to the level builder.

There used to be one. It wrote a key the purchase route never read, while the offer page was already hiding itself from the same user through the shared feature gate — so the UI refused what the server allowed, and the switch enforced nothing. One dial, in one place, is the fix.

Availability

Stop the ICO module — contributions and new launches are refused with a maintenance message

This is a real stop-the-world switch. While it is on, both the purchase route and the launch route refuse with a 503 and a maintenance message. Existing offerings, schedules and balances are untouched, and everything resumes when you turn it off.

Use it before an upgrade, or when you have discovered something wrong and need the money to stop moving while you work out what.

Announcement

Display the announcement banner across the ICO pages

The notice shown to every visitor while the announcement is active

The banner renders on every page under /ico. It is plain text shown to everybody, signed in or not — do not put anything in it you would not put on a public page.

Blockchains

The list of chains a creator may launch on. Each row is a display name, a stored value, and a status flag. Only active rows appear in the launch form.

Wallet addresses and transaction hashes are checked against a fixed table of chain names, compared lowercase:

`value`	Address format enforced	Hash format enforced
`ethereum`, `bsc`, `polygon`	`0x` + 40 hex	`0x` + 64 hex
`bitcoin`	`bc1…` or legacy `1`/`3`	64 hex
`solana`	32–44 base58	87–88 base58
anything else	20–128 chars, no whitespace	none — any string is accepted

Name the row whatever you like, but set value to one of those five wherever it applies. A chain valued eth or Ethereum Mainnet gets the fallback, and a buyer can typo their receiving address into an unrecoverable transfer.

Unknown chain values are accepted on purpose — you cannot enumerate every chain a creator might use. That is a trade-off, not an omission, and it is why the five names matter.

Token types

Name, value and a description. Purely descriptive metadata — ERC-20, BEP-20, SPL, and so on — shown on the offer page. Nothing is enforced against the value.

At least one active row must exist or no offering can be submitted.

Launch plans

The packages creators buy to list. This is the most consequential list on the page, because a plan sets the currency of every sale made with it.

Field	Effect
`name`, `description`	Shown on the plan card
`price`	Charged from the creator's wallet at submission; `0` skips the charge
`currency`	The currency of every contribution to offerings on this plan
`walletType`	The wallet type those contributions come from — `FIAT`, `SPOT` or `ECO`
`features.maxTeamMembers`	Enforced at launch and when adding members later
`features.maxRoadmapItems`	Enforced at launch and when adding items later
`features.maxOfferingPhases`	Enforced at launch
`recommended`	Highlights the plan in the picker
`status`	`false` hides it from the picker without deleting it
`sortOrder`	Position in the picker

The plan form also collects maxUpdatePosts, supportLevel, marketingSupport, auditIncluded, customTokenomics, priorityListing and kycRequired. They are shown on the plan card and read by nothing.

In particular, kycRequired gates nothing — KYC is decided by the level builder, platform-wide. Do not sell a plan on the strength of it.

Both foreign keys cascade on delete. Removing a plan or a type deletes every offering using it, live ones included, along with their phases, token details and contributions.

Set status = false instead. It disappears from the picker and everything using it keeps working.

Creators can upgrade to a different plan after launch, which raises their caps. It does not change the sale's currency and does not alter anything already sold.

A key the settings page does not show

There is a separate investment-limits API behind /api/admin/ico/settings/limits. It reads and writes the same keys as the Investment tab, plus one more:

Refund grace period, in days

The limits endpoint accepts it, stores it and reports it back. Nothing anywhere in the refund logic consults it. There is no grace period, no time window after which a refund is refused, and no automatic refund triggered by it.

If you set it expecting refunds to be time-limited, they will not be. Refund eligibility is decided entirely by the offering's status.

That endpoint also gates on the caller's role name — only Admin or Super Admin — rather than on a permission key. An operator on a custom role holding view.ico.settings is still refused there, even though the settings page itself opens for them.