Overview

OhShii lets you launch a token that automatically becomes a community-governed DAO. Everything around it — fundraising, ICPSwap trading, refunds if a sale falls short, vesting, and on-chain voting — is built in and runs on-chain.

OhShii Launcher Overview

OhShii Launcher bundles everything needed to launch a token and bootstrap a DAO on the Internet Computer. The core features are summarized below.

Fair Liquidity Generation Events (LGE)

An LGE is a fundraising sale where contributors receive the new token; if the sale doesn’t reach its target, contributors are refunded.

The creator chooses how much the LGE raises — any multiple of 500 ICP, from 500 up to 5000 ICP (500, 1000, 1500, … 5000). The curve keeps the exact same shape and always sells the same 700M tokens; only the prices scale with the chosen target, so a 5000-ICP LGE prices every token 10× a 500-ICP one.

Each LGE has a fixed total supply of 1 billion tokens — 700M sold through the bonding curve, 200M seeding the ICPSwap liquidity pool, and 100M held in the campaign DAO treasury. Pricing follows a buy-only SigmoidV2 curve whose shape never changes. At the 500-ICP default the price increases monotonically from 0.00000010 to 0.00000133 ICP per token across the 700M-token sale (a higher target scales those prices up proportionally — 10× at the 5000-ICP maximum). The curve is buy-only, so it cannot be sold back into before the pool is created. The ICPSwap opening price is a mechanical result of the 200M-token : pool-ICP seed ratio (≈450 ICP at the default, up to ≈4500 ICP at the 5000 target).

Selling out the curve raises the creator’s chosen target: about 90% seeds the ICPSwap pool (≈450 ICP at the 500-ICP default, up to ≈4500 ICP at the 5000 target) and the remaining ~10% (≈50 ICP at the default, up to ≈500 ICP) covers pool creation, fees, and referral rewards. The end-of-LGE price is always about 41% below the ICPSwap listing price, whatever target the creator picks.

Buy-only SigmoidV2 curve: the price increases monotonically from 0.00000010 to 0.00000133 ICP per token across the 700M-token sale. The dashed line marks the ICPSwap opening price (0.00000225 ICP), which is the mechanical result of seeding the pool with 200M tokens and ≈450 ICP — not a target.

Per-user purchase limits also cap how much any single wallet can buy: unverified “guest” wallets are limited to 1M tokens, while verified users unlock higher caps (4M and up) based on their Voting Power and active-voter status. All tier limits are governance-configurable.

Refund Protection

If an LGE does not sell out its token supply before the deadline (and is therefore marked Failed), refunds open for 7 days:

Contributors receive approximately 95% of their contributed ICP back — the ~90% net plus the held 5% referral band, returned regardless of sponsor tier — minus a negligible per-leg ledger fee.
Creators receive approximately 70% of the ICP they spent contributing to their own LGE.
Guest-tier contributors also get their one-time 30,000 OHSHII guest fee back.

If the sale does not complete, contributed ICP is returned from the campaign’s held sub-accounts rather than released to the creator.

Automatic Infrastructure

Every token launched through OhShii receives:

A standard token ledger with a full, on-chain transaction history
An index canister for transaction tracking
A dedicated governance canister for campaign-specific voting

Integrations and Additional Features

ICPSwap — A liquidity pool is created when the LGE launches and seeded with liquidity at completion, so the token is tradable straight from its LGE page.
Cycle management — Every canister on the Internet Computer must hold cycles to keep running. From the launcher you can monitor and top up the cycles of your token’s own canisters (ledger, index, and governance) as well as its ICPSwap pool, so none of them freeze.
Cross-Chain Gateway — Bring Bitcoin or Solana into the ICP ecosystem without custodians or traditional bridges, then convert to ICP to participate in any LGE. Bitcoin is minted to ckBTC via DFINITY’s native chain-key minter (swap ckBTC ↔ ICP via ICPSwap, and redeem back to native Bitcoin at any time); Solana is handled through Menese Protocol’s chain-key execution layer for direct SOL ↔ ICP swaps at minimal slippage.
Referral System — Optional sponsor code. Sponsors earn a share of a capped referral pool — at most 5% of the curve (≈25 ICP at the 500-ICP default, up to ≈250 ICP at the 5000 target) — and the share is paid only if the campaign completes successfully; failed or refunded campaigns pay sponsors nothing. The share is claimed from the campaign’s own autonomous DAO after completion, not from OhShii, and scales with the sponsor’s governance tier (Voting Power ≥2,000 → 2%, ≥3,000 → 3%, ≥5,000 → 5%; below 2,000 → 0%), active-voter status, and the contributions of the wallets they referred. Anyone can get a sponsor code for 3 ICP. Any unearned part of the band settles to the OhShii treasury on success, or is refunded to contributors on failure.
Analytics — The OhShii Explorer bundles a Token Explorer (holders, transactions, and a BubbleMap holder-graph view), a Wallet Analyzer for any principal or account, and Atlas, an ICP-wide token map. Because the Token Explorer can scan transactions directly on-chain from the ledger, tokens are trackable from the very start — even before they are listed on third-party explorers like ICExplorer.

Integrated Vesting (DAO-managed)

Every OhShii LGE uses governance-managed vesting — it is mandatory and canister-enforced (an LGE cannot be created without it, and it always applies to both the creator and contributors; the creator only chooses the cadence). Vesting locks are created in an INACTIVE state at LGE completion — held on the campaign’s own DAO (its governance canister), not the OhShii Locker canister — pending user activation. (The OhShii Locker frontend is used to view and manage these governance-held locks.) Users must click the “ACTIVATE VESTING” button within one week (7 days) of LGE completion to start their vesting schedule. Upon activation, unlock timestamps are computed from the activation time: by default ALL users (including the creator) have their first unlock one frequency period after activation (1x — e.g., weekly = 1 week after activation). However, if the CREATOR holds more than 12 million tokens total across their vesting locks, their first unlock is delayed to 3x the frequency period (e.g., weekly = 3 weeks after activation) — versus the 1x base for everyone else. This additional delay applies specifically to high-allocation creators and results in a more gradual token distribution.

How integrated vesting works:

Tokens unlock gradually on a fixed schedule after the LGE completes, rather than all at once.
Creator tokens are also subject to vesting (same base rules as everyone).
Your vesting is also your voice in the DAO. The moment the LGE completes it becomes an autonomous on-chain DAO — its own governance canister (a SONS DAO) — and your vesting locks are created inside it. As soon as you click ACTIVATE VESTING (within 7 days), those still-locked tokens become your voting power in that campaign DAO, so your locked stake helps govern the token from the DAO’s first days instead of sitting idle. (Voting power begins at activation: a lock that hasn’t been activated yet carries none.)

Not a benefit — an anti-dump safeguard for participants: a creator who holds more than 12 million of their own tokens across their vesting locks is locked up longer than everyone else — their first unlock is delayed to 3× the frequency period (e.g., 3 weeks on a weekly schedule) instead of the 1× that applies to every other participant. This is a constraint on a large-allocation creator (it discourages the biggest insider from dumping first), not a perk for them.

Key Differences from Other Launchers

Most launchpads hand you a token and a pool, then keep the keys. OhShii runs on two separate layers of on-chain governance, and once your launch completes the keys are gone — your community holds them.

How governance works: ONS vs SONS

Two distinct DAOs that never overlap — neither can vote on, control, or override the other:

SONS — Standalone OhShii Network System (your campaign’s DAO). Every LGE gets its own dedicated, standalone governance canister that governs only that token: its proposals, its treasury, its liquidity position, and its canisters. It is autonomous: once your LGE completes, only its own holders can govern it — not even ONS can — voting with voting power from their locked campaign tokens.
ONS — OhShii Network System (the ecosystem DAO). It governs the OhShii platform itself — the launcher canisters, the OhShii Locker, the pool manager, and the OHSHII ledger / index / pool — not your campaign DAO. ONS holders vote with their OHSHII voting power.

The points below are grouped the same way: SONS governs one token per campaign; ONS governs the OhShii platform — and the two never reach into each other.

What your campaign DAO (SONS) can do

Govern your token’s trading fees. When your LGE completes, your token’s ICPSwap liquidity position is transferred to your campaign DAO, which becomes its sole owner. The fees the pool earns are then claimed through a governance proposal, never paid to the creator — the DAO keeps 100% in its own treasury (held on the governance canister itself). Each campaign DAO decides, through its own proposals, how to use the fees it collects; OhShii neither directs nor participates in those decisions.
Upgrade its canisters — not just “upgradable”, but in ordered batches. After finalization the DAO holds upgrade authority over its own canisters and can, behind a single vote:
- upgrade the token’s ledger, index, and archive canisters together as one ordered batch — the platform enforces the safe order (index → ledger → archives) so a money-rail upgrade can’t run out of sequence;
- upgrade several dapp canisters in one ordered batch (a self-upgrade of the governance canister is allowed only as the final step);
- upgrade the frontend / asset canister as a first-class governed action;
- ship large WASM modules beyond the normal 2 MiB limit (automatically split into chunks and reassembled on-chain);
- add or remove controllers of its canisters by proposal.
Every upgrade is gated: before anything installs, the platform checks the DAO is already a controller of every target (all-or-nothing — one missing controller means zero installs), and committed steps are never silently rolled back. That is the real power of DAO-governed canisters — the community can safely evolve the entire token stack, not just flip one switch.
Decide everything else by proposal — motions, treasury actions, emergency operations (e.g., pausing a canister), and parameter changes. Voting power is quadratic (roughly the square root of the locked amount × the lock duration, capped per user); only active locks count, and quorum/approval thresholds are themselves DAO-configurable.

What the OHSHII ecosystem DAO (ONS) governs

ONS is the ecosystem-wide DAO. Its standing scope is the OhShii platform itself — the launcher canisters, the OhShii Locker (its token list and selected lock operations), the pool manager, and the OHSHII ledger / index / pool — plus any external dapp that adds ONS as a controller (backend and frontend).

ONS cannot upgrade, change, or vote in a completed campaign’s SONS DAO. Its only reach into a campaign is temporary: while an LGE is still running, OhShii’s backend and the ONS DAO are short-lived controllers of that campaign’s canisters — so the platform can deploy them, wire up the pool, and finalize the LGE. The instant the LGE completes, both are removed on-chain and the campaign becomes a fully autonomous SONS DAO that only its own token holders govern — ONS can never touch it again.

Holders vote with OHSHII voting power, and critical proposals are guardian-vetoable. Concretely, ONS can:

Collect the ecosystem’s trading fees. Separately from any single campaign, the OHSHII ecosystem pool’s fees are collected by ONS through the pool manager and routed to the ecosystem treasury. This is a different pool and a different DAO from your campaign’s pool above — they are never mixed.
Upgrade the ecosystem’s canisters — including itself. By proposal, ONS can upgrade any Rust canister it controls, commit a new frontend / asset build, and self-upgrade its own governance canister. As with a campaign DAO it can do this in ordered batches: the OHSHII ledger suite (index → ledger → archives, in the enforced order) or an arbitrary set of dapp canisters (code + asset steps, with the governance self-upgrade allowed only as the last step) — with the same all-or-nothing controller pre-flight and large-WASM chunking.
Run cross-canister governed operations. A general, governed call lets ONS act on the canisters in its scope — e.g. manage the OhShii Locker token list, update OHSHII ledger metadata, adjust selected locker lock operations, and drive pool-manager actions — each as its own proposal.
Change controllers, take snapshots, and set the rules of voting. Critical governance operations let ONS add or remove controllers of the canisters it governs, take or restore canister snapshots, and change the voting parameters themselves (quorum, approval thresholds, voting windows, and voting-power rules).
Operate the security Shield. ONS controls the kill-switch of the in-canister firewall (the Shield) that protects the platform from abuse — tightening or relaxing protection by proposal.
Elect, replace, or remove the guardian. The guardian is the trusted holder of the veto on critical proposals; ONS decides who holds that role (or removes it).
Keep the lights on with cycles. ONS can recharge canisters (up to ~10 at a time) from the DAO’s own cycles balance, so the ecosystem stays funded and running.
Signal direction with motions. Non-binding proposals to gauge community sentiment, with no on-chain effect.

Platform infrastructure & protections

Dedicated canisters — a pool manager that creates each LGE’s liquidity pool and, when the campaign completes, hands that liquidity position to the campaign’s own autonomous SONS DAO (it never keeps the position, and is not blackholed), plus a separate storage canister holding all LGE data, referrals, and participation records (for scalability).
Refund system — if a campaign fails to sell out, contributors and the creator can claim on-chain refunds within a 7-day window, paid from the funds held for that campaign (never from the OhShii treasury) — no off-chain process to trust. See Refunds.
Optional lock-points utility — holders of any OhShii token can choose to lock it in OhShii Locker (locker.ohshii.io) to earn lock points — a signal third-party dapps can read to gate features or rewards. The Locker is a standalone locking app, not a manager of your token: it never controls, upgrades, or governs the token or its SONS DAO.

Standalone Token Minting

An alternative way to create tokens (separate from LGE functionality). Create custom tokens for your dApps without mandatory liquidity generation. You can customize the following:

Token name, symbol and logo
Decimals and transfer fee
Initial supply and initial balance distribution
Minting account (no minter / fixed supply, or a custom minter principal)
Subnet selection

Newly minted standalone tokens are deployed with default operational controllers — CycleOps for automated cycle monitoring and optional top-up, and NNS Root for open canister-status reads and IC-level emergency recovery (the index canister also keeps the OhShii backend as a controller for maintenance). None of these can mint your token or change its supply.

Note: if you choose the “No Minter” fixed-supply option, a community blackhole canister is used only as the token’s minting account — that is a minter, not a controller, so it cannot manage the token either.

After the sale: full DAO autonomy

While the sale is running, OhShii’s backend helps operate the campaign. The moment the sale completes and the pool is live, OhShii removes itself as a controller of your DAO’s governance canister — it can no longer upgrade, modify, or interfere. From then on, your token holders govern everything by vote.

For the exact controller structure at each stage (creation vs. after finalization), see the Architecture reference in the developer docs.