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.
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.
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.
The top-level creator workspace: collections, generators, vendors, media, access, whitelists, beneficiaries, revenue presets, treasury, and Toko Reputation all hang off it.
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).
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.
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.
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.
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.
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.
(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.
The per-collection template for claim cost (per tier) and optional claim requirements. They have no lifecycle of their own and — since R81 (2026-07-22) — no gate either: fully optional, shown as informational coverage on the collection checklist. The pricing gate lives on the vendor: before a vendor's Review/Live every tier must resolve to a cost on the vendor's copy ("Reviewed, stocked and priced"). Editable in every collection state, non-retroactive; a vendor imports them per source collection (when present) and edits its own copy.
Optional eligibility gates on a tier, always combined with AND, never OR (an empty set = anyone can claim). Variants: On a whitelist (V1 — several selected lists merge into one de-duplicated eligible list: being on any one of them passes); 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 gates are V1 (ratified 2026-07-22 — authorable, shown publicly, enforced and re-validated at settlement; hotkeyed neurons count; eligibility is a live check — one neuron backs claims across any number of drops, capped at a configurable claims-per-neuron limit per vendor (default 1) counted regardless of hotkeyed address, ruled 2026-07-22). Token-hold is front-end V2 (backend schema in V1, fail-closed) — V1 authorable requirements: whitelists + the two stake gates.
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.
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.
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.
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.
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.
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.
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.
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.
The unlock tree spending (committing) Reputation. Front end is V2; the backend schema (accrual, committed/available, unlock records) ships in V1.
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.
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.
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.
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: 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).
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.
See locked_sale_split: the platform-wide fallback royalty (1% → project treasury) for copies never distributed through a vendor.
The gated collection type (platform allowlist — Toko-only at first, never a Reputation unlock) for custody-backed physical items. Every token is a 1/1 backed by a vaulted item; no variants, ever; an asset spec is required; the only archetype whose tokens can enter vault custody.
A vetted custody company holding physically-redeemable stock. One registry entry per physical vault; stages Draft → Review → Live (+ Suspended — frozen read-only, history preserved forever).
The vault workspace roles, granted per vault location. Vaultie = any vault team member. Dweller = intake + redemption fulfilment. Overseer = a Dweller who also manages vaulties, edits the vault profile, and countersigns high-value dispatches.
The per-(token, vault) state machine, separate from the token's own status: awaiting processing → vaulted → redeem requested → shipped → delivered | lost-in-transit | returned-to-sender | disputed — post-ship states live here; the token itself stays Redeemed. Every transition is logged and feeds the public custody timeline.
The per-(collection × vault) two-party handshake: Draft → Proposed → Active; either party may propose amendments, flagged for the other's review; pending changes never freeze operations. Nothing ships to a vault without an Active arrangement; RWA go-Live requires one with a Live vault. It summarises an off-platform contract — Toko is never the counterparty.
The platform-admin-gated bulk action (never available to vaults) for relocation (records move to a new registry entry, history preserved) and emergency (vault failure: records annotated custody-uncertain, owners notified, emergency migration or return). The sanctioned exception to "no vault→vault transfer".
Exchanging a vaulted token for its physical item. The holding locks the moment Redeem is pressed (no sale, transfer, burn, or listing; Redeem is blocked while listed). Unlock = pay shipping (direct to the vault) or cancel; unpaid requests auto-cancel after 30 days. Payment makes it binding; Redeemed (terminal) lands at tracking entry. Customs are the redeemer's responsibility.
Three distinct per-item values, never conflated: declared (customs + carrier claim, set at fulfilment) · insured (custody insurance, set at intake, public) · oracle (pricing suggestion engine — rolling market average, never binding).
Every purchased RWA token includes 12 months of vault storage; each paid sale restarts the year (free transfers inherit the remaining clock). After that: sell, redeem, or arrange with the vault directly — if the holder does nothing, Catcha absorbs the cost; nothing is ever confiscated.
Periodic Overseer count confirmation — physical items vs custody records, per collection; mismatches raise flags; shown publicly as "Last audited {date}". Ships with the vault directory.
A named, project-level template of required media slots, applied to token types (batch, snapshot-on-apply, versioned) and enforced as a go-Live gate. Verifies existence only, never content — human Review stays the content check. Deliberately not NFT-specific: tokens are simply the first consumer.
A slot is one required-media position in the template. Its key is the immutable machine slug files bind to; its label is the freely-renameable display name (unique within the spec); plus optional description, explicit sort order, allowed filetypes + max size, and max_files (default 1, schema-only in V1). At most one slot carries the primary-asset flag — its file becomes the token's card image.
Derived, never stored: Missing · Uploading · Present · Failed. The gate counts only Present. Replace is atomic (never transiently empty); replaced files are retained as recoverable version history.
A durable, pull-based, per-principal message queue — no push, no device registration. Events append rows; the badge shows the unread count; rows persist across sessions and devices until read or dismissed. Ordered by occurred_at (event time).
Flood control, not a digest: a new event matching an unread row's kind + subject updates that row (count +1, occurred_at refreshed) instead of appending. Per-source cap: 5 unread rows per subject.
The idempotency key on notification creation: a replayed or cross-canister duplicate event is a no-op — not a new row and not a count bump.
Every kind carries a severity (info · success · warning · error · critical) and one category: Marketplace · Studio · Billing · Projects · Access & security · Vault. Access & security is platform-native only — login/device events belong to Internet Identity, invisible to Toko.
Persistent kinds (payouts, moderation, Access & security, cycle runway) never expire unread; informational kinds expire even unread after ~90 days. Read rows purge after 7 days; 50-row cap with the drop ladder (read → expired → coalesce → informational unread → persistent last).
Five guarantees: best-effort side effect · idempotent creation on event_id · at-least-once with duplicate suppression at insertion · authorization at the destination, never at read time · rows are immutable records (a dead deep-link lands on "This item is no longer available", never an error).
The creator of a project: the unique, permanent first role on a project (the account that created it). "Creator" always means this project role — never a platform-wide permission.
Renamed 2026-07-21 (formerly "creator access", R58) — the platform-level capability that lets an account use the creative studio (create projects and collections). Requested via the public request modal; granted / revoked / restored by Toko admins. Distinct from Creator: studio access is account-wide and Toko-granted; Creator is per-project and automatic.
The auth-level identifier of an account on the IC; what routes like /profile/:principal and transfers resolve against.
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.
Source of truth: Design Documentation/glossary.md (updated 2026-07-21). This page mirrors it for easy browsing — when they disagree, the markdown wins and this page needs a refresh.