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 — since R81 (2026-07-22) — is fully optional: nothing here ever gates the collection; the resolve-to-a-cost gate now sits on each vendor's Review/Live ("Reviewed, stocked and priced"). 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 — though several selected whitelists merge into one de-duplicated eligible list (on any one passes). Whitelist and the two stake gates are V1 (stake gates ratified 2026-07-22); token-hold is 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). The stake gates are V1 (ratified 2026-07-22 — authorable and enforced; one NNS + one SNS max, SNS editor capped at one row); token-hold remains front-end V2, backend schema in V1, fail-closed. 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 (and "on the whitelist" itself means on any one of the selected lists — several lists merge into a single de-duplicated eligible list). 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". Max claims per neuron defaults to 1, counted per vendor whichever hotkeyed address claims.
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, and since R81 (2026-07-22) an unset page is a perfectly valid one — the collection can go Live regardless. The checklist shows cost coverage informationally; the resolve-to-a-cost gate (R61 inheritance; free allowed) is applied per vendor at the vendor's Review/Live.
Set a cost for each tier (free is allowed); requirements are optional. Unset tiers inherit the cost from the tier below. Entirely optional (R81) — the collection can go Live regardless; each vendor prices its own copy before it goes 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. Since R81 (2026-07-22) there is no stage-coupled behaviour left at the collection: cost coverage is informational only, and the resolve-to-a-cost check (own cost or inherited from the tier below; free counts; R61) runs at each vendor's Review/Live instead. Requirements never gate anything.
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; a vendor copying these defaults starts fully priced. 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 — first tier unset (incomplete coverage, not a blocker)Inheritance flows downward only, so an unset first tier has nothing to inherit from and fails to resolve. Since R81 this no longer blocks the collection — the checklist reports the coverage gap informationally, and the failure surfaces as a vendor Review/Live blocker if a vendor tries to go Live with the tier still unresolved on its copy.
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 — full coverage & still editableEvery tier resolves to a cost — its own, or one inherited from the tier below (R61) — so the informational coverage line reads complete (it never gates the collection; R81). Collection defaults stay editable here — and will stay editable at Live too.
All tiers resolve to a cost — every vendor created from this collection starts fully priced (coverage is informational; it never gates the collection — R81). 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; several selected whitelists merge into one de-duplicated eligible list — on any one passes). 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.