Run a check
Live mode talks JSON-RPC and HTTPS straight from your browser — no server, no key, nothing stored. If an issuer blocks browser CORS, the affected checks are marked skipped with the exact CLI command that settles them.
Conformance report
NO RUN YETThe bench is clear.
No report yet. A run takes three passes over the target:
- Contract pass — ERC-165 probes and passURI(tokenId) reads, including the revert check on a nonexistent token.
- Manifest pass — fetch, media type, shape validation, lint, and the tokenURI metadata mirror.
- Gated pass — if the manifest answers 401: challenge issuance, SIWE fields, nonce freshness, and garbage-proof refusal.
New to a target? Hit Run demo report to see a full stamped report on specimen data first.
The check registry
Every check this workbench knows, with its stable ID, RFC 2119 level, and the spec section it enforces — the same registry the @erc8426/conformance CLI runs. A failed MUST means non-conforming (exit 1). A failed SHOULD is a warning only.
| Check ID | Level | Section | What it proves |
|---|
Reading a report · the owner path
How the stamp is decided
- CONFORMS — every MUST that could be observed passed. CLI exit 0.
- DOES NOT CONFORM — at least one MUST failed. CLI exit 1. The fix list in the report is ordered by blast radius: discovery first, then manifest, then authorization.
- INCOMPLETE — no MUST failed, but checks were skipped (CORS, gated owner proof, server-cooperation checks). Treat as “not yet proven,” not as a pass.
- Warnings — SHOULD failures: updatedAt in milliseconds, a Google URL that isn't a Save link, an Apple URL not served as .pkpass. Worth fixing, never blocking.
The two checks gated.expired-proof and gated.wrong-domain-proof are always skipped by design — a valid expired or wrong-domain proof can't be produced without the server's cooperation, so the issuer's own tests must cover them.
Proving the owner flow
A gated issuer answers 401 with error: "proof_required" and a challenge URI. The owner path then proves three things the public path can't:
- gated.owner-200 — the owner's signed ERC-4361 proof resolves the manifest.
- gated.no-store — that response carries Cache-Control: no-store, so a gated manifest is never cached into the wrong hands.
- gated.replay-refused — the same proof a second time is refused: nonces are single-use.
Why the key never touches this page: the suite reads it from an environment variable (--owner-key-env), and it signs only a challenge that names the serving host as verifier, is scoped to this token + the acquire action, and expires within one hour. Anything else is never signed.
PassWrks — one toolkit, three instruments
PassWrks is the name for the whole ERC-8426 builder toolkit. The Checker is the wedge — it tells you if a pass works. The next two tell you why it looks wrong, and how to ship one.
Pass Checker
Web conformance suite: contract + token ID in, stamped pass/fail report out, shareable route for every run. Public path first, gated owner path alongside.
Preview / Debugger
Renders the pass in-browser — Apple and Google side by side — and flags the classic gotchas before certs are paid for: missing icon, duplicate field keys, overflow fields, wrong hero ratio, non-public images.
Starter Kit
Template repo + deploy button + a credential wizard that validates the Apple Pass Type ID and Google service account as you enter them. Zero to a live pass in an afternoon.
The PassWrks platform — hosted site plan
PassWrks grows from this single workbench into a hosted home for ERC-8426 builders. This page is the live first surface — everything below is the build order for the full site, in the order it ships.
What the hosted PassWrks site holds
- Home / landing — what ERC-8426 is, why wallet passes for NFTs, and a live Checker demo up front. No sign-up to run a check.
- /checker — this workbench, hosted as-is: browser-only reads, no keys, shareable #/check/… routes for every run.
- /preview — Phase 2 Preview / Debugger: Apple + Google render side by side with gotcha flags.
- /starter — Phase 3 Starter Kit: template repo, deploy button, and the credential wizard.
- /registry + /docs — the 35-check registry, spec notes for ERCs PR #2036, and plain-language guides for each MUST.
- /examples — real contracts tested in public, starting with the WalletChi testnet run, with their stamped verdicts shown.
One rule across every surface: tools for serious projects, built to last — no extraction patterns, no key ever asked for in the browser.
Why PassWrks — and what is still open
- PassWrks — shortened spelling, reads instantly as “pass works.” Chosen over Passifi (already a crypto token, PFI) and PassWorks (passworks.io — an existing Apple / Google Wallet pass platform since 2014).
- Checked so far: no web hits for “PassWrks”; passwrks free on npm; no GitHub org/user named passwrks.
- Still to verify before launch: register the domain at a registrar (availability not yet confirmed there), then claim the GitHub org and npm name under PassWrks.
- First real test, next: WalletChi on Robinhood Chain testnet — chain 46630, token ID 1 first — run it here, keep the stamped verdict, and let a clean public/gated result trigger Phase 2.