Frequently asked questions.

Toko is a digital asset platform built on the Internet Computer.

It gives creators the tools to create, launch, manage, and trade digital collectibles from one place.

Toko includes a Generator for layered artwork, a Wallet for holding assets, a Launchpad for new drops, and a Marketplace for peer-to-peer trading.

Toko is organized into three main layers:

Project
The top-level creator workspace. This is where teams manage media, whitelists, beneficiaries, and vendors.

Collection
The rule layer for a specific set of tokens. It defines things like attributes, rarity, supply, and token policy.

Vendor
The distribution layer. A vendor acts like a stall where tokens can be sold, claimed, or distributed.

The Generator sits alongside the collection. It handles the artwork, while the collection controls the rules.

You can browse public areas like the Launchpad and collection pages without signing in.

To use wallet features such as My Tokens, you need to sign in with your Internet Computer identity.

Once signed in, Toko checks ownership against your principal, so your tokens are linked directly to your identity.

Open My Tokens from the authenticated sidebar to view everything owned by your account.

You'll see your NFTs, fungible token balances (ICRC1 and NNS), and your recent transaction history all in one place.

You can currently:

• Transfer a token to another principal.
• Burn a token permanently.

Both actions require confirmation before they are processed.

Additional features such as marketplace listings, auctions, token splitting, merging, and other advanced operations are planned for future releases.

No. Burning a token is permanent and cannot be undone.

The token is removed from circulation, while a historical record of the burn remains on the ledger to preserve provenance and supply tracking.

Your wallet displays the fungible tokens associated with your account, including ICRC1 and NNS balances.

Each balance shows the token name, symbol, and current amount held.

In the current release, balances are view-only. Sending, swapping, and other fungible token operations are not yet available.

Transaction history provides a record of recent activity across your NFTs and fungible tokens.

Each entry may include:

• Transaction type (received, sent, minted, burned)
• Amount or token involved
• Sender and recipient principals
• Timestamp
• Transaction reference, where available

You can view all activity together or filter by asset type.

Claimed tokens usually appear in My Tokens shortly after the claim is confirmed.

If you don't see the token immediately, refresh the page. Some areas of Toko may also update automatically when ownership changes.

Before processing a transfer, burn, or other wallet action, Toko verifies that the token is still in a valid state.

An action may be blocked if:

• Ownership has changed.
• The token's status has changed.
• The token is temporarily locked.
• The token is listed for sale and cannot be transferred or burned.

If this happens, refresh the page and try again.

The Launchpad is where you discover and claim new drops on Toko.

The default view is a gallery of all live vendor drops, alongside a Coming Soon rail and a Recently Ended rail.

It's designed to feel editorial and collectible-first, rather than a dense trading interface.

Each label reflects a vendor's real state:

• Coming soon — scheduled, before its start time.
• Live — running and claimable now.
• Ending soon — running with roughly two hours or less remaining.
• Sold out — inventory is exhausted.
• Ended — finished, and shown only for a short retention window afterwards.

Paused and faulted vendors are hidden from the Launchpad.

Open a vendor's Launchpad detail page and, if the drop is live and you're eligible, the button reads Claim now.

Claiming is explicit: you'll see your wallet and payment context before confirming, and inventory is consumed atomically.

If you don't meet the drop's requirements, the button reads View requirements instead.

Creators can attach conditions to a drop, such as:

• Holding a particular token
• Staking
• Being on an allowlist
• A per-person claim limit

If you don't meet them, you'll see View requirements rather than Claim. Eligibility is always re-checked at the moment you claim.

Live vendors, Coming Soon, and Recently Ended are available today.

Featured, Trending, Newest, and Recently Claimed are planned, but the curation tooling behind them isn't built yet.

The Marketplace is where collectors buy, sell, and trade tokens after they have been minted.

It provides a transparent view of listings, pricing, ownership history, and trading activity across supported collections.

Whether you're looking to expand your collection or sell a token you already own, the Marketplace is the place to do it.

No. Toko's Marketplace is non-custodial.

Your token remains in your wallet while it is listed for sale. Toko never takes ownership of your asset.

While a listing is active, the token is temporarily locked to prevent transfers, burns, or other conflicting actions.

If you cancel the listing, the token becomes fully available again.

Toko is designed to support multiple ways to buy and sell tokens.

• Buy Now — Purchase immediately at a fixed price.
• Auctions — Competitive bidding with configurable rules.
• Offers — Negotiate directly with collectors through offers and counter-offers.

Vendor buybacks are also planned and will use the same offer system.

These features are still under development and may change before release.

The Launchpad is where new tokens are first distributed through drops and claims.

The Marketplace is where collectors trade tokens that are already in circulation.

The Collection Hub provides information about a collection and links to its Launchpad activity and Marketplace listings.

In short: Launchpad for new drops, Marketplace for trading, Collection Hub for discovery and context.

The Generator helps you create large collections of unique artwork from layered assets.

Upload and organize layers such as backgrounds, bodies, clothing, and accessories, then define how those parts can appear together.

Once configured, the Generator assembles unique tokens automatically. You can review the results, pin your favourites, and export them directly into a collection.

The Generator is responsible for creating artwork. Collection settings such as rarity and distribution are managed separately.

Deterministic generation means the same inputs always produce the same results.

If you generate a batch using the same configuration, seed, and source data, Toko will recreate the exact same tokens every time.

Every export includes a locked snapshot of the settings used to create it, making collections easy to audit, verify, and reproduce in the future.

No. Weighting and rarity are intentionally separate concepts.

Weighting controls how often a part appears during generation. For example, a hat with a higher weight is more likely to be selected than a hat with a lower weight.

Rarity is defined at the collection level and determines how uncommon a finished token is considered to be.

Toko includes simple weighting presets ranging from Very Infrequent to Very Frequent, or you can provide custom values for finer control.

The Generator supports several creation workflows:

• Create a full batch of unique tokens.
• Generate a single token for testing.
• Create tokens from a CSV file using predefined values.

During generation, Toko selects parts from each layer, applies weighting rules, checks compatibility requirements, and ensures every generated token is unique.

Invalid combinations are automatically rejected until the desired number of valid tokens has been produced.

Tokens are added to collections through the Generator's export process.

After generating artwork, review the results, pin the tokens you want to keep, and export them directly into a collection.

Exported tokens arrive as Draft items with their generation history and composition data attached.

Each collection is linked to a single Generator source, ensuring provenance remains clear and consistent throughout the collection's lifecycle.

Collections move through three stages:

• Draft — Build and configure your collection. Everything remains editable.
• Review — Make the collection publicly viewable while continuing to refine it.
• Live — Publish the collection and lock its core rules.

A token can only be made Live after its collection has reached the Live stage.

Going Live permanently locks the collection's core policies and supply rules.

This includes settings such as:

• Maximum supply
• Rarity configuration
• Attribute definitions
• Supply limits and distribution rules
• Guardian settings

Visual content such as descriptions, thumbnails, and banners can still be updated after launch.

New token definitions can also be added later, but they must operate within the collection rules that were locked when the collection went live.

The Guardian defines the promises your collection makes to collectors.

These settings determine whether tokens can be duplicated, destroyed, transferred, or sold under specific conditions.

Once a collection goes Live, Guardian settings are locked so collectors can rely on those guarantees.

Some Guardian rules are currently informational while full backend enforcement continues to be developed.

Collections can define limits on total supply, the number of unique token definitions, and the number of copies that can exist for each token.

Each token definition receives a permanent issue number when it moves from Review to Live.

Issue numbers are assigned once, never change, and are never reused.

Individual copies also receive their own immutable copy identifier, allowing collectors to distinguish between multiple copies of the same token.

Creators can choose whether issue and copy numbers are displayed to collectors.

Yes, but only if no tokens have been minted from the collection.

Once a token has been minted, the collection becomes part of the permanent record and can no longer be deleted.

Deleting a collection always requires confirmation before the action is completed.

Attributes are the properties a token can have. They're defined at the collection level, not in the Generator.

A token type groups tokens that share the same set of attributes, and traits are the specific values those attributes take.

Artwork composition from the Generator is treated as evidence that the attribute system can map into attribute values — the Generator never stores attributes directly.

On the Attributes page you assign numeric values to attribute options, then choose how they combine.

Three calculation methods are available: Add Values, Multiply, and Highest.

Unmapped values are simply skipped — they aren't counted as zero unless you explicitly map them to zero. The result becomes the token's attribute score, which feeds its overall score.

Rarity is set at the collection level, and every collection starts in Uniform.

• Uniform — every token is treated as equal.
• Tiered — you define your own tiers and assign them by hand; the system shows score guidance but never picks for you.
• Weighted — Toko's fixed official tiers (Common, Uncommon, Rare, with Epic and Legendary unlockable), assigned automatically by score.

Switching models requires confirmation and resets any rarity assignments you'd made. For a full walkthrough, see the Rarity article.

You shape the curve with two dials, and Toko computes the per-tier quotas over your Max Supply:

• Ratio — how much scarcer each rarer tier is than the one below it.
• Accelerator — how steeply the curve bends toward the rarest tiers.

The defaults (Max Supply 1,000, ratio 3, accelerator 1.0) produce roughly 69% Common, 23% Uncommon, and 8% Rare.

A tier's quota is a mint budget — a cap on how many copies across that whole tier can ever be minted.

It is not a cap on how many token definitions can carry the tier. You can author more "Rare" definitions than the Rare budget allows.

The budget is enforced only at mint, first-come, and it's frozen when the collection goes Live.

No. Toko never re-tiers tokens silently in the background.

A collection-wide redistribution only happens when you run an explicit Rebalance.

You can also override any token's tier by hand; an overridden token is excluded from rebalances until you undo it, and its tier locks permanently when the collection goes Live.

A token's final score is its attribute score multiplied by a layer multiplier.

The attribute score comes from the numbers you map onto attributes, combined using Add Values, Multiply, or Highest.

The layer multiplier scales the result based on generator-layer weighting. When no generator is linked it's 1.0, so the final score simply equals the attribute score. For a full breakdown, see the Token score article.

No. Score is a number; rank is a token's position relative to others.

Rank is always calculated within a single token type, never across the whole collection — otherwise types with more scoring attributes would dominate the top tiers.

The interface always shows the scope, for example "Score Rank is within Character · 312 tokens".

A score is "stale" when something that feeds it has changed and it hasn't been recalculated yet.

Triggers include editing composition or attribute values, changing the value mapping, adjusting layer weights, or switching the calculation method.

A token can't move from Review to Live while its score is stale, so live tokens always reflect their current inputs. A bulk refresh recomputes all stale scores at once.

No. Whether a token's score is shown to collectors is a separate, per-collection setting, independent of the rarity model.

A vendor is a distribution mechanism — the configured "shop" that hands tokens to collectors.

Each vendor has its own storefront, lifecycle, inventory, costs, rules, and revenue settings.

A vendor's inventory is backed by minted tokens, not draft definitions.

Vendors are project-scoped. A single vendor can distribute minted tokens from several of a project's collections.

Revenue templates are managed at the project level, while collection defaults are managed at the collection level.

Each vendor settles payments — and holds any buyback proceeds — from its own account.

Market vendors, which sell specific tokens, are available first.

Gacha and GachaRwa vendors, which distribute randomized rewards, are designed but deferred to a later release.

At launch, expect Market vendors only.

A claim returns a randomly selected reward from the vendor's prize pool.

There are two draw modes: uniform lucky dip (equal chance per available unit) and weighted (odds based on configured weight and remaining quantity).

The full prize pool — including sold-out entries — is always visible, and every draw is deterministic and fully auditable. Gacha is not part of the first launch.

Vendors support claim costs by tier, along with requirements, restrictions, and rewards.

Requirements can include holdings, staking, or allowlist membership, and are evaluated per tier. Higher tiers inherit rules from lower tiers where they aren't set explicitly.

Allowlists come from your project's whitelists, and you can also set per-person claim limits.

A vendor has a stage (Draft, Review, Live) and a runtime status (setup, running, paused, empty, ended, faulted).

You can start, pause, resume, restart, or stop a vendor. There's no separate vendor approval step — validation happens per token at Review to Live.

When a vendor stops, any unclaimed inventory is either returned to inventory or burned, depending on its termination policy.

Revenue is configured through Revenue Presets — named, project-level split templates created in Project → Revenue presets.

When creating a vendor, you select a Live preset, and its values are copied onto the vendor as a snapshot.

Editing a preset later doesn't change vendors that already use it. Claim presets are available first; Sale presets are a future addition.

A split takes fees off the top, then optional royalties:

• Project / cycles funding — required, roughly 1–10%, which funds your project canister.
• Toko contribution — optional, 0–10%.
• Royalties — optional, paid to your beneficiaries.

Individual royalties are capped around 10%, total royalties around 20%, and non-project allocations around 40%. Only Live beneficiaries can receive royalties — to pay yourself, add yourself as a beneficiary.

Yes. Each royalty can run Forever or for a fixed period (1, 3, 6, 9, 12, or 24 months).

A fixed-period royalty uses a taper — No taper, Cliff, Linear, or Curve — that changes the effective percentage across the period.

The taper clock starts when the vendor first goes Running.

A buyback is an offer from a vendor to buy a token back from a collector.

It's configured at the vendor level — not in the revenue preset — as a vendor percentage (roughly 1–20%) over a set duration.

Buybacks run through the same shared offer system as the marketplace, and proceeds are held in the vendor's account until release.