Transparency

Why the supply is 794, not 1,000

The collection was planned at 1,000. Each of those 1,000 planned pogs got a full set of traits — series, subject, finish, palette, rim, era, grade — dealt out in advance. Then the art had to be generated, one image at a time, and the budget for generating images ran out after 794.

That left a choice, and it is the first thing worth being transparent about, because the three obvious options are not equally honest:

1. Mint 1,000 anyway and fill the last 206 with placeholders or recycled art. Rejected: 206 people would own a receipt for a picture that was never drawn.
2. Mint 794 now and promise the other 206 later. Rejected: it makes the supply an open number that the owner can extend whenever he likes, which is the same as having no cap.
3. Set the cap to what exists. Chosen. MAX_SUPPLY = 794 is a constant in the contract with no setter, so the collection can never grow.

Setting the cap to the real number had consequences that were accepted deliberately:

• The 794 surviving pogs were renumbered 1…794 with no gaps, in ascending order of their original plan id. Each one keeps its original id in a src field, so any token can be traced back to the artwork that produced it.
• Rarity was recomputed against the real counts. A trait's rarity is how often it occurs in the 794 pogs that exist, not in the 1,000 that were planned. Quoting planned rarity for a collection this size would overstate how rare some traits are.
• The provenance hash was taken over the final 794 and nothing else. This is what makes the decision permanent: adding a pog later would renumber the collection and change that hash, and the hash is stored on the contract. It cannot be done quietly.

The rounder number was available and was not taken. "1,000 pogs" reads better than "794 pogs". 794 is the number that is true.

The price ladder

A pog's mint price depends only on its tier. There is no dynamic pricing, no bonding curve and no discount for buying in bulk — a Common is $7.50 whether you buy one or twenty.

The spread from bottom to top is deliberately narrow: $7.50 to $12.50, a difference of $5.00. A Legendary is about 87 times scarcer than a Common, but it costs only 67% more. Rarity is meant to show up in what a pog is worth later, not in a wall at the front door.

If every one of those 793 pogs sold at its ladder price, the collection would raise $6,298.75, plus whatever the Mythic fetches. That figure matters later: it is the anchor for what the Mythic is worth.

The token

POGS is an ERC-20 token with 18 decimals. The entire supply — 1,000,000,000 POGS — is created in a single transaction when the contract is deployed, and the contract has no mint function afterwards. Not an owner-only one, not a capped one, not a paused one. There is no code path in the token that can ever bring the total to 1,000,000,001.

The 80/20 split is fixed in the constructor and asserted there: a deploy whose airdrop and treasury do not sum to exactly 1,000,000,000 reverts, so a mis-configured token cannot exist on chain at all.

On burning

There is no burn function anywhere in this project, and no address in any contract, script or config that exists to receive tokens and never give them back. Sending a million POGS to 0x…dEaD and posting the transaction would make the remaining supply look scarcer without anyone being better off; it is a number moved from one column to another and photographed.

So wherever supply would otherwise be left over, it is given away instead:

• Rounding leftovers from the airdrop division go to the lowest token ids — the dust rule, below.
• If the Mythic's 80,000,000 POGS are forfeited, they go to the other 793 holders — the rollover rule, below.

One exception, stated because it is real: the rollover's own rounding remainder — a fraction of a single POGS, in wei — stays in the distributor contract permanently, because the alternative (rounding up) could pay out more than the 80,000,000 it is redistributing. There is no sweep function to retrieve it, so those wei are genuinely stuck. They are not burned; nobody claimed they were.

How the 800,000,000 POGS are split

Two rules, applied in this order.

Rule 1 — the Mythic gets a fixed 10%

RHPOG #1, the only Mythic in the collection, receives 80,000,000 POGS. That is 10% of the airdrop, set as a flat number rather than earned through the weight system, because a single pog holding a tenth of a community allocation is a decision that should be visible rather than something that falls out of a weight table. (Read the rollover rule below before deciding what that means: this allocation can be given up.)

Rule 2 — the other 793 share the rest by weight

That leaves 720,000,000 POGS for 793 pogs. It is divided using weights, which work like shares: a Common is worth 1 share, an Uncommon 1.6 shares, and so on up to a Legendary at 8. Add up everybody's shares, divide the pool by the total, and you get the value of one share.

720,000,000 ÷ 1,037.2 = 694,176.62938681064404165 POGS per weight unit

That is the exact figure, floored to the wei — it is where every "POGS each" number in the table comes from. Elsewhere on this page POGS amounts are rounded to two decimals so they can be read; the exact wei for every token id is in data/airdrop.json.

Every "POGS each" figure in the table is that number multiplied by the tier's weight, and nothing else enters the calculation — a Legendary gets eight times what a Common gets because its weight is eight.

Precisely, it gets eight times a Common's share plus 4 wei. Each tier's share is floored on its own, and flooring a larger number throws away a slightly smaller fraction of a wei. That is the whole of the discrepancy, it is in the eighteenth decimal place, and it is mentioned because "exactly eight times" would have been the easier sentence to write and would not have been true.

The dust rule

Dividing 720,000,000 POGS by 1,037.2 does not come out even. Each pog's share is rounded down to a whole wei, which leaves 515 wei unallocated. A wei is a billionth of a billionth of a POGS, so that is a vanishing quantity — and it is still not zero. Rather than leave it stranded, it is handed out one wei at a time to the 515 lowest token ids: ids 2 through 516. (Token id 1 is the Mythic, which is not part of this division.)

That rule was chosen because it needs no list, no snapshot and no merkle proof: a pog gets a dust wei if and only if its id is 516 or lower, which anybody can check by looking at the number on the pog.

The proof

Those two lines sum to the airdrop exactly, with nothing left over and nothing overdrawn. The check is not a claim in a document — build_airdrop.py refuses to write its output file at all unless the 793 individual allocations sum to precisely 720,000,000, and the Solidity test suite then checks the deployed contract against that file, id by id.

The three tranches

The airdrop is not paid all at once. It arrives in three instalments — tranches — that get bigger as they go: a fifth, then three tenths, then half. The clock starts at a moment called T, defined in the next section.

Nothing expires. A tranche unlocks and then stays unlocked; if you claim nothing for a year, all three are still there waiting. Claims are keyed to the token id, not to a wallet snapshot, so a pog sold halfway through the schedule carries its unclaimed tranches to whoever holds it — and selling a pog cannot re-open a tranche that was already claimed on it.

Small honesty note on the arithmetic. 20% of one pog's allocation is not a whole number of wei, so each tranche is computed as a cumulative percentage and then subtracted, which parks each pog's rounding remainder in tranche 3. Measured across all 794 pogs, that makes tranche 1 pay 119 wei less than the nominal 160,000,000, tranche 2 pay 131 wei less, and tranche 3 pay 250 wei more. Those are wei, not POGS: the three together come to exactly 800,000,000, and there is no per-tranche pot that could be overdrawn. The binding guarantee is the grand total, not the headline of any one tranche.

What starts the clock

T is the moment the last RHPog leaves the mint wallet. Not a date the owner picks, not a launch announcement — the mint wallet's balance hitting zero.

Anyone may start the clock. arm() is permissionless: any address can call it, it costs one transaction, and it does the same thing no matter who calls it. It cannot be called early, because it checks all three of these and reverts if any is false:

• totalSupply() == 794 — every pog has been minted.
• balanceOf(mint wallet) == 0 — none of them are still sitting with the project.
• the distributor is holding the full 800,000,000 POGS it is going to pay out.

It also refuses to run twice, so T can be set once and never moved. The timestamp it records is emitted in an Armed event, which means the start of the schedule is a public fact on chain rather than something you have to ask us about.

The reason the trigger is "the pogs are gone" rather than "the pogs are sold" is that they are the same event and only one of them is visible to a contract. A balance is checkable by anybody; a sale is a story.

The Mythic Dutch auction

RHPOG #1 is not sold at a ladder price. It is sold by Dutch auction, which works the opposite way round to the auction you are probably picturing: the price starts high and falls on a fixed clock. There are no bids and no bidding war. The first person willing to pay the price currently on the board buys it, immediately, and the auction ends.

The schedule is $1,000.00 down to $12.50 over 14 days, falling in a straight line — about $70.53 a day, and in practice smoothly rather than in daily steps, because the price is recomputed from the block timestamp every time anybody looks at it. When the 14 days are up the price stops at $12.50 and stays there. It never expires.

What it is actually worth

Here is the part that would normally be left out. The Mythic's 80,000,000 POGS can be valued directly off the ladder, because the ladder already says what everybody else is paying per POGS.

1. The 793 laddered pogs, if they all sell, raise $6,298.75 between them.
2. Those same 793 pogs receive 720,000,000 POGS between them.
3. So the primary market is paying $0.0000087 per POGS — $6,298.75 ÷ 720,000,000.
4. The Mythic's grant is 80,000,000 POGS, which is exactly 1/9 of 720,000,000. So on the same arithmetic it is worth 1/9 of $6,298.75: $699.86.

That is a point estimate, and two of its inputs are judgement calls rather than arithmetic: how much of a pog's ladder price is really buying the artwork rather than the token, and what being the collection's only one-of-one is worth on its own. Rather than claim a precision that is not there, the published estimate is a band — $680.00 to $730.00, which is 2.84% below and 4.31% above the calculated $699.86.

Now put that band on the schedule above:

One caveat, stated once and then dropped: this whole calculation assumes the only anchor for what a POGS is worth is what people paid for the pogs on the ladder. POGS has no market price, no exchange listing and no promised liquidity. The figure is a floor derived from primary sales, not a prediction of anything.

The Mythic rollover rule

What each pog gets if it happens

Those bonus columns assume the roll is thrown before any tranche has unlocked, which is the intended sequence. A roll thrown later can only affect tranches that are still locked — see the limitation below.

How it is enforced

A promise in a blog post is a promise somebody has to keep. This one is enforced by the bytecode:

• One-way. There is no un-roll function, no owner reversal and no admin key that can restore the Mythic's claim. Once thrown, it is thrown.
• Publicly visible. Throwing it emits a MythicRolledToCommunity event carrying the exact number of POGS forfeited, and mythicRolled is a public flag anybody can read.
• It cannot be pointed at somebody else. The function reverts unless the owner personally holds RHPOG #1 at the moment of the call. Without that check, the "fairness feature" would be a confiscation key: an owner could delete an 80,000,000 POGS entitlement belonging to a stranger who paid the top of the auction, and redistribute it across 793 pogs of which the owner may hold any number. The only entitlement the owner can destroy is one the owner bought.
• The public view stops lying immediately. After a roll, allocationOf(1) returns 0 rather than 80,000,000 — because that view is the number a marketplace shows to somebody pricing RHPOG #1 on the secondary market.
• It can never pay out more than it took. Each pog's bonus is rounded down, so the redistribution hands out all but 1,399 wei of the 80,000,000 — a difference that lives in the eighteenth decimal place, and a shortfall on purpose. Erring towards paying slightly less is the only safe direction for a fixed pool: erring the other way would eventually try to pay out POGS the contract does not hold, and the last holders to claim would find an empty contract.

The five headliner auctions

Five pogs — one from each laddered tier — are also sold by Dutch auction instead of at a fixed price. Each starts at $200.00 and falls to its own tier's ladder price over 7 days.

These are a shop window, and the design says so: the point is to have five pogs whose price is visibly moving so the collection has something happening on its front page during the first week. If nobody buys one early, it ends up at exactly the price it would have had anyway.

When a headliner reaches its floor it stops being highlighted — it drops out of the featured row on the front end — but it stays on sale at the floor price. It does not expire and the seller does not have to relist it. The contract exposes whether an auction is still inside its highlight window as a public view, so the front page cannot quietly keep advertising something as "falling" after it has stopped falling.

What the owner can and cannot do

"Decentralised" is a word, so here is the list instead. These are real admin powers and they are worth knowing about before you buy anything.

Every "cannot" in that list is a test in the suite, not a policy. The distributor one is worth spelling out: an earlier version of that test looked like it proved there was no withdraw function, and did not — it passed unchanged against a contract that had one. It now scans the deployed runtime bytecode for the function selector, and checks it can find two functions that are there first, so that a broken scanner cannot report "no escape hatches" by failing to see anything at all.

Check it yourself

Three checks. The first two need nothing but the public repository and a Python that is already on your machine; the third needs a block explorer. What you cannot yet do on your own is listed at the end, because a verification section that only lists the checks that pass is not a verification section.

1. The airdrop arithmetic, from the published file

data/airdrop.json in the repository carries the exact wei allocation for all 794 token ids. This script re-derives every one of them from the weights and the pool size, and fails loudly if any one of them disagrees. It needs no network, no wallet and no dependencies — run it from the root of the repository:

import json
d = json.load(open('data/airdrop.json'))
a = d['allocations']
W = {'Common': 10, 'Uncommon': 16, 'Rare': 26, 'Epic': 45, 'Legendary': 80}
POOL, ONE = 720_000_000, 10**18

assert len(a) == 794                       # one row per pog
assert sum(int(r['alloc']) for r in a) == 800_000_000 * ONE  # the whole airdrop
assert int(a[0]['alloc']) == 80_000_000 * ONE                # RHPOG #1, fixed

for r in a[1:]:                          # every other pog: weight, then dust
    assert int(r['alloc']) - POOL * ONE * W[r['tier']] // 10372 in (0, 1)
    assert sum(int(x) for x in r['tranches']) == int(r['alloc'])

print('checks passed:', d['collection']['provenance'])

If any figure on this page had been typed in by hand rather than derived, this is the script that would disagree with it. It checks the three claims that matter: that the 794 allocations sum to exactly 800,000,000 POGS, that each pog's allocation is its tier weight's share of the pool (plus at most the one wei of dust), and that each pog's three tranches re-sum to its allocation.

2. The same numbers, regenerated from scratch

python3 tools/build_airdrop.py

This is the program that wrote the file above. It prints every table in the allocation section of this page — per-tier allocations, tranche totals, rollover bonuses, the dust — and it refuses to write any output at all if the collection is not 794 pogs with the expected tier counts, or if the allocations do not sum exactly. Every POGS and dollar figure on this page is generated from that same code at build time, which is why the page cannot quietly drift away from the contracts. (It needs the struck collection record, so it runs on the build host; see the limitation below.)

3. The provenance hash, against the chain

A SHA-256 hash is a 64-character fingerprint of a piece of data: change any part of the data and the fingerprint changes completely. This one fingerprints the complete trait record of all 794 struck pogs — for every token id, its series, subject, finish, palette, rim, era and grade, plus the source id it was renumbered from.

The recipe is published so it can be reproduced exactly rather than taken on trust. Take the list of all 794 pog records, drop the art_direction field from each (it is the prompt the art was drawn from, not a trait), serialise the list as JSON with sort_keys=True and separators (",", ":") — no spaces — and SHA-256 the UTF-8 bytes. In Python that is one line:

hashlib.sha256(json.dumps([{k: v for k, v in p.items() if k != 'art_direction'}
    for p in pogs], sort_keys=True, separators=(',', ':')).encode()).hexdigest()

The hash was computed before minting opened and is stored on the NFT contract as PROVENANCE — an immutable value written at deploy with no setter. Read it in the block explorer (a public read, no wallet needed) and compare it to the string above, character for character. Its whole job is to make it impossible for anyone, us included, to change which traits belong to which token id after seeing who bought what.

What you cannot check yet, and why

Recomputing that hash from the art means having the 794 trait records, and those come out of the image build directory, which is not in the public repository. So today you can confirm that the hash on this site matches the hash on the contract, and that neither has moved — but you cannot yet independently re-derive it from the collection. Publishing the collection record as a downloadable file would close that gap, and until it is published this paragraph is here so nobody mistakes the gap for a proof.

The contracts

cd contracts && forge test

The suite checks the deployed contract's allocation for every one of the 794 token ids against the JSON file above, and covers the adversarial cases as well as the happy ones: arming early, arming twice, rolling a Mythic somebody else bought, claiming a tranche twice, underpaying an auction by one wei, and buying an auction long after it reached its floor.