Participating in an LGE

Participating in a Liquidity Generation Event (LGE) means depositing ICP into a campaign’s buy-only bonding curve and receiving tokens in return. This page covers the four things that shape a contribution: how funds get in (ICP or Bitcoin via the ckBTC gateway), the purchase limits (a minimum per contribution plus a per-tier cap set by the Voter Benefit Protocol), the optional sponsor code and its VP-gated reward share, and the OHSHII fee with its identity-verification exemption. The full purchase flow — escrow custody, idempotency, the per-contribution lifecycle — lives in Core Workflows; this page summarizes the participant-facing mechanics.

Getting funds in: ICP or Bitcoin

A contribution is always paid in ICP, settled via an ICRC-2 approval the participant signs at purchase time. Two on-ramps reach that ICP balance:

ICP directly — deposit ICP and participate.
Bitcoin via the ckBTC gateway — Bitcoin arrives on the Internet Computer as ckBTC through DFINITY’s chain-key minter (no custodians, no traditional bridges), then is swapped to ICP via ICPSwap. The converted ICP is then used to join any LGE.

Once the participant holds ICP, the LGE page handles everything else — there is no need to move assets between external interfaces.

Purchase limits

A contribution is bounded on both ends: a minimum that every purchase must clear, and a maximum number of tokens a wallet can buy in a single campaign.

Minimum per contribution. Each purchase must clear a small dynamic floor — about 0.1 ICP by default (MIN_PURCHASE_AMOUNT_DEFAULT), dropping to roughly 0.01 ICP in the late stage of the curve (MIN_PURCHASE_AMOUNT_LATE_STAGE, applied via get_dynamic_min_purchase). Anything below it is rejected because, after fees, nothing would reach the LGE. This floor applies to every contributor regardless of tier.

Maximum (per-tier token cap). The cap depends on who the contributor is:

The creator has a separate 80M token allocation (8% of supply) and does not need any governance qualification. No one else can buy before the creator.
A standard (non-voter) user is capped at 4M tokens.
A user who locks OHSHII and votes climbs the Voter Benefit Protocol tiers, raising the cap up to 24M tokens (Whale).

Voter Benefit Protocol tiers

The backend (ohshii_governance) is the source of truth for a participant’s tier and effective purchase cap. The tier is derived from the user’s OHSHII Voting Power (VP) and verification status:

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

The high-capital tiers (Fish, Shark, Whale) require the user to be an active voter — they must have voted on at least 2 of the last 3 countable ONS proposals. A qualifying user who stops voting is temporarily demoted toward the base cap until they resume. The frontend renders the backend’s LgeEligibility (effective_tier, max_purchase_limit_e8s) rather than recomputing the cap locally.

See the full flow in Core Workflows.

A sponsor code is optional. If a participant does not provide one, the referral band stays in the OhShii treasury and the participant pays nothing extra for omitting it. If one is provided and resolves to a valid, non-self sponsor, that sponsor can earn a reward share from the referral band — at no additional cost to the participant (the share is taken from the 5% referral band only, never from the campaign’s 90% or the platform fee). The band is a capped pool (≤5% of the curve, ≈25 ICP), the share is paid only on a successful LGE, and on success it is claimed from the campaign’s own sons_governance canister, not from OhShii (on failure the held band is refunded to buyers).

The reward share depends on the sponsor’s Voting Power, gated by the same active-voter rule used for purchase limits:

Sponsor Voting Power	Sponsor reward share
VP < 2,000	0%
VP ≥ 2,000	2%
VP ≥ 3,000	3%
VP ≥ 5,000	5%

Notes:

A sponsor with the VP for a tier but who is not an active ONS voter forfeits the reward entirely (0%, regardless of VP) until they resume voting; the unearned band settles to the OhShii treasury exactly as a sub-threshold tier does.
The VP tier is snapshotted at the time of each individual transaction, not once per campaign — different buyers in the same campaign can have different sponsors and tiers.
Once set, a sponsor code cannot be changed.
A participant who does not know a referrer can use the standard “OHSHII” code, which directs the referral portion (up to 5%) to treasury and service maintenance.

For the full fee-split mechanics (the 10% total fee, the held 5% referral band, deferred settlement on the campaign’s sons_governance), see the Sponsor System documentation.

The OHSHII fee and the identity-verification exemption

A first contribution to a campaign may require a one-time OHSHII fee in OHSHII tokens. This is the Guest-tier fee — it applies only to unverified (“Guest”) wallets and is waived by identity verification.

Condition	Outcome
Wallet is identity-verified (World ID or DecideID)	Exempt — no OHSHII fee (the wallet is Human tier or higher)
Wallet is unverified (Guest tier)	First participation in each LGE requires the OHSHII fee (30,000 OHSHII, snapshotted at contribution time, 100% to treasury)
Any subsequent contribution to the same LGE	No additional OHSHII fee

Mechanics:

The fee is 30,000 OHSHII, charged once per (user, campaign) on the Guest tier’s first contribution. It is a single ICRC-2 transfer_from to the OHSHII treasury (100% to treasury — there is no burn).
The exemption is purely identity verification: a verified wallet is Human tier or higher, so its effective_tier is never Guest and it never owes the fee. Voting Power and active-voter status do not affect this fee — they only set the purchase-limit tier (a non-voting Whale is demoted toward the Human cap, but still pays no guest fee). There is no tokens-sold cutoff: the gate is purely tier-based (effective_tier == Guest), regardless of how many tokens the LGE has sold. (The legacy burn_token_limit / 650M-sold cutoff from the pre-Voter-Benefit-Protocol burn design is retained only for stable-storage decode safety and is ignored at runtime.)
The exact amount charged is snapshotted at contribution time, so it is independent of any later fee-config change.
On a failed campaign, Guest-tier contributors get their 30,000 OHSHII fee back alongside the ICP refund — the guest-fee refund is idempotent and keyed per (user, campaign). (Distributed OHSHII tokens on a successful campaign are permanent and non-refundable.)
Guest participant cap (anti-Sybil). Because unverified (“Guest”) wallets are free to create, each LGE accepts at most 50 distinct Guest participants while identity verification is active. The limit is enforced backend-side, atomically, at a Guest’s first contribution to a campaign; once a wallet is in, its later contributions are unaffected, and verified participants are never counted or limited by it. When platform verification is globally disabled (no World ID / DecideID method enabled), the cap does not apply — every wallet would otherwise resolve to Guest, which would limit the whole launch. A Guest arriving after the cap is reached is asked to verify their identity (World ID or DecideID) to participate as a verified user.

Summary: the per-LGE OHSHII fee is required only on an unverified (Guest-tier) wallet’s first contribution; identity verification (World ID / DecideID) exempts you. Voting Power, voting activity, and tokens-sold do not affect it. The sponsor code is always optional.

The eligibility verdict and the exact required fee come from the backend (get_lge_eligibility → effective_tier, guest_fee_e8s); the frontend approves exactly that amount and never relies on a hardcoded fallback. See the full purchase flow in Core Workflows.

Participating in an LGE

Getting funds in: ICP or Bitcoin

Purchase limits

Voter Benefit Protocol tiers

The sponsor code (optional)

The OHSHII fee and the identity-verification exemption

See also