The kascov passport · checked in your browser

Your reputation, verifiable without us.

Every role you earn here becomes a claim keyed to the address you proved on chain: the address, the badge, the date, nothing else. The claims are merkleized, the root is published with them, and the math checks out in any browser — including one that has never heard of kascov.

look up your claims how a role becomes a claim check the math
reading the anchor status…

The mainnet anchor — the claims root and the lane ledger root written together into one Kaspa transaction — makes the publication itself checkable without this site. Its live status is published at /passport-anchor.json; this box checks that file against the claims file in your browser and says exactly what it finds, one way or the other. With JavaScript off, the file itself is the same answer.

In your browser · nothing leaves it

Look up an address.

Claims live in /passport-claims.json and this box renders them in your browser. With JavaScript off, read the file directly; it is the same data, proofs and root included.

Enter the address you proved and this box shows every claim published for it: the badge, the granted date, the merkle root, and a verify-it-yourself block with the proof. The lookup runs entirely in your browser; the address you type never leaves it.

Earned, never bought

How a role becomes a claim.

  1. Earn the roleToday that means the verified-holder role (prove an address with a free signature, how it works) and, as the unknowns board opens, the auditor role for pinning a build. Roles are earned, never bought: the token buys status, voice and access, not a verdict and not a badge.
  2. The role becomes a claimA claim is three fields: the proven address, the badge name, the granted date. Voting mints one too: when a round closes, a participation claim — voted-round-N, naming the round — lands next to your badges. It never says what you picked, and it exists only for rounds closed after participation claims shipped: earlier rounds deleted their ballots, so there is nothing to mint from. No Discord id, no balance, no history — what the bot stores while a role is live is a separate, fully enumerated list at /bot.
  3. The claims are merkleizedEach claim hashes to a leaf, the leaves build a tree, and the root is published in the same file as the claims. Change one claim and the root changes; that is the whole trick.
  4. The root gets anchoredA mainnet transaction carrying the root makes the publication itself checkable without this site. The payload carries a second root beside it: the merkle root of the lane ledger, so every capacity grant is committed by the same transaction. The box at the top of this page checks whether that has happened for the root currently served, and says exactly what it finds.

sha256-v1 · never a guess

Check the math.

The file names its own algorithm in a hash field. This page knows sha256-v1 and refuses to guess at anything else.

the recipe

  • leaf = SHA-256 of the UTF-8 bytes of the claim object as canonical JSON — keys recursively sorted, no whitespace, the exact bytes verifyBadge() hashes in the js and py clients
  • each step up hashes the two 32-byte nodes concatenated in ascending byte order — sorted pairs, so a proof needs no left/right flags and two verifiers cannot disagree
  • the final node must equal the file’s merkle_root

the lane ledger tree

  • leaf = SHA-256 of each event in /lane-ledger.json as {"address":…,"expiry_unix":…,"minted_utc":…,"tier":…} — keys in that order, no whitespace, events in file order
  • then the same sorted-pair walk as the claims tree; an absent or empty ledger contributes the SHA-256 of zero bytes, e3b0c4…b855, so the commitment never quietly shrinks to claims-only
  • the anchored payload is the ASCII string kascov:passport:v2:<claims root>:<lane root>, both roots readable in raw chain bytes; anchors from before the ledger existed carry kascov:passport:v1:<claims root>

recomputed on the spot

Every claim this page renders gets a “verify it yourself” block with the claim JSON, its proof and the root, and the browser recomputes the whole path on the spot. If the recomputed root ever disagrees with the published one, the page says that too, in red. The lane root is not recomputed here: its recipe above needs only a SHA-256 tool, and /passport-anchor.json repeats the instructions next to the roots themselves.

Nothing shown over something guessed

What is live today, and what is not.

live today

  • the claims file and its published root, at /passport-claims.json, regenerated when roles change
  • this page’s in-browser recheck of every proof against that root
  • the mainnet anchor — the box above reads its live status; between anchors the newest root’s publication relies on this site alone
  • the anchor box itself, which checks /passport-anchor.json against the served root in your browser and reports exactly what it finds
  • the role flow itself: prove an address, earn the role (/bot)

pending, in the open

  • claim signatures, so a single claim can travel and be checked alone, without the whole file
  • the KCC convention review — whether this claim format becomes a shared convention is not kascov’s call alone

A passport claim is a record of something earned, never a verdict about a token or a build. Verdicts on this site come from the chain and only from the chain. If no claims file exists yet, this page says “no claims published yet” and shows nothing — nothing shown is always better than something guessed.

What the bot stores and deletes is enumerated at kascov.io/bot. What holding the token does and does not do is at kascov.io/token.