Vendors & revenue, explained

A collection is a set you made; a vendor is where someone picks one up. It's the stall that hands out tokens — on a schedule, under rules you set, for a price you choose. When a token leaves the stall, a revenue preset decides where the proceeds go. This article covers both halves: distribution, then payout.

What a vendor is

A vendor distributes tokens that have already been minted into a collection. It doesn't create tokens — it holds inventory and hands it out under a claim policy. On Toko a vendor is project-scoped: it lives at the project level (decided 2026-06-22), so a single vendor can distribute tokens drawn from more than one of the project's collections, and it settles into its own account.

Vendor, not mint

Minting puts tokens into a collection; the vendor is a separate step that gives them out. Keeping the two apart means you can prepare inventory quietly, then open the stall when you're ready — and close it without touching the collection behind it.

Two kinds of stall

Toko is building toward more than one vendor style. The first is the straightforward one; the others are designed but not yet live:

Market vendor — a direct stall: a claimer picks a token (or a tier) and claims it under the rules you set. This is the vendor type available today.
Gacha vendor (designed, not yet live) — a lucky-dip: the claimer pays for a draw from a visible prize pool and receives a random token. Draws are deterministic and auditable, so the odds are honest. Still in WIP design.

The vendor lifecycle

A vendor has two clocks. Like everything else on Toko it moves through Draft → Review → Live as you build and approve it. Once Live, it also has a runtime status that you drive with start / pause / resume / stop:

Runtime status, once a vendor is Live

Setup → Running ⇄ Paused → Empty → Ended · Faulted if something needs attention

There's no separate approval gate at runtime — validation happens per token as inventory is staged. Running hands out tokens; Paused holds the queue without losing state; Empty means inventory is exhausted; Ended is closed. When a vendor ends, its termination policy decides whether unclaimed tokens are returned to the project or burned.

Claim rules: who can claim, and what it costs

The claim policy is where you shape the drop. Rules can be set for the whole vendor or per tier, and tiers inherit sensible defaults so you only override what you need:

What a claim rule can set

Lever	What it does
Cost	v1 · required. Free, an ICP amount, or an ICRC-1 token — can differ by tier. An unset cost blocks go-live.
Requirements	v1 · optional. Eligibility gates — an allowlist entry, or holding a token / neuron — combined with AND, set per tier.
Restrictions	v2. Limits like a claim cap per verified human — a creator-level unlock (burn $TOKO).
Rewards	v2. A payout to the claimer on claim — also a creator-level $TOKO unlock.

v1 ships Cost + Requirements. Restrictions and Rewards are v2, unlocked at the creator level. Allowlists come from the project's shared whitelists, so the same gated audience can be reused across drops. A tier with no explicit rule falls back to the vendor's default.

Revenue presets: where the money goes

When a claim is paid, the proceeds are split according to a revenue preset — a named split template that lives at the project level. You build presets once and reuse them. A vendor picks a Live preset when it's created, and that choice is snapshotted onto the vendor. Editing the preset later won't silently rewrite the terms of vendors already using it.

Snapshot, not a live link

Because the split is captured at creation, a claimer's terms can't change underneath them after they've claimed, and you can safely evolve your presets for the next drop without disturbing the last one.

What's in a split

Proceeds come off the top as fees, and the rest goes to your beneficiaries — only beneficiaries who are Live qualify to be paid:

Where a claim's proceeds go

Your beneficiaries · 92%

Project / cycles — required, ~1–10% Toko contribution — optional, 0–10% Beneficiaries — the remainder

Figures are illustrative. The project/cycles fee is required; the Toko contribution is optional. Where royalties are configured, each is capped at ~10%, with total royalties ≤20% (and non-project royalties bounded separately) — caps that keep any single split honest.

Royalties over time

Royalties don't have to last forever — or they can. A royalty runs either Forever or for a fixed period (1, 3, 6, 9, 12 or 24 months), and over that period it can taper so the cut shrinks as time passes. The clock starts when the vendor is Running.

Taper shapes

Forever / No taper

Flat — the same cut the whole time.

Cliff

Holds, then drops at the end.

Linear

Eases down evenly to zero.

Curve

Stays high, then falls away faster.

A taper lets you reward early activity more heavily without cutting creators off abruptly. Pick the shape that matches how you want the drop to age.

Buyback

A vendor can also run a buyback — an offer to buy tokens back from holders, set as a percentage (around 1–20%) over a duration. Buyback proceeds are held in the vendor's own subaccount, so the funds backing an offer are kept distinct from the rest of the project's balances.

One technical note

Because a vendor settles from its own subaccount, that account can double as the escrow account per ledger — which is why the design keys it by something unique like collection_id + tier + payment_ledger. You don't need to think about this to run a drop; it's how the plumbing stays separated underneath.

In short

A vendor distributes already-minted tokens; it's project-scoped, so one stall can span collections.
Market vendors are live today; Gacha (auditable lucky-dip) is designed but not yet live.
Vendors go Draft → Review → Live, then run through Setup → Running ⇄ Paused → Empty → Ended.
Claim rules set cost, requirements, restrictions and rewards — per vendor or per tier, with allowlists from the project.
Revenue presets are project-level split templates, snapshotted onto a vendor; fees come off the top, beneficiaries get the rest.
Royalties can run forever or for a fixed period with a taper; buyback repurchases tokens from a vendor subaccount.