Creating a Liquidity Generation Event

A Liquidity Generation Event (LGE) is the launcher’s core flow: a creator pays a creation fee, the backend deploys a complete token + DAO stack in one transaction, and a buy-only bonding curve raises ICP until the target is hit and liquidity migrates to ICPSwap. This page covers what a creator configures, what is deployed at creation, who controls each canister before and after finalization, and the curve and distribution constants. See the full flow in Core Workflows.

What the creator configures

An LGE is created for a fixed total supply of 1 billion tokens. Creation is paid in one ICRC-2 charge — see What creating an LGE costs for the breakdown. The creator configures, among other parameters:

• Token metadata: name, symbol, logo. (Decimals are not a creator-configurable field on the ICOInit creation argument.)
• Description and social links: description, website, Telegram, OpenChat, Twitter.
• Vesting is forced (canister-enforced) — create_ico_campaign rejects (VESTING_REQUIRED) any LGE whose delayed_unlock_config is missing, has enabled = false, or does not apply to both creator and contributors. Vesting is therefore mandatory for every LGE, enforced backend-side — not just in the UI — so a direct API caller cannot create an immediate-claim or single-target LGE. The creation form always sends enabled = true, applies_to_creator = true, applies_to_contributors = true; the creator only chooses the cadence: weekly (up to 104 unlocks) or monthly (up to 24 unlocks), ~2 years. (The check runs only on the new-creation paths; relaunch reuses the original campaign’s config, and imported DAOs have no sale and no vesting.)
• Creator allocation (creator_allocation_tokens, default 80M): the creator may allocate up to 80M tokens (8% of supply) to themselves. This is bought atomically at creation priced from tokens_sold = 0, so the creator is effectively first in — there is no separate timed pre-sale window.
• Full-sale raise (creator-chosen): the total ICP the curve raises at sell-out is chosen by the creator in steps of 500 ICP — from 500 ICP (the default) up to 5000 ICP, i.e. target_icp_for_liquidity = k × 500 for an integer k in 1..=10. The curve keeps the same shape and sells the same tokens at every k (700M on the curve / 200M pool / 100M DAO reserve — unchanged); only the ICP prices scale by k, so ~90% of the chosen raise seeds the ICPSwap pool (450 × k ICP, 450 at the 500-ICP default) and the remaining ~10% covers pool creation, fees, and referral rewards.
• Liquidity tokens: liquidity_tokens (default 200M) — the token side of the pool.
• Sale window: expiry_timestamp (sale window / expiry).
• Attribution and infra: sponsor_code (referral attribution), subnet_selection, enable_banner_feature (paid +3 ICP add-on), and post_lge_guardian (an optional post-LGE local guardian). no_pool exists but is governance-gated, not a normal creator option.

Per-buyer purchase limits during the sale are enforced downstream by the Voter Benefits Protocol tiers, not chosen at creation: Guest 1M, Human (verified) 4M, Fish 12M (≥2,000 VP), Shark 18M (≥10,000 VP), Whale 24M (≥30,000 VP). Fish/Shark/Whale also require active-voter status. These five limits, the three VP thresholds, the guest fee, the treasury fee, and the pool reserve are all DAO-tunable defaults (VotingParamsConfig/IcoFeeConfig carry Option<T> overrides that fall back to the constants), not immutable values.

What creating an LGE costs

The creation charge is collected as a single ICRC-2 payment, assembled at request time (prepare_ico_creation_impl) from these components:

total = treasury_fee_e8s            // DAO-set platform fee, default ~399_980_000 e8s (~4 ICP)
      + pool_creation_fund_e8s      // pool reserve sized from the LIVE ICPSwap passcode price
                                    //   (fetch_pool_creation_reserve_e8s; static fallback ~1.0002 ICP)
      + banner_feature_fee_e8s      // +3 ICP, only if the creator opts into the banner feature
      + ico_cycles_cost             // dynamic cost to spin up the ledger + index + DAO canisters
      + creator_token_cost          // bonding-curve cost of the creator's own allocation buy

• Treasury fee — the platform fee, defaulting to ~4 ICP; governance-tunable via admin_set_ico_fee.
• Pool reserve — the ICP set aside to seed the token’s ICPSwap pool, sized at request time from the live pool passcode price (static fallback ~1.0002 ICP).
• Banner feature — an optional +3 ICP add-on, charged only if the creator enables the banner.
• Cycles cost — the dynamic cost of spinning up the campaign’s ledger, index, and DAO canisters.
• Creator allocation buy — the bonding-curve cost of the creator’s own token allocation (see What the creator configures), bought atomically during creation.

The treasury fee and pool reserve are governance-adjustable and the cycles and creator-buy components are dynamic, so the total varies per LGE.

Canisters deployed at creation

The user pays the ICRC-2 creation fee (the dynamic total broken down under What the creator configures); the backend then creates an empty governance canister, a ledger canister, and an index canister (with governance as a controller), installs the SONS governance WASM, and registers the campaign in dao_storage and pool_manager. The ICPSwap pool is created at LGE launch as well, so fundraising is blocked immediately if any piece fails.

Canister	Created by	Role
Ledger canister	Backend — create_canister (IC management canister), then LEDGER_WASM installed	ICRC-1 + ICRC-3 ledger for the campaign token; ICRC-2 is disabled at init (feature_flags.icrc2 = false) — no allowance-based approve / transfer_from
Index canister	Backend — create_canister (IC management canister), then INDEX_WASM installed	Transaction-history index for the campaign token, synced from its ledger (powers per-account get_account_transactions)
Governance (sons_governance)	Backend (create_empty_governance_canister), then GOVERNANCE_WASM installed	The campaign’s own DAO: treasury, proposals, voting with the LGE token
ICPSwap pool	Backend / pool_manager	Pool created at launch; liquidity added at completion

sons_governance is not in dfx.json — one instance is created per LGE campaign at runtime. The same WASM binary (sons_governance.wasm.gz) is installed into every instance, each with its own state. The same creation path is shared with standalone token creation, which deploys only the ledger and index (no governance, no pool).

Controllers: at creation vs after finalization

Every LGE gets its own governance canister from day one, but the DAO becomes autonomous only at completion. The controller set tells the difference.

At creation

The governance canister, ledger, and index are each deployed with a full set of controllers so OhShii can monitor cycles, upgrade WASM, and perform maintenance until the DAO goes live. The governance canister is also added as its own controller immediately after creation, so it can manage itself via proposals.

Controller	Purpose	Lifetime
ohshii_launcher_backend	Manages LGE operations, upgrades	Temporary
ohshii_governance (ONS)	Enables OHSHII-token governance over the stack	Temporary
Governance canister itself	Token-holder voting / self-upgrades	Permanent
CycleOps	Metrics + optional automated top-up	Permanent
NNS Root	Open canister-status reads (cycle monitoring) + IC-level emergency recovery	Permanent

New deploys do not add the community blackhole monitor (e3mmv-5qaaa-aaaah-aadma-cai) as a controller; NNS Root’s open canister_status passthrough replaces it. Only legacy campaigns created before this change still carry the blackhole as a controller.

The ledger and index carry the same set, plus the governance canister itself so the per-LGE DAO can upgrade and manage its own ledger/index once live. Archive controllers are headed by the backend, with ohshii_governance and the governance canister in more_controller_ids.

After finalization (full DAO autonomy)

Once the campaign reaches target and is finalized, finalize_governance and execute_post_finalization_steps remove the backend and ohshii_governance from both the governance config’s admins and the canister’s IC-level controllers (keeping at least one controller). The pool_manager also transfers the liquidity position to the governance canister. The result:

• Removed: ohshii_launcher_backend, ohshii_governance.
• Remaining: the governance canister itself, CycleOps, NNS Root. (Legacy pre-NNS-Root campaigns also retain the blackhole monitor.)

After this point the DAO is fully autonomous: token holders control all decisions via proposals, the governance canister can upgrade itself / the ledger / the index, OhShii has no admin or controller power, and NNS Root remains only for IC-level emergencies. The DAO can later change these controllers via governance proposals.

The buy-only bonding curve

During the LGE phase OhShii implements a buy-only bonding curve: selling is technically impossible until the curve completes and liquidity migrates to ICPSwap, which blocks front-running, bot manipulation, and instant rug-pulls. Token price is set by a power-curve / Sigmoid mechanism — the exact formula depends on the campaign generation:

Generation	Price formula	Cost of buying tokens a → b
Sigmoid V2 (current LGEs)	p(x) = 10 + 123 × (3x² − 2x³), with x = tokens_sold / 700M	Cost(a,b) = 700M × (F(b/700M) − F(a/700M)), F(x) = 10·x + 123·(x³ − x⁴/2)
Power Curve V1 (pre-V2)	P(t) = 10 + 215 × (t / 758.41M)^2.844269, K = 2.844269	Cost(a,b) = 10×(b−a) + 215×(b^(K+1) − a^(K+1)) / ((K+1) × 758.41M^K)

The token amount for a purchase is computed by dao_storage (bonding_curve::calculate_tokens_from_icp_amount) against the live tokens_sold / sale_supply, not by the backend. The curve always prices on the gross ICP a buyer sends. Sigmoid V2 keeps the same curve shape at every raise and scales all prices linearly by k = target / 500 (so the formulas above are the k = 1, 500-ICP default). The curve ends at 0.00000133 × k ICP per token (0.00000133 at the default), and the ICPSwap opening price (450k ICP / 200M = 225k e8s/token ≈ 0.00000225 × k ICP; 0.00000225 at the default) is a mechanical result of the seed ratio, not a target. The end-of-curve price is therefore ~41% below the ICPSwap listing at every k (the ratio 0.00000133 / 0.00000225 is invariant). The sale is buy-only, so tokens cannot be sold into the curve before the pool exists.

At the 500-ICP default (k = 1) these are the familiar numbers; a larger chosen raise scales every price by k:

Creator’s raise	Pool ICP (~90%)	ICPSwap listing	End-of-curve price
500 ICP (k = 1, default)	450 ICP	0.00000225 ICP/token	0.00000133 ICP/token
1000 ICP (k = 2)	900 ICP	0.00000450 ICP/token	0.00000266 ICP/token
5000 ICP (k = 10, max)	4500 ICP	0.00002250 ICP/token	0.00001330 ICP/token
k × 500 ICP (general)	450 × k	0.00000225 × k	0.00000133 × k

The end price stays ~41% below the listing in every row (0.00000133 / 0.00000225 ≈ 0.59).

Fundraising trigger and completion distribution

The curve completes — and finalization is triggered — when the sale target is reached: the creator-chosen raise (500 × k ICP, default 500) and 700M tokens sold (Sigmoid V2). Pre-V2 generations used different constants:

Generation	Tokens sold on curve	ICP target
Sigmoid V2 (current)	700M	creator-chosen 500 × k (default ~500)
Power Curve V1	758.41M	~500 ICP
Exponential legacy (dao-0000000000–0000000010)	800M	~1000 ICP

ICP distribution (creator-chosen 500 × k total, Sigmoid V2)

Amounts scale with the chosen raise (k = target / 500, k in 1..=10); the k = 1 (500-ICP default) figure is shown in parentheses.

Share	Amount	Destination
~90%	450 × k ICP (450)	ICPSwap liquidity pool
~5%	25 × k ICP (25)	OhShii platform / DAO treasury
0–5%	up to 25 × k ICP (25)	Referral rewards, based on sponsor’s Voting Power; the unearned portion stays in the OhShii treasury

Token distribution (1B fixed total supply, Sigmoid V2)

Share	Amount	Destination
70%	700M	Distributed during the LGE via the curve
20%	200M	ICPSwap liquidity pool
10%	100M	DAO reserve — held in the campaign’s governance canister

The 200M tokens plus 450 × k ICP (450 at the 500-ICP default) form the ICPSwap pool; the 100M DAO-reserve tokens remain in the campaign’s governance canister for platform fees, quests, and allocations. Power Curve V1 distributes 758.41M (75.84%) on the curve with a 41.59M (4.16%) DAO reserve; the exponential legacy campaigns distributed 800M (80%) with no DAO reserve.

The DAO reserve is the governance canister’s treasury (its main account). Curve tokens that become vesting locks are held separately, in per-lock custody subaccounts of the same canister (see token-claim.md and GOVERNANCE.md → “Per-lock custody isolation”) — so the treasury balance a DAO can spend excludes tokens still backing locks.

Participation, limits, and alternative funding

Contributors fund the curve with ICP through purchase_tokens_icrc2, gated by their Voter Benefits Protocol tier. Per-purchase token limits:

Tier	Requirement	Purchase limit
Guest (unverified)	—	1M tokens
Human (verified)	Identity verified	4M tokens
Fish	≥2,000 VP + active voter	12M tokens
Shark	≥10,000 VP + active voter	18M tokens
Whale	≥30,000 VP + active voter	24M tokens

“Active voter” means having voted on at least 2 of the last 3 ONS governance proposals; the Fish/Shark/Whale tiers all require it — a holder who stops voting is demoted to the Human (4M) tier until they vote again (verification and VP are retained, only the cap drops).

The creator has a separate 80M allocation and does not need governance qualification. Guest-tier participants pay a one-time 30,000 OHSHII guest fee on their first contribution (refunded on failure). Contributors who lack ICP can fund participation via the Bitcoin Gateway — depositing BTC, minting ckBTC, and swapping to ICP — without custodians or traditional bridges. The end-to-end purchase, escrow custody, and refund mechanics are detailed in Core Workflows.

Refund protection on failure

If the full-sale target (500 × k ICP, default 500) is not reached before the deadline, the LGE is marked Failed and contributors can request a refund within 7 days of the campaign expiry via request_refund:

• Contributors: 90% net of contributed ICP, plus the held 5% referral band (95% total, tier-independent on escrow-funded campaigns).
• Creator: ~70% of their spent ICP.
• OHSHII: the platform fee is non-refundable; the Guest-tier OHSHII fee is returned.

Refunds draw only from held funds (the campaign subaccount and the per-campaign referral subaccount), never the treasury. See the full per-leg math in Core Workflows.