Two thousand turtles with a claim on revenue

The distribution is exact, not approximate

Most generative collections assign rarity by probability weight, which lands near the intended distribution rather than on it. That is fine where rarity is cosmetic. Here it is not: fee weight sums to 3,600 units, and every published payout figure divides by that total. Nine Legendaries instead of ten and every one of those figures is wrong.

The counts are built into the list before it is shuffled, so exactness comes free. revealTiers then recounts all five on-chain and rejects a list whose counts do not match — a list that hashes correctly but is miscounted cannot be accepted either.

Why the seed is a block nobody had seen

Whoever runs a shuffle picks its seed. Pick a different seed, get a different shuffle; run it ten thousand times and keep the one where the Legendaries land on wallets you control. From outside, the result looks identical either way.

So the choice is removed. The seed is the block hash of a Robinhood Chain block whose height was announced publicly before that block existed. Rigging the shuffle would mean predicting a future block hash.

Note what cannot be reordered: the commitment is derived from the seed, so it cannot be published first. Announcing the height is the step that binds. The commitment stored in the constructor defends a different attack — it stops the tier list being swapped after minters have seen the art.

Verifying it yourself

At reveal the seed and the full tier list are published. One command regenerates the shuffle and reports whether it matches:

tier-prepass.py --seed 0x<block hash> --out build --verify

The method is written out rather than pointed at — SHA-256 in counter mode, rejection sampling instead of a modulus, Fisher–Yates from the end — so it can be reimplemented in any language. A modulus would bias the low values, and across 2,000 draws that is enough to skew where ten Legendaries land.

The final hash is keccak256, not SHA3-256. The two differ in padding, and a verifier reaching for a language’s built-in SHA3 will get a different answer and conclude, wrongly, that something is off.

What the fee share is, and is not

Share is paid only out of revenue the protocol actually collects. No acquisitions means no revenue and no share. Rarity governs fee weight — not value, and not a guaranteed payout.

An instrument that pays holders a share of a business’s revenue may be treated as a security in your jurisdiction. No determination has been made and no legal opinion obtained. The terms state this plainly, and it is worth reading before acquiring one.

The art

Each token is composed from layered traits at 32×32 — background, head, eyes, mouth and neck — over one locked base. Trait weights differ per tier, so a Legendary draws from a different distribution than a Common; without that the tier would be invisible in the artwork and holders would read fee weight as the only real difference.

Composition is deterministic from the same published seed, by domain separation rather than a second seed. Anyone holding it can regenerate all 2,000 images byte for byte.

Where the art is stored, and the risk in that

Images and metadata live on IPFS, pinned by a single service. IPFS stores nothing on its own — a CID is an address, and content exists only while some node keeps it. If that service goes away, every tokenURI stops resolving: the tokens remain on-chain and point at nothing.

What makes that survivable is the determinism above. Anyone can regenerate all 4,000 files from the published seed and re-pin them to the identical CID, with nobody’s permission. The exposure is an outage until someone restores it, not a permanent loss — but it is a weaker guarantee than pinning twice, and it is stated here rather than left for you to discover.