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, updated for SDK 0.4.0 (@erc8426/core 0.4.0). New in 0.4.0: manifest version is a MUST, and the optional issuer identity commitment checks are included. 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.
Signature rule, SDK 0.4.0: a signature that is 0x alone, or has an odd number of hex digits, is refused with 401 and error: "signature_invalid", not 400 invalid_request. That applies on the gated manifest route, the signed action route and the rotate route. A signature that is not 0x prefixed hex at all is still 400 invalid_request.
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.
Roadmap
Where PassWrks stands right now, and what comes next.
What is live, and what is next
- Pass Checker, live now. The conformance checker on this page, with 40 checks and a stamped verdict for every run.
- Pass Preview / Debugger, next, Phase 2. Renders a pass before it ships and flags problems field by field.
- Issuer Starter Kit, follows, Phase 3. Templates and setup help for issuers shipping their first pass.
Plain English glossary
The main words used on this page, explained the way you would explain them to a friend. No crypto background needed.
The pass and where it lives
- ERC-8426: the rulebook this page checks against. It is the standard that lets an NFT carry a pass for Apple Wallet or Google Wallet.
- Token ID: the number of one individual NFT in a collection. Pocket No. 042 is token ID 42. You can find it on the collection page, the marketplace listing, or the block explorer page for that token.
- Contract: the program on the blockchain that issued the tokens and keeps the official record of who owns each one. Every collection has one contract address.
- passURI: the question the checker asks the contract to get the web address of one token's pass file. If the contract cannot answer it, no wallet can load the pass.
- Manifest: the pass file itself, a small data file listing the download links for the Apple and Google versions of the pass, plus when it was last updated.
- Version: every manifest must carry "version": 1. If it is missing, wallets still read the pass as version 1, but the issuer fails the version check. If it is present and is not 1, the manifest fails.
- tokenURI: the address where an NFT's public description lives (its name, image, and details). Some issuers also keep a copy of the pass details there, and the mirror checks read that copy.
Proving ownership, and the rulebook
- Gated: locked to owners. A gated pass is only handed over after the visitor proves they own the token.
- SIWE: short for Sign In With Ethereum, the standard way to prove you control a wallet by signing a message. Signing is free, and it never moves your tokens.
- Nonce: a one time random code inside a sign in message. Because it changes every time, a copied proof cannot be used twice.
- RPC: the doorway this page uses to read the blockchain. The chain presets at the top of the form fill it in for you.
- MUST and SHOULD: words from the rulebook. A MUST is required, so failing one means the pass does not conform. A SHOULD is a strong recommendation, so failing one is a warning, not a failure.
- Issuer commitment: an optional promise a contract can make on chain about who signs its passes, read through passIssuer(). When a contract makes one, every manifest must name the same signer, member for member. When it makes none, those checks are skipped.
- Conformance: checking something against the written rules of a standard, line by line, instead of going by opinion. That is all this page does.