Toko · Reference

Glossary.

Canonical definitions for the terms Toko uses — defined once, used consistently everywhere. When a doc and this glossary disagree, the glossary wins. Source of truth: Design Documentation/glossary.md.

Burn vs Destroy — the load-bearing pair

Burn

A voluntary owner action that permanently removes a token the owner holds — a manual burn, or a transfer to a zero address. Burning is always available to an owner: no guard, flag, or policy ever prevents an owner from burning what they own. (Like any mutation it requires the holding to be unlocked — a listed token's sale-lock must be cancelled first, itself an owner action.) Irreversible; the burned copy is retained in ledger records with Burned status for audit and supply accounting.

Destroy

An involuntary action: game logic or a system action makes a token cease to be accessible or usable, without the owner choosing it. Gated by the collection's destruction guard (allow_token_destruction) and the token's frozen can_destroy field. With the guard off, no game logic can ever destroy a token in the collection — the buyer's guarantee. The guard says nothing about burning.

Lifecycle & structure

Project

The top-level creator workspace: collections, generators, vendors, media, access, whitelists, beneficiaries, revenue presets, treasury, and Toko Reputation all hang off it.

Collection

The project-scoped policy boundary for tokens: attributes, rarity, supply, guards, collection defaults. Stages Draft → Review → Live; core policy freezes at go-live (Live = locked), while the roster stays open (monotonic growth).

Token definition

The singular design-time record of a token (Draft → Review → Live). Not a holding. Its issue_number is definition-level and permanent from Review → Live. Review is stage-only: the backend rejects every non-stage update — any edit, rarity included, requires returning to Draft first.

Copy

One minted unit of a definition. Copies carry an immutable per-copy copy_sequence and inherit the definition's issue_number; they never get their own.

Holding

The owned runtime representation of minted copies: a Stack (fungible bucket with quantity) or a Single (individualized unit with optional rich state). One unified TokenHolding model.

Variant

An optional, token-defined, locked-at-Live sub-type discriminator (e.g. Red / Green apple). Part of stack identity everywhere; V1 mints the default_variant only.

Archetype / capacity envelope

The collection shape chosen at creation (Curated Art, Game Items, …) that sets the maximum ceilings (blueprints, total units, copies per token). The archetype ceiling overrides any other rule or default; ceilings are raisable only in Draft and freeze at go-live.

Guards & policy

Guard / Guards

(Never "Guardian".) A per-capability, collection-wide permission (allow_* flags): duplicates, destruction, transfer restrictions, sale restrictions. A guard is either a guarantee that something can never occur, or a warning that it may occur within the collection — off = the guarantee (absolute stop, forever); on = the warning (tokens may opt in). Freezes at collection go-live. Guards exist to future-proof: no future platform feature can ever do the guarded thing inside a collection whose guard is off. The sale- and transfer-restriction guards gate only the per-copy count limits (sale_limit / transfer_limit), not the named states.

Collection defaults

The per-collection template for claim cost (per tier, required) and optional claim requirements. They have no lifecycle of their own — the stage badge on the page is the collection's; the single stage-coupled behavior is the go-Live gate: every tier needs data (a cost — free counts). Editable in every collection state, non-retroactive; a vendor imports them per source collection and edits its own copy.

Claim requirements

Optional eligibility gates on a tier, always combined with AND, never OR (an empty set = anyone can claim). Variants: On a whitelist (V1); Holds tokens from a collection — never "holds a token" — collection_id + quantity ≥ 1; Has a stake — an NNS (ICP neuron) or SNS (ICRC-1 neuron) gate with optional minimum_stake and minimum_dissolve_delay (dissolve delay, not neuron age); a tier may carry one NNS and one SNS gate, both binding. The stake and token-hold gates are front-end V2; their backend schema ships in V1 — whitelist is the only requirement authorable in V1.

Sale / transfer restrictions

Per-copy count limits (sale_limit, transfer_limit): how many times a copy may be sold or transferred. Gated by the sale- and transfer-restriction guards, frozen at token Review → Live (locked_sale_restrictions), authored per token in V2. In V1 every token is freely tradeable with no limits.

Named states (Gift Only / Sale Only / Soul Bound)

Possible per-token restrictions, not yet enabled and not part of the guards: Gift Only = can never be sold; Sale Only = can never be transferred; Soul Bound = can never be transferred or sold. Their gating will be defined if/when they are enabled.

Money

Claim

Primary distribution: paying a vendor's cost (or Free) to receive a copy. Settlement chain: vendor account → split (beneficiaries + Toko) → remainder to the project treasury.

Claim preset / Sale preset (Revenue presets)

Named, project-level split templates. A vendor must select one of each (Live presets only, snapshot copy-on-create, no per-vendor editing). Claim preset: the Toko burn (fees.toko, mandatory 1–10%) + royalties (≤ 20% total). Sale preset: the secondary royalty split, ≤ 3% total.

locked_sale_split

A copy's frozen resale royalty split, stamped at claim from the distributing vendor's Sale preset. Copies claimed from different vendors may carry different splits (and then never stack together). Never-vendored copies (e.g. freely transferred by the creator) use the standing default: 1% of each resale → the token's project treasury.

Referral fee

The seller-set 1–10% of a completed secondary sale (min 1%), paid to the sale's referrer (initially always the Toko Marketplace). Toko's only secondary take; it drives the default marketplace sort and the landing page's Marketplace section (whose cards deep-link to their listings) and Featured example set. The landing hero carousel is the exception — created and managed by Toko, never referral-driven. No sale, no fee. Not part of any preset.

Buyer price rule

The buyer pays the price only; every fee and split comes out of the price, never on top of it. Stack listings and staged vendor stacks are priced per unit: a buyer/claimant takes any quantity 1..remaining (total = qty × unit price), the remainder stays available, and quantity is protected by an atomic check-and-decrement — a race fails cleanly with a one-tap "take the remaining {n} instead" offer.

Toko Reputation

A project's cumulative lifetime $TOKO burned (earned-to-burn from claims ≥ 1%, or paid-to-burn from a wallet). Never decreases; unlocks commit it (available = lifetime − committed). Project-scoped and admin-contingent.

Project Mastery

The unlock tree spending (committing) Reputation. Front end is V2; the backend schema (accrual, committed/available, unlock records) ships in V1.

Treasury

The project's own funds: claim remainders + royalty failsafes. A locked percentage is reserved for cycles (auto-top-up via AMM → ICP → cycles); only the excess is withdrawable.

Supply & rarity

Max Supply

The collection's total supply ceiling — all token types sum together (no per-type supply cap in V1). Clamped to the archetype envelope; frozen into the mint ledger at go-live.

Tier budget / mint budget

The collection-wide, per-tier ledger of mintable copies (quota_units / minted_units), snapshotted at go-live and drawn down first-come at mint. Definitions may oversubscribe budgets; enforcement happens only at mint.

Official rarity tier set (Weighted)

Seven reserved tiers: Common, Uncommon, Rare (default for everyone) · Epic, Legendary (unlock at a Toko Reputation threshold) · Mythical, Inconceivable (future-gated, never creator-unlockable; possibly Toko-granted on super rare occasions). Tiered-mode collections define their own tier names and may not reuse these.

issue_number vs copy_sequence

issue_number: definition-level, assigned at Review → Live, immutable, never reused, shared by all copies. copy_sequence: copy-level creation index used for copy-number display (No. 3/50).

Vendors & distribution

Vendor

A project-scoped distribution mechanism selling minted copies from its fixed source_collections set (editable in Draft/Review, frozen at vendor go-live — no new collections after Live, even with an additive inventory policy; restocking from the frozen set is unlimited). Cannot go Live without inventory. A minted copy sits in at most one vendor at a time. Market is the only type that exists; the type set is open-ended (e.g. Gacha, Tombola, MarketRwa may come; GachaRwa is not planned). Deletable only pre-Live: a Live vendor is ended and remains a read-only record with its on-chain history.

Standing default

See locked_sale_split: the platform-wide fallback royalty (1% → project treasury) for copies never distributed through a vendor.

Identity

Principal

The auth-level identifier of an account on the IC; what routes like /profile/:principal and transfers resolve against.

User ID (usr_…)

The stable Toko platform identity, shown as a copyable chip on the owner's profile. It is what Recipient::User resolves against in revenue presets, and the key the (WIP) friends list is built on.

No matching terms.Try a different word — or clear the filter.

Source of truth: Design Documentation/glossary.md (updated 2026-07-03). This page mirrors it for easy browsing — when they disagree, the markdown wins and this page needs a refresh.