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, or an amount in an accepted currency (ICP, ckBTC, ckETH, ckUSDC, ckUSDT, ckSOL, $TOKO, $DKP) — 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

The required Toko burn comes off the top; the rest goes to your beneficiaries — only beneficiaries who are Live qualify to be paid:

Where a claim's proceeds go

Your beneficiaries · 98%

Toko burn — required, 1–10% of each claim (converted to $TOKO and burned for your project's reputation) Beneficiaries — the remainder

Figures are illustrative. The Toko burn (min 1%) is the only required cut; the rest is your beneficiaries' royalties, each capped at ~10% and ≤20% total. Cycles are not taken from the split — the project funds them from its own treasury. To pay yourself, add yourself as a Live beneficiary.

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 V2

Buyback is a later-release (V2) feature — not in v1, and a candidate to be unlocked via Project Mastery. When it ships, a vendor will be able to offer to buy tokens back from holders for a fee over a set window, with proceeds held in the vendor's own subaccount.

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 (repurchasing tokens) is a later-release V2 feature.