$SLOPwhitepaper.

Slonk

An NFT in the Slonks collection.

Source CryptoPunk

The original CryptoPunk image assigned to a Slonk. Each Slonk has one source CryptoPunk.

Slonks model

The on-chain image model trained to reconstruct CryptoPunk images. The model renders the Slonk image.

Generated image

The image produced by the Slonks model for a Slonk.

Original image

The source CryptoPunk image used as the comparison target.

Slop

The number of pixels where the generated image differs from the original. A Slonk image has 576 pixels, so a Slonk has between 0 and 576 slop.

$SLOP

The ERC-20 form of slop. When a Slonk is voided, its slop becomes newly minted $SLOP.

Void

The contract state where Slonks are held after being converted into $SLOP. The void is not a burn address — it is a reservoir of voided Slonks that can return through revival.

Revival

Burning $SLOP to draw a Slonk back out of the void.

Merge

The existing Slonks mechanic where one Slonk consumes another to create a new visual state. Merging is separate from $SLOP minting.

Embedding

A small numeric representation used by the Slonks model to render an image. Revival gives a Slonk a new active embedding.

Max supply:               5,760,000 $SLOP
Launch inventory:           576,000 $SLOP
Future emission capacity: 5,184,000 $SLOP

The launch inventory starts the market. The remaining supply is emission capacity that can only be minted by Slonks entering the void. All $SLOP amounts in this document are whole-token amounts — with 18 ERC-20 decimals, 100 $SLOP is 100e18 base units onchain.

• ▸576,000 $SLOP minted into the launch pool / launch manager
• ▸buyers bring the ETH side through public buys
• ▸launch configuration is fixed before the pool opens

slopMinted   = currentSlop
mintAmount   = slopMinted

maxSlopMinted = 576 $SLOP   // 24 × 24 pixels

• ▸the Slonk leaves active circulation
• ▸the Slonk is held by the void / game contract
• ▸the holder receives newly minted $SLOP
• ▸the amount minted equals the Slonk's current slop
• ▸the Slonk cannot be transferred or merged while in the void

voidSlonk(tokenId) reverts when slopMinted > maxSupply - totalSupply. Each call is checked independently — there is no separate global closed flag. A voided Slonk stays in the void until a revival request draws it back out.

sourceId         = Slonks.sourceIdFor(tokenId)
generatedPixels  = imageModel.renderSourcePixels(sourceId)
originalPixels   = CryptoPunksData.punkImage(sourceId)
currentSlop      = countSlopPixels(generatedPixels, originalPixels)

For a merged or revived Slonk, the contract uses the token's current active embedding to calculate the generated pixels before computing slop.

• ▸user burns the current revival cost
• ▸a Slonk is drawn from the request's eligible void pool by delayed blockhash randomness
• ▸the Slonk receives a new active embedding
• ▸merge level resets to 0
• ▸the Slonk returns to active circulation
• ▸tokenId and sourceId stay the same — historical provenance is preserved

Positive $SLOP outcomes are valid — a revived Slonk can later be voided again for more $SLOP than the revival cost paid, when its new embedding produces enough slop. The revival distribution is weighted toward the source embedding, so the average revival produces less slop than the $SLOP burned to create it. Super-rare revivals can come back with 400+ slop.

dutchStartPrice  = 576 $SLOP
elapsedBlocks    = block.number - lastRevivalRequestBlock
priceDrop        = floor(elapsedBlocks / revivalDropIntervalBlocks)
dutchPrice       = dutchStartPrice - min(priceDrop, dutchStartPrice - minRevivalCost)
revivalCost      = max(minRevivalCost, dutchPrice)

Each paid revival request resets lastRevivalRequestBlock to the current block, snapping the price back to 576 $SLOP. Revival opens for the first time when the void contains at least 100 Slonks; that block becomes the initial lastRevivalRequestBlock.

requestRevival(maxCost)
  → settle the previous pending request
  → require: void contains ≥ 100 Slonks
  → revivalCost := current price
  → revert if revivalCost > maxCost
  → burn revivalCost from caller
  → store requester, revivalNonce++, eligibleSlonkCount
  → store targetBlock  = block.number + 32
  → store expiresBlock = targetBlock + 255

finalizeRevival()
  → opens after targetBlock, closes after expiresBlock
  → uses target blockhash to pick: void index, embedding bucket, random embedding
  → transfers the revived Slonk to the requester

• ▸the request's eligible void pool is fixed at request time — Slonks voided after the request are not eligible for it
• ▸users do not choose which Slonk they revive — a revival request buys a random draw from the eligible pool
• ▸only one pending request at a time — a new requestRevival first resolves the previous (finalize, clear-if-expired, or revert if not yet at target)
• ▸finalization is permissionless — anyone can call finalizeRevival(), but the Slonk always goes to the stored requester
• ▸revival cost is paid at request time — later price changes do not affect existing requests
• ▸expired requests can be cleared by anyone after expiresBlock; the burned $SLOP stays burned

randomEmbedding  = random 10-byte int8 embedding
blendBucket      = weighted random choice
newEmbedding     = blend(sourceEmbedding, randomEmbedding,
                         sourceWeight, randomWeight)

Most revived Slonks come back close to their source. Rare revived Slonks come back stranger, more random, or visually valuable.

buyAndVoidSlonk(tokenId, target, value, data)
  → calls marketplace target with value
  → only succeeds if marketplace returns ok AND
    game contract receives tokenId
  → tokenId is added to the void
  → mints 0 $SLOP   // protocol-bought Slonks do NOT increase $SLOP supply

The Uniswap v4 hook is the pool-facing fee collector. The void / game contract is the canonical Slonk inventory and revival contract. Marketplace purchases are not executed inside the swap hook — the hook only collects and routes fees, and a separate authorized protocol buyer executes the market call.

Merge history remains available through onchain events and current merge state. Revival creates a new active image state for the same Slonk without erasing its identity.

The Slonks NFT contract remains responsible for NFT existence, ownership, transfers, and renderer delegation.