The collection sub-page where a creator sets the default claim rule every new vendor drawing from this collection starts with (then edits per vendor). It is tier-indexed (a default per rarity tier), auto-saves, and is required-valid before Review — cost only; rules never gate. Being a template, it stays editable in every collection state, including Live (edits are non-retroactive — existing vendors keep their copies). In V1 a rule is two things: a required cost (Free, or an accepted currency) and optional requirements (allowlist / hold / stake). Restrictions (claim limits) and Rewards (payouts) are V2. Source: Design Documentation/collection-defaults-design.md. Refreshed 2026-07-20 for the post-06-30 rulings: cost inheritance (R61 — the gate tests effective resolution), requirements never inherit (R72), full-tier-set gate (R73), sparse vendor snapshot (R74), fail-closed unenforced requirement kinds (R75), and the V1 weighted tier set (3 tiers).
V1 scope: collection defaults carry only cost + requirements. Claim Restrictions (how often / how many — e.g. max per human) and Rewards (extra payout) are V2 — not yet configurable. Source: Design Documentation/collection-defaults-design.md.
Part A
The sale-defaults page
The sub-page itself: a per-tier table of the claim rule (cost + requirements), and the rule editor. Auto-saves; stage persistence lives on the collection bar, not here.
A1Collection defaults — setA collection with collection defaults in place. Each rarity tier has a cost plus optional requirements. This is a collection sub-page, so it auto-saves — no Save/Discard here; stage persistence (Submit to Review / Publish to Live) lives on the collection bar.
The default claim cost & requirements every new vendor drawing from this collection starts with — vendors then edit their own copy. One default per rarity tier.
Draft
Per-tier defaults
tiered rarity · 3 tiers
TierClaim rule
PatronFree · On a whitelist
Keeper2 ICP
Founder4 ICP · On a whitelist
A2Rule editor — collection defaultOpened from "Edit rule" on a tier. A required cost (Free, or an accepted currency) plus optional requirements (whitelist / holds tokens from a collection / has a stake), combined with AND. Whitelist is V1; the token-hold and stake types are front-end V2 (backend schema in V1) — see A2b. Restrictions (claim limits) and Rewards (payouts) are V2 and not shown here. Dev note (2026-07-17): Free and unset are distinct wire states — never coerce an absent value into Free; on the tier update endpoints an omitted tier means unchanged, and clearing a tier back to unset is an explicit operation, never inferred from omission.
Claim rule · Founder
✕
Claim cost required — Free, or an accepted currency
Free
Anyone eligible can claim at no cost.
Priced
An amount in one of Toko's accepted currencies.
Requirements optional · combined with AND · none = anyone can claim
On a whitelist
Only principals on a Live whitelist may claim.
Holds tokens from a collection
Must hold at least a set number of tokens from a chosen collection.
Has a stake
Must have an active NNS / SNS stake.
Requirements narrow who can claim, combined with AND — optional. Changes here never affect existing vendors.
A2bRule editor — token-hold & stake requirements configuredThe same editor with Holds tokens from a collection and Has a stake selected, each revealing its config inline. Token-hold = collection_id (picked by name, id shown) + quantity ≥ 1 — never "holds a token" in copy. Stake = source (NNS or an SNS governance canister) + optional minimum_stake (quantity of the staked token) + optional minimum_dissolve_delay (chosen over neuron age — forward commitment, same measure NNS/SNS use for voting eligibility). Both requirement types are front-end V2; the backend schema ships in V1 (ruled 2026-07-03). Both targets must resolve before Save enables. Requirements AND together — never OR — so this rule reads: on the whitelist AND holds ≥ 3 AND has the stake. A tier may carry two stake gates (one NNS + one SNS), both of which must then be satisfied. Fail-closed (R75, 2026-07-17): any requirement kind not enforced end-to-end — token-hold today — is rejected by backend validation on every live claim path, at save and at claim; a stored schema is never, by itself, permission to enforce.
Claim rule · Founder
✕
Claim cost required — Free, or an accepted currency
Priced
An amount in one of Toko's accepted currencies.
Requirements optional · combined with AND · none = anyone can claim
On a whitelist
Only principals on a Live whitelist may claim.
Holds tokens from a collection
Must hold at least this many tokens from the chosen collection.
Quantity required ≥ 1 · collection col_9f3k2…7a
Has a stake
Must have an active NNS / SNS stake.
Minimum stake and dissolve delay are optional — leave both empty for "any active stake".
Requirements narrow who can claim, combined with AND — optional. Changes here never affect existing vendors.
A4Collection defaults — not set yetA Draft collection before collection defaults are configured. Tiers exist (from the rarity system) but have no cost. The page is editable in any state; the only gate is at go-Live — every tier must resolve to a cost (its own, or one inherited from the tier below; free is allowed — R61) to pass review.
Set a cost for each tier (free is allowed); requirements are optional. Unset tiers inherit the cost from the tier below; every tier must resolve to a cost before the collection can go Live.
Part A note (not UI) — what isn't here
Collection defaults are the per-collection starting point for vendor claim rules — every new vendor drawing from this collection inherits them, then can edit per vendor. The vendor's copy keeps the sparse authored per-tier values (the unset / explicit-Free / amount distinction) plus a revision stamp; tier inheritance is applied at claim by the same shared resolution function, never flattened at copy time (R74, 2026-07-17). In V1 a rule is just cost + requirements. Restrictions (claim limits — e.g. max per human) and Rewards (extra payout on claim) are V2 — not yet configurable. Promo / redemption codes are project-level, not collection defaults.
Part B
Lifecycle
Collection defaults have no lifecycle of their own — the stage badge on the page is the collection's, shown for orientation. They are a template, editable in every state including Live (resolved 2026-07-02); edits are non-retroactive — existing vendors keep their imported copies. The single stage-coupled behavior: to pass review and go Live, every tier must resolve to a cost — its own, or one inherited from the tier below (free counts; R61). Requirements never gate.
B1Draft — unset tier inherits from below (valid)Ruled 2026-07-07 (R61): the go-Live gate tests effective resolution, not storage. An unset tier inherits the nearest set cost from the tier below it, so Founder — with no cost of its own — resolves to Keeper's 2 ICP and the collection IS ready for Review. The row shows the inherited value muted with an "Inherited" tag (informational coverage); the checklist and the claim path share one resolution function, never two. Everything is editable and stays editable; nothing on this page ever locks.
Founder inherits its cost from Keeper (2 ICP). Every tier resolves to a cost, so this collection is ready for Review. Setting a cost on Founder overrides the inherited value.
⚠
Editing Keeper warns before saving: "Founder inherits this cost — changing it also changes 1 inheriting tier." A guardrail, never a gate.
Per-tier defaults
TierClaim rule
PatronFree · On a whitelist
Keeper2 ICP
Founder2 ICP Inherited from Keeper
B1bDraft — blocked (first tier unset)The genuinely blocked state under R61: inheritance flows downward only, so an unset first tier has nothing to inherit from and fails to resolve. Only then does the go-Live check fail; the error copy points at the fix.
Patron has no claim cost and no tier below it to inherit from. Set a cost on Patron (free is allowed) before this collection can go Live.
Per-tier defaults
TierClaim rule
PatronNo cost set ⚠
Keeper2 ICP
Founder2 ICP Inherited
B2Review — valid & still editableEvery tier resolves to a cost — its own, or one inherited from the tier below (R61) — so the collection-defaults check for go-Live passes. Collection defaults stay editable here — and will stay editable at Live too.
All tiers resolve to a cost — this collection can pass review and go Live. Defaults stay editable at every stage; edits never change existing vendors.
Per-tier defaults
TierClaim rule
PatronFree · On a whitelist
Keeper2 ICP
Founder4 ICP · On a whitelist
B3Live — still editable (template)Resolved 2026-07-02: collection defaults do NOT freeze at Live — they're a non-retroactive template. Editing at Live changes only what future vendors inherit; existing vendors keep their imported copies. An info note makes the non-retroactivity explicit.
These are a template — still editable while Live. Changes apply only to vendors created from now on; existing vendors keep the copy they imported.
Per-tier defaults
TierClaim rule
PatronFree · On a whitelist
Keeper2 ICP
Founder4 ICP · On a whitelist
B4Stage gates — referenceWhere collection defaults sit in the collection lifecycle. A plain reference table on grey (not UI).
Stage
Editable?
Gate
Draft
Yes — fully editable
Tiers may be unset
Review
Yes — still editable
Go-Live check: every tier in the collection's rarity-mode tier set resolves to a cost — its own, or one inherited from the tier below (free is allowed); zero-budget tiers included, no carve-out (R61/R73). Requirements optional, never a gate
Live
Yes — still editable
None — edits are non-retroactive; new vendors start from the current defaults, existing vendors keep their imported copies
Part B note (not UI)
Collection defaults have no lifecycle of their own — the stage badge on this page is the collection's, shown for orientation only. Unlike frozen core policy, defaults are a template: editable in every state, including Live, and never retroactive. The single gate is at go-Live: to pass review, every tier in the collection's rarity-mode tier set must resolve to a cost — its own, or one inherited downward from the tier below (free is allowed; zero-budget tiers included, no carve-out — R61/R73). The checklist calls the same resolution function the claim path uses, never a second implementation. Requirements are optional and never gate. The check is surfaced on the collection's status checklist (see collection-states-gallery); this sub-page shows field-level state inline only.
Part C
Rarity modes
Collection defaults are tier-indexed, so the table shape follows the collection's rarity mode — exactly like collection defaults.
Modes
Uniform
No tiers — one default for the whole collection.
Tiered
The collection's own named tiers (Patron / Keeper / Founder).
Weighted
The collection's weighted tier set — Common / Uncommon / Rare in V1 (Epic / Legendary only once unlocked, Phase 3).
C1Uniform — populatedUniform rarity has no tiers — one set of collection defaults for the whole collection. A single rule.
Collection default
uniform rarity
ScopeClaim rule
All tokens2 ICP
C2Tiered — populatedTiered rarity uses the collection's own named tiers. Each tier needs a cost; requirements optional. Cost can escalate per tier.
Per-tier defaults
tiered · 3 tiers
TierClaim rule
PatronFree · On a whitelist
Keeper2 ICP
Founder4 ICP · On a whitelist
C3Weighted — populatedWeighted rarity uses the collection's weighted tier set — in V1 that is Common / Uncommon / Rare for every collection (Epic / Legendary are locked platform-wide until the Phase 3 Mastery unlock; their rows appear only on collections whose project has unlocked them pre-Live). Same model — a cost per tier, with downward inheritance.
Per-tier defaults
weighted · 3 tiers (V1 set)
TierClaim rule
CommonFree · On a whitelist
UncommonFree · On a whitelist
Rare2 ICP
Part C note (not UI)
A tier carries two things: a required cost (Free, or an accepted currency) and optional requirements (on a whitelist / holds tokens from a collection / has a stake — combined with AND; none = anyone can claim). The only go-Live gate is that every tier resolves to a cost — its own, or one inherited from the tier below (R61); requirements are optional. Restrictions (how often / how many — e.g. max per human) and Rewards (extra payout) are V2 — not yet configurable. Source: collection-defaults-design.md.