Contracts
Seven contracts, one pool
Responsibilities are split so that a change to rewards or randomness does not require migrating a contract that holds other people's NFTs.
| Contract | Responsibility | Status |
|---|---|---|
| Tuck | Core pool — positions, weighting, pricing, selection, settlement | Implemented |
| TuckWhitelist | Collection curation with sticky blocking | Implemented |
| TuckRandomness | Router with swappable beacon adapters; drand adapter first | Implemented |
| TuckTreasury | Protocol revenue, segregated from operator capital | Implemented |
| TuckRewards | Crown, on-chain points accrual, epoch accounting | Planned |
| TuckClaim | Merkle distribution of the Phase 1 retroactive allocation | Implemented |
| Tuckers | The TUCKERS collection — mint, rarity tiers, fee weight | Implemented |
Why the split matters
Phase 1 pays no token, but the settlement path still calls a reward distributor with a null implementation behind it. Hardcoding “no reward” instead would turn Phase 3 into a contract migration while the pool holds other people’s NFTs.
The treasury separates third-party revenue from operator capital for the same reason: Phase 2 triggers have to be computed from third-party revenue only, and that is not recoverable after the fact if both were pooled.
Tiers are committed, not announced
Tuckers takes a hash of the tier list in its constructor and only accepts the list itself after the mint has closed. Publishing the list up front would let minters watch the queue and buy the token ids that land on Legendary; publishing only its hash removes that edge while still proving the tiers were not reassigned once the art was seen.
On reveal the contract checks the commitment and recounts the distribution — 1,400 / 400 / 150 / 40 / 10, summing to a total fee weight of 3,600. A list with nine Legendaries instead of ten is rejected on-chain, because every published fee-share figure divides by that total.
Curation, in detail
TuckWhitelist was the first contract implemented. Allowing a collection is reversible; blocking it is not. An owner key that could quietly un-block a collection is a strictly worse trust assumption than one that cannot, so revoking is the reversible action and blocking is permanent.
Allowing also rejects anything that does not advertise ERC-721 through ERC-165, so a typo in a curated list fails loudly instead of sitting there as a dead entry. Blocking deliberately skips that check — a collection that has turned hostile may well have stopped answering introspection, and the owner must still be able to bar it.