Be on the list.
The contract owner assigns each wallet an allowance of up to 3 claims. Owning an IMD NFT or paying for a swarm job does not automatically grant eligibility in the code.
Contract: grant / grantEach ↗ A field guide to an Ethereum collectible
Claim first.
Meet Pepe later.
A small guide to the free claim, the waiting, and the artwork that lives on-chain. Start here, even if this is your first NFT.
Explore the revealNo wallet. No signatures. Just learning.
01 / Before the pixels
From eligible to yours.
An NFT is a unique token recorded on a blockchain. “Minting” creates that token; “revealing” makes its final artwork visible.
Free means mint price.
The claim has no mint payment. A real Ethereum transaction still costs gas, paid in ETH. The no-argument claim() takes your entire remaining allocation, not just one.
Wait, then reveal.
A claim records the minter and mint block. The artwork seed uses the next block’s hash—a fingerprint of a block that does not yet exist at mint time.
Contract: _claim / reveal ↗What else can stop a claim?
Minting must be open, the caller cannot be the contract owner, and the request must fit the wallet’s allowance, its lifetime limit of 3, and the collection limit of 5,000. A partial allocation can be claimed through claim(amount). Transferring a Pepe away does not reset the mint count. These are code limits, not a report of current availability. Source: remaining, _claim, MAX_SUPPLY ↗
02 / The reveal lab
You can’t preview
a block that hasn’t happened.
Interactive simulation
If the hash were already known, someone could test inputs and pick a result. Compare that with waiting for a future block.
Switch tokens. The known-hash preview changes; the future result stays unknown.
If the hash were known
Comparison onlyPreview available
You could inspect the outcome before committing.
Known hash
0x51a7c0deWith a future blockhash
Contract patternNo preview yet
A mystery Pepe
The missing input is a block that hasn’t happened.
Future hash
Not created yet- Block 100CommitMinter + token fixed
- Block 101Hash appearsThe target block
- Block 102Reveal can runTarget is in the past
First, commit to an example.
Your choice is locked before the future hash exists.
The order is the point.
You committed first. The missing input arrived later. Resetting creates a separate pretend experiment; a real revealed token cannot be rerolled. Contract: reveal ↗
A model, not a mint. All tokens, hashes and artwork here are invented. This uses a toy mixing function, not the contract’s keccak256 or actual trait probabilities. Nothing is sent to Ethereum. Real token IDs are assigned by the contract, not selected from this menu. Source: _claim / reveal ↗
What the code guarantees
A mint in block B targets B+1 and can first reveal at B+2. The seed combines that hash, the token ID, the original minter and this contract’s address. Anyone can trigger the reveal, and a stored seed stays fixed. Source: reveal ↗
What the demo doesn’t prove
It shows why an ordinary minter cannot preview the final traits at mint time. It does not prove perfect randomness or rule out influence by block producers. The creator’s stronger anti-grinding claim is not a security audit. Solidity’s randomness warning ↗
Will the reveal always happen automatically?
The creator says a bot handles reveals. The contract itself needs a reveal transaction; it cannot schedule one. Anyone may call it, so it is not restricted to the creator or the token owner. A bot’s availability has not been checked here. Creator memo ↗ · Contract: reveal / revealableAt ↗
The contract’s Blockhash helper can use Ethereum’s extended history (up to 8,191 blocks), beyond the native 256-block window. If the fixed target hash is unavailable, the token stays unrevealed; there is no substitute hash or reroll. A timely reveal matters. Source: Blockhash.sol / reveal ↗
03 / No image server needed
The pixels live
with the code.
The token’s tokenURI returns its description and image as embedded data. The image is an SVG: a picture drawn from shapes, rather than fetched from an image server. Contract: tokenURI ↗
A separate on-chain PixelArt contract turns the seed into a 24 × 24 grid of colored rectangles. Skin, eyes, mouth, hat and accessory all come from that seed. Swarm Pepe’s reference to this renderer is fixed at deployment. PixelArt: renderSVG / attributes ↗SwarmPepe: immutable ART ↗
In plain language: the contract contains the recipe for the picture. A marketplace displays that picture; it does not supply the artwork file.
04 / Check the field notes
Facts deserve footnotes.
Code describes the rules. A creator’s memo describes intentions. This guide keeps the two separate.
01SwarmPepe verified sourceAllowance, claim, supply limits, seed and reveal · EtherscanContract code02PixelArt verified sourceThe renderer referenced by the constructor · EtherscanContract code03The creator’s launch memoSelection policy, reveal bot and anti-grinding claims · 25 Sep 2026Creator statement04Ethereum’s blockhash historyThe extended history used by the contract’s Blockhash helperTechnical context
“Verified source” means Etherscan has matched published code to deployed bytecode. It does not mean independently audited. This is a source-based guide, not a live eligibility, supply or bot-status checker. About source verification ↗