Paste the ADMIN_KEY value from your Railway variables. It is checked once and never stored: this tab gets an admin pass for 8 hours, and closing the tab ends it.

Every tracked community's transactions are read once, oldest first, from one daily allowance of chain calls shared by all of them. The last 30 days of every token are read first, so 24H / 7D / 30D figures do not wait for the whole history. The allowance rises above its fixed base to whatever the plan has spare once the reserve and the rest of the site are paid for (measured, not assumed). To finish one community first, press Read first on its row: it gets the whole allowance until it is read to the present, then the next one you queued, then the regular rules come back on their own.

What HODLComp needs after the catch-up, worked out from what it measures: Blockfrost from a whole day of every job except the one-time history jobs, plus what keeping every community current costs; the volume from each community's bytes per transaction times its exact transaction count, a year of new transactions, and the write log Postgres keeps on the same volume.

An exchange, bridge, lending or staking contract holds tokens for many people, so it is not a community member. Paste its address or stake key — from the exchange's own published addresses or the explorer's label — and it is left out of every community's holders, Conviction Board and Community Health at once. Never guess: only mark a wallet whose owner is known.

Anyone can make a free key on the API page with their wallet. Here you move a key to a paid plan once they have paid, issue one yourself, or turn one off. The key's owner wallet sets its $HODL discount, shown on each row.

In dollars, every price, high and percentage is worked at the ADA/USD rate of its own day. The server reads the last 365 days from CoinGecko, and the days before that from Coinbase’s public daily ADA-USD prices, back to the oldest community’s mint — both by itself. Optional: to use CoinGecko’s own rates for those older days too, open Cardano → Historical Data on CoinGecko, export it as CSV, and choose the file here. Rates for the same day take the file’s value; nothing else changes.

Reading the rates on record…

Loads live competitions so you can pick one, then writes an exact price (in ADA) into its start or end snapshot. Use this to correct a wrong Price at Start.

Each community's finished history — older than 33 days, fully read and priced — is packed into a daily archive, and every wallet's totals are carried forward. Every page reads the archive and the recent rows together, so no figure changes. Nothing is deleted until you trim, and a community can only be trimmed once its fold has been proven against its rows, wallet by wallet and day by day.

Before Postgres saves a change it writes it to a log, on the same volume as your data. Most of the time that log is small. During heavy work — a history backfill, a trim, a Reclaim — it grows until it reaches its ceiling, then reuses its own space. Out of the box the ceiling is 1 GB. On a 1 GB volume that is 1 GB, the whole volume, so one heavy burst could fill the disk and stop the database — cap it at 256 MB. On a larger volume 1 GB is a small slice and either setting is safe. The ceiling does not change how fast history is read — the walk’s request pace does. It deletes nothing and changes no data.

Every pledge recorded against the competition picked in step 2, and what each one is doing to the prize pools. Why you may need this: until recently the donate form only offered ADA, $HODL, $BLUE and $SNEK — so a pledge of any other native asset was saved as ADA with the token's quantity as its amount. A row like that adds ₳1,500,000 to a ₳500 pool. Fix it here: set the real asset by pasting its Policy ID, and say which pool it funds.

Three panels used to live here — a before-the-event pre-flight, an after-the-event audit, and a per-wallet trace — because attribution had four mechanisms and each needed its own explanation. There is one mechanism now: a verified Hizz trade order carrying partner_code = hodlcomp. So there is one panel.
It lists every Hizz order for the competition picked in step 2 and gives each a verdict: credited, or the exact condition it failed — wrong partner, wrong token, wrong competition, not yet verified, outside the window, or no participant it could be matched to. Provider and route are shown but never used: a router can change venue between trades, which is precisely why identifying widget buys by their venue never worked.
Callbacks with no order behind them are listed separately. A few are normal — Hizz needs a moment to verify. A growing list means our partner attribution is not reaching the trade order, and step 6 is where to check that.

The single question the whole multiplier rests on, and the one that cannot be answered by reading our own code. We pass partner: "hodlcomp" in the widget’s mount options — but the iframe URL is built by Hizz’s loader, and the trade order carries what is in that URL, not what is in our object. If partner=hodlcomp never reaches the iframe, Hizz stores no attribution and no buy can ever qualify, however correct everything downstream is.
So every Live Competition page reads back the iframe it actually rendered and reports the URL. Open a competition page in any browser once, then press Check. Until a page has been opened, this can only state what we intend to send.

The multiplier depends on Hizz’s widget telling us which transaction it made. Whether it does is the one thing that cannot be answered by reading our code — and a browser console cannot answer it either if the buy happened on a phone and the console is open on a laptop: those are two different JavaScript contexts, and a log written in one is invisible in the other.
So every browser reports the callback to the server. Make one small buy through the widget from any device, then press Check — the answer lands here either way. Diagnostic only: a ping never grants a multiplier.

The panel for a dispute. Somebody sends you a stake key or the address they trade from — paste either one, with the competition picked in step 2, and this lists every movement of that token by that wallet inside the window, newest first.
Each row says whether it is already credited and by what, or — if not — whether it can be and why not. Those reasons are the real ones: a grant is checked against the same four conditions every other buy faces, from the same code that answers here, so nothing shown as creditable will be refused and nothing refused will be shown as creditable.
What a grant is. It records the transaction as a widget buy and lets the next scan recompute from it. It does not edit anybody’s conviction — the corrected figure is produced by the same arithmetic as everyone else’s, so it cannot drift from it. It is idempotent on the transaction hash: granting twice produces one credit. And Revoke takes it back, whatever produced it.
What you cannot grant. A sell, a transfer or airdrop, a buy before the competition started or after it ended, or a transaction the scan has not read yet. Those are the chain’s answers, not yours.

Every movement of this competition’s token, by every participant, inside the window — with the full transaction hash and the full stake address, so a row can be pasted straight into an explorer. Click either to copy.
Each row also says whether that transaction earned the multiplier, and if not, the reason — read from the same rule the scoring engine uses, never a second copy of it.
The fingerprint hunt is gone. This panel used to read every buy for the output addresses, script hashes and metadata it carried, and rank the marks they shared, looking for a router fee address that would identify a widget trade. That is attribution by venue, and a router is free to change venue between trades — a widget buy through an unfingerprinted pool earned nothing while a fill placed elsewhere that routed the same way earned the multiplier. Step 5 answers the question properly, from Hizz’s own records, and costs no chain calls at all.

Upload one image per competition. It appears behind the Live Competition page and behind that competition’s share card — set it once, and both follow. Works for the live competition and for any future one.
PNG, JPEG, GIF or WebP, up to 4MB. A wide image around 1600×900 looks best: it is drawn to cover, so a very tall or very narrow one gets cropped at the sides. The file is checked by its actual contents, not its name. SVG is not accepted — it can carry script. Artwork always sits under a scrim, so it can never make the figures hard to read. You can also paste an https URL instead of uploading.

The scoring engine recomputes every live competition on a fixed cadence, and the Live Competition page polls on the same one. So “the board hasn’t moved” has two different answers — the scan hasn’t run yet, or it ran and nothing changed — and this tells you which without reading the logs.
Refresh now triggers a recompute immediately instead of waiting for the next tick. It uses chain calls, so it is worth pressing after crediting a buy or fixing a wallet, not on a loop. If the chain budget has dropped into its reserve, the scan stretches to a slower cadence rather than running the budget to zero — scoring slows, it does not stop — and that shows up here as In reserve.

A leaderboard is stored as one row that gets overwritten, so by the time somebody notices a wallet has gone, the evidence of it going has been replaced. This asks the question properly: it reports what the saved board says about that wallet, what the chain says right now, and the day's call budget — because “unreadable” and “the budget was spent” are the same event seen from two sides.
Search by the name you know them by (a profile name, including one linked through a snek.fun Turbo wallet) or by any part of their stake key. It re-reads the chain for each match, so it costs a handful of calls — use it on a report, not on a loop.
The three answers it separates. Sold — net fell to zero, and the sells are in the feed. Transferred out — buys in the feed but holds_now at zero: moving tokens to another wallet is not a sell and never appears in the feed, yet it still ends the position. Unreadable — a chain read failed, which is not a fact about the wallet at all; since this build such a wallet keeps its place at its last confirmed figures instead of vanishing.

Until the coverage fix, a community whose history walk had not caught up was still scored on 30-day retention, holder growth and new-holder survival — from an unwind missing everything since the walk's frontier. Those readings said Retention 100%, and they are still stored: the Communities Δ column and Community Health's What changed both compare today against them, so without a correction the fix itself shows up for a month as declines that never happened.
Preview changes nothing. It lists, per community, the readings the walk's own cursor proves were taken on an open record, and what each would become: the 30-day figures set to unmeasured (what the corrected gate stores for such a day), and Community Health recomputed from that day's own stored inputs. A caught-up community's readings are never changed — nothing recorded says whether they came before or after its walk finished — but any shaped like the failure are counted so you can see them.
Apply writes only the set you previewed, and keeps each reading's before-image. Revert puts a batch back, except any day the daily snapshot has since rewritten with newer figures.

Pick a community, then edit it. Everything here used to live in the TOKEN_REGISTRY constant in the backend, which meant adding a community was an edit, a review and a deploy — and until that landed, the project's own treasury counted as its biggest fan.
What the wallet lists do: liquidity pools, vesting contracts and burn addresses are excluded from this community's holder counts and health metrics. They are never read by competition scoring, finalisation or payouts, so nothing you type here can change a score or move prize money.