CaffeineAI

Integrating a Token into Your CaffeineAI dApp

When you build a dApp with CaffeineAI, you can attach an OhShii token to it. There are two ways to create the token, and a third way to “upgrade” one of them into a DAO later:

1. LGE — launch the token through a Liquidity Generation Event. It becomes a governance token from day one: every LGE auto-deploys a per-campaign governance canister (a DAO) that can control and upgrade your dApp’s canisters by on-chain vote.
2. Standalone token — mint a token without an LGE (no DAO by default). Use it for any dApp utility — for example, let your dApp’s backend canister mint rewards programmatically.
3. Convert later (Imported DAO) — take a standalone token you minted (or one deployed elsewhere) and turn it into a governance token without an LGE, so it can govern your dApp’s canisters and its ICPSwap pool.

Each is described below.

1. LGE path: a governance token that controls your dApp

Launching via LGE gives your token a per-campaign governance canister (a DAO, sons_governance) the moment the campaign is created. Token holders govern it with quadratic voting on locked tokens, and at completion OhShii steps back so the DAO is fully autonomous (the launcher backend and OHSHII governance remove themselves as controllers). The creator is never a controller of the token.

The real power for a dApp: that DAO can control and upgrade external canisters — including your CaffeineAI dApp’s backend and frontend.

How it works

1. You (the current controller of your dApp’s canisters) add the campaign’s governance canister as a controller of those canisters.
2. From then on, the DAO can manage them by proposal: upgrade the backend (UpgradeCanister / UpgradeDappBatch), commit new frontend assets (UpgradeAssetCanister), and add/remove controllers (AddController / RemoveController). The on-chain check only requires that the governance canister is already a controller of the target — there is no restriction that the canister was created on OhShii.
3. The same DAO also governs the token’s ICPSwap pool.

So an LGE token turns your dApp into a community-governed application: upgrades and changes happen through token-holder votes, not a single admin key.

Note: an LGE token is not “automatically listed on OhShii Locker.” OhShii Locker is the front-end interface for creating and managing locks; it is not auto-populated by every LGE. (Lock-based utility is described below.)

You launch an LGE from the Launch LGE flow in the launcher app.

2. Standalone token minter: programmatic minting for your dApp

The standalone minter creates a token without an LGE and without a DAO. With it you define:

• the minting account (minter),
• decimals and transfer fee,
• initial supply (which can be 0), and
• the subnet.

You do not choose the canister controllers — a standalone ledger is always created with cycle-monitoring controllers (CycleOps + NNS Root), and the creator is not a controller. What you control is who holds the minter role.

Minter vs controller. The minter (minting account) governs token supply — minting and burning. A controller can upgrade/stop/configure the canister. These are different roles: choosing a custom minter does not make you a controller.

Backend minting

Set your CaffeineAI dApp’s backend canister as the Custom Minter when you create the token. On the launched ledger, a transfer whose sender is the minting account creates supply, so your backend mints simply by calling icrc1_transfer from itself to the recipient (and a transfer to the minting account burns supply). This is ideal for dynamic issuance:

• usage-based or activity rewards,
• performance payouts in skill-based / AI games,
• referral and gamification systems (XP, boosts, items).

Standards note: launcher-created tokens are ICRC-1 and ICRC-3 compatible; ICRC-2 (approve / transfer-from allowances) is disabled at creation. Backend minting uses icrc1_transfer, so it is unaffected — but keep this in mind for the Import path below.

You create a standalone token from the Deploy Token flow in the launcher app.

3. Convert a standalone token into a DAO later (Imported DAO)

A standalone token starts with no DAO — but you can later turn it into a governance token with the Import a DAO flow, without an LGE. The launcher deploys only a fresh governance canister (sons_governance) for your existing ledger (no new ledger, index, or pool), links your existing ICPSwap pool, and reads the token name/symbol from the ledger metadata. That DAO can then control and upgrade your dApp’s canisters exactly like an LGE token (Section 1).

• Cost: a fixed 20 ICP platform fee + cycles for one governance canister (~1T).
• Requirements: the ledger must use 8 decimals, advertise both ICRC-1 and ICRC-2, have an existing ICPSwap pool, and not already be attached to another campaign.

Heads-up: because launcher-minted tokens have ICRC-2 disabled, an OhShii standalone token cannot be imported as-is — the Import flow requires ICRC-2. Plan for this if you intend the “mint standalone now, govern later” route (e.g. deploy a ledger that advertises ICRC-2, or use the LGE path if you want governance from the start).

How a governance token brings value to your dApp

A governance token (from an LGE, or a standalone token converted via Import) adds value on two axes:

1. Control & upgrades. Put your dApp’s backend and frontend canisters (and the token’s ICPSwap pool) under the DAO’s control. Upgrades then happen through token-holder votes — decentralized, transparent, and not dependent on a single key.
2. Lock-based utility. OhShii Locker (the lock front-end) exposes a public query, calculate_user_lock_points(user, token), that returns a user’s lock points — a linear score of locked amount × remaining lock time (it decays as the unlock date nears). Your dApp can read it and gate features without building any lock logic of its own. Today the user-lockable token is OHSHII; new-token listing on the Locker is currently restricted, so plan lock-points gating around OHSHII. (Lock points are not voting power — voting power is a separate quadratic score.)

Examples your dApp could build on top of lock points (your policy, not OhShii features): membership tiers, time-gated modules, beta access, or fee discounts.

How to find your CaffeineAI dApp’s backend canister ID

CaffeineAI dApps do not use dfx / icp or PUBLIC_CANISTER_ID_* env vars — Caffeine wires the frontend to the backend differently. The Caffeine frontend template ships a file src/frontend/env.json:

{
  "backend_host": "undefined",
  "backend_canister_id": "undefined",
  "project_id": "undefined",
  "ii_derivation_origin": "undefined",
  "storage_gateway_url": "undefined"
}

When Caffeine deploys/serves your app, it replaces these "undefined" placeholders with the real values, and the build copies env.json into dist/. So to find your backend canister ID, read the backend_canister_id field of the deployed env.json (in the code at runtime, or by opening env.json from the served app). That value is the principal you set as the Custom Minter for backend minting.

In a nutshell

Path	What it gives you
1. LGE	A governance token + per-campaign DAO. Put your dApp’s canisters under the DAO’s control and upgrade them (backend + frontend) by vote; the DAO also governs the token’s ICPSwap pool.
2. Standalone minter	A token with no DAO: you choose the minter, decimals, fee, supply (can be 0), subnet. Set your backend as the minter and mint via icrc1_transfer. Controllers are fixed (CycleOps + NNS Root); the creator is not a controller.
3. Import a DAO	Convert a standalone (or external) token into a governance token later — deploys only a governance canister, links the existing pool. Requires 8 decimals + ICRC-1/2 + an existing pool.

Three approaches, all compatible with CaffeineAI — pick governance from the start (LGE), utility-first (standalone), or standalone-now-govern-later (Import).