Generate or verify an Inkan — trust nothing, recompute everything

Content anchor — typed commitment & seal

The first layer of the standard. A (data, kind) pair commits to typed content: the kind is folded into the digest, so a seal over an address and a seal over a contract can never collide even when the underlying bytes are identical. Enter a pair to generate its anchor and seal; add the seal image someone showed you to check it pixel-for-pixel.

Peer-to-peer identity checks. Two parties who should be holding the same key, address or handle can each seal it and compare: a mismatch is visible at once. Define your own kind — yourapp:member — and that comparison can never be confused with another application's, because the kind is inside the digest. Per §9 of the standard, treat a visual match as a tamper-notice channel only: it is never sufficient authentication for a value-at-risk decision, and a GENUINE verdict requires the full 32-byte digest — which is what the seal-image comparison below actually does.

Tiers. A kind may carry @t1, @t2 or @t3, choosing how many cells the seal draws: 72, 48 or 24. More cells means more visible entropy and a costlier visual forgery — roughly 2^79.5 distinct seals at T1, 2^55.5 at T2 and 2^31.5 at T3. Reserved kinds have a fixed tier (address is T1, code is T3). Any other string defaults to T2, and so does an unrecognised suffix: @t4 is not a tier, so thing@t4 is simply a kind whose name ends in "@t4", still at T2. Tier changes the picture only. The anchor is the full 32-byte digest at every tier, which is why T3's findable image collisions are a documented design choice rather than a weakness — the digest is what commits, never the picture.

Data to seal (an address, a key, any text…)

text text file raw bytes (hex)

Kind — what the data is

Avalanche — why a lookalike cannot be grown from yours

The seal above is not a picture of your data, it is a picture of its digest, so neighbouring inputs are not neighbouring images. This flips every single bit of whatever is in the sealed-data field, recomputes the cells each time, and reports the fewest that moved — the best an attacker could hope for by nudging the input. The worst case is drawn beside yours, so you can see that even the least dramatic single-bit neighbour is unmistakable.

Code fingerprint — software & build provenance

The second layer of the standard. A release publishes the fingerprint of the exact bytes it shipped; you recompute it here from the file you actually hold. A match proves the code you are running is the code that was released. Different adopters get different digests for identical bytes, because the adopter name is inside the hash.

Warrant canary — is the operator still uncompromised?

The third layer of the standard. A canary is a signed, freshness-proofed statement that the publisher has not been compromised or coerced. Absence, staleness or a bad signature is the warning. The record embeds a recent block height and hash, so it cannot have been signed before that block existed. This page verifies only: it holds no key and can sign nothing.

How to use it. 1. Get the publisher's public key from somewhere you already trust — pinned in an app you installed earlier, a previous release, or handed to you in person. Taking the key from the same page that serves the canary proves nothing, because whoever controls that page controls both. 2. Fetch their latest canary record and signature from wherever they anchor it. On-chain is the point: an inscription or OP_RETURN cannot be quietly withdrawn, so a canary that stops appearing leaves a visible gap instead of vanishing. 3. Paste record, key and signature below and check. 4. Read the verdict, and sanity-check the record yourself: seq should be higher than the last one you saw, and block_height should be recent.

What the verdicts mean. OK — signed by that key and inside the freshness window. STALE — the signature is good but the record is old. The publisher has stopped renewing; that is a warning, not a pass. INVALID — the signature does not verify. Wrong key, altered record, or forgery. UNSUPPORTED — a newer record version than this page implements. Get a newer verifier; it is not a finding against the publisher. MALFORMED — the record, key or signature is not in the form the standard requires, so the signature could not be checked at all. Usually a truncated paste. It is not a pass, and not evidence of forgery. And the one no button can show you: nothing to check at all. If a canary you expect is simply missing, that is the loudest result of all — the design assumes silence is what a coerced publisher is able to produce.

This checks any publisher's canary — paste theirs below. Nothing here is specific to Inkan or to any one project. Load the BRC-145 example if you would rather see it work first; that record is dated 2026-06-30 and will read STALE once it ages past the 35-day window, which is itself worth seeing — it is what a canary nobody renewed looks like.

Paste the record exactly as the publisher published it. The standard fixes its form byte for byte: one line, the seven members in key order, no spaces. A copy that has been re-formatted reads MALFORMED, because a verifier must judge the bytes that were signed. Blank space around the record is ignored.

The record cites a block height and hash, which is what stops it being backdated: it cannot have been signed before that block existed. Checking that needs a fact about the chain, and this page never goes online — so bring one. Enter a height you trust, from your own node or a wallet, and the arithmetic happens here. Leave it blank to skip the check entirely.