CollectionGalleryClaim

Claim a frog

Buy $UFROG, burn some of it, and the pond hands one of the 189 drawings over. The tokens are destroyed rather than collected, and which frog you get is decided after you have paid, by a block that did not exist when you signed.

Burn 0 $UFROG to commit to a draw, wait one block, and pull a frog out.

Claim not open
0/189claimed

The collection has not been handed to the claim contract yet. Nothing can mint until it is.

Why it is two transactions

The first one burns your $UFROG and writes down your address and the block you are in. Nothing is minted by it. The second one draws the frog, 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 frog 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 frog.

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 frog goes to whoever paid for it, never to the caller.

Which frog 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 frog.

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 frog 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 frog somebody else is already owed.

Why there is no mint hook

The first design put a Uniswap v4 hook on the $UFROG pool so that buying the token was itself the mint. $UFROG launches through pools.trade’s instant launch instead, and that factory takes no pool parameters and no hook address, so there is nowhere to attach one to the launch pool. Of the last twenty-five pools initialized on this chain’s PoolManager, twenty-two were initialized with no hook at all.

The hook contract and its tests are still in the repository, for the crowd-launch route that does accept a third-party hook. It is not deployed and it is not what mints these frogs.

Reference