Creating a Standalone Token

The Deploy Token flow creates an ICRC token without running a Liquidity Generation Event (LGE). It is the path to take when you want a token your own dApp drives — custom minting account, custom parameters, programmatic minting — rather than a fair-launch campaign with a bonding curve and a DAO. The two paths are distinct: standalone tokens are deliberately not auto-listed on OhShii Locker (only LGE tokens are). See the full flow in Core Workflows.

Creation flow

Standalone creation is a two-call ICRC-2 payment then a deploy. The user pays 5 ICP; the backend verifies the payment and deploys the token’s ledger and index canisters. No governance canister, bonding curve, escrow, or pool is involved — those belong to the LGE path.

Step	Method (ohshii_launcher_backend)	What happens
Prepare	prepare_token_creation()	Returns payment_info (amount, expiry, subaccount).
Approve	ICP ledger icrc2_approve(backend, amount)	User authorizes the 5 ICP collection.
Deploy	create_token_with_icrc2_payment(args)	Backend runs icrc2_transfer_from to collect, allocates funds, deploys the ledger + index, returns Ok(ledger_id, index_id).

sequenceDiagram
  participant User
  participant Frontend
  participant ICPLedger
  participant Backend

  User->>Frontend: Deploy token (metadata, payment)
  Frontend->>Backend: prepare_token_creation()
  Backend-->>Frontend: payment_info (amount, expiry, subaccount)
  User->>ICPLedger: icrc2_approve(backend, amount)
  Frontend->>Backend: create_token_with_icrc2_payment(args)
  Backend->>ICPLedger: icrc2_transfer_from (collect)
  Backend->>Backend: allocate funds, deploy ledger + index
  Backend-->>Frontend: Ok(ledger_id, index_id)
  Frontend-->>User: Token created

The deployed token is ICRC-1/2/3 compliant and ships with an index canister for transaction tracking — the same ledger + index infrastructure every OhShii token receives.

What you can configure

The standalone minter exposes the token’s economic and custody parameters at creation time:

Parameter	Notes
Minting account	The account authorized to create supply — a transfer from it is a mint. Permanent, and it defaults to the management canister (aaaaa-aa), which can never mint. Set it to your dApp’s backend canister to mint programmatically (see below). What “fixed supply” does and does not guarantee is covered in STANDALONE_TOKENS.md §1-bis.
Subnet selection	Choose the subnet the token canisters are deployed on.
Transaction fees	The per-transfer ICRC ledger fee.
Decimals	Token decimal precision.
Initial balance distribution	The starting supply allocation. May be set to 0 when supply will be minted later by your backend.
Controller	The token creator is always a controller; further controllers are creator-chosen (see below).

Because these parameters are creator-defined rather than the LGE’s standardized, pre-tested configuration, standalone tokens are not added to OhShii Locker — this preserves the Locker’s security and integrity by only listing tokens whose configuration is verified and uniform and whose creator is not the controller.

Controllers

Every standalone token is deployed creator-controlled:

Controller	Added	Removable?
The creator	always	never dropped by any platform flow (anti-lockout)
Up to 8 more, creator-chosen — including the opt-in monitoring canisters (CycleOps balance checker, NNS Root status passthrough)	only if the creator explicitly picks them	yes

The OhShii backend is never a persistent controller — it is rejected even on explicit request. OhShii operates as an escrow, not a custodian: the backend holds control only transiently (during the install, and during updates the creator signs a temporary grant for) and removes itself on every exit path. Nothing else is ever added on the creator’s behalf. The full ownership model — the non-custody rationale, what a controller can actually do, what each opt-in monitoring canister costs, and how to shrink the list down to the creator alone — is in STANDALONE_TOKENS.md §2. The LGE token controller structure is analogous in spirit: the OhShii backend and OHSHII governance hold control only until finalization and are removed at that point to hand the DAO full autonomy.

Backend minting via icrc1_transfer

When you set your dApp’s backend canister as the minting account at creation time, minting becomes a single ICRC-1 call: because the minting account is authorized to create supply, calling icrc1_transfer from that backend canister to a target address effectively mints new tokens to that address. No separate mint endpoint is needed.

This is the model for dApps that need dynamic or continuous issuance — usage-based rewards, activity incentives, performance payouts in skill-based games, referral programs, and gamification (XP, boosts, digital items). Pair it with an initial balance of 0 so all supply originates from your backend’s icrc1_transfer calls.

Standalone vs LGE — when to use which

Path	What it gives you	Locker listing
LGE (Launch LGE)	Bonding-curve fair launch, per-campaign governance canister, automatic ICPSwap pool at finalization, standardized parameters, refund-on-failure.	Automatic — only LGE tokens are auto-listed.
Standalone (Deploy Token)	Custom minting account, controller, subnet, decimals, transfer fees, initial balance; programmatic minting from your backend.	Not auto-listed (creator-defined config).

For the LGE creation, participation, and finalization flows, see Core Workflows.

References

• ohshii_launcher_backend — prepare_token_creation, create_token_with_icrc2_payment (src/backend/src/lib.rs).
• Core Workflows — Create Token (§2), Create LGE, finalization, refunds.