Claim a crab
Buy $CLAW, burn 300,000 of it, and the shuffle hands one of the 1,111 crabs over. The tokens are destroyed rather than collected, and which crab you get is decided after you have paid, by a block that did not exist when you signed.
The collection contract is not wired into this build yet.
Why it is two transactions
The first one burns your $CLAW and writes down your address and the block you are in. Nothing is minted by it. The second one draws the crab, using the hash of the block after your commit as the entropy.
That hash does not exist while you are signing the first transaction, which is the whole point. If the draw were decided inside the transaction that pays, anybody could run it through a contract, look at the crab that came out, and revert the call when it was a common one. Splitting it takes that away from everyone, us included.
The claim contract also picks the seed it hands the collection so that the position drawn out of the shuffle is a function of your committed blockhash and nothing else. Revealing later, or from a contract that inspects the result and aborts, produces the same crab.
How long you have
Robinhood Chain produces a block roughly every hundred milliseconds, but the number a contract reads from block.number is the Ethereum block number, which moves about once every eleven and a half seconds. This was measured against a mainnet node rather than assumed, and the blockhash history is exactly 256 of those blocks deep.
So the wait between the burn and the draw is about twenty-three seconds, and the window to draw stays open for 240 blocks, which is about forty-five minutes.
If the window closes with nobody having drawn, the claim is not lost and it is not charged twice. Re-anchoring moves the commitment to the current block for the price of gas. Anyone can also draw or re-anchor somebody else’s commitment; the crab goes to whoever paid for it, never to the caller.
Which crab you get
Token ids come out of a lazy Fisher-Yates shuffle held in the collection contract. The draw indexes into whatever ids are still unclaimed, the drawn id is swapped out of the live range, and the range shrinks by one. No id can come out twice and the draw stays uniform over the remainder all the way down to the last crab.
The metadata is published in full before the first claim, so which id is rare was settled before anyone could act on it. What is random is which id you receive. The keccak of every image hash, in id order, goes into the contract as a provenance hash before the token launches, so the published art can be checked against what was committed.
A crab is held in reserve for every commitment that has been paid for and not yet drawn, so the last few claims cannot be sold a crab somebody else is already owed.
Why the mint is not attached to the market
An earlier design in this family put a Uniswap v4 hook on the token’s pool so that buying was itself the mint. That is not available here: $CLAW launches on Pons V2, which is a bonding curve rather than a pool. The token trades against a virtual reserve from its first block and only graduates into a real Uniswap V3 pool once the threshold is taken, so for most of the mint there is no pool to hook.
Decoupling it turns out to be the better answer anyway. The claim reads nothing from the market, so it behaves identically before graduation, after graduation, and on a day the curve is not moving at all. And burning is a stronger claim than routing fees: the tokens are not taken somewhere, they stop existing.