Paste the ADMIN_KEY value from your Railway variables. It's saved in this browser only and sent with each admin action.

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.

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, What Changed and the outlook all 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), the Community score and HODL 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.