Verifier Playground

Don't take our word for it. Run the verifier.

Below is the live credential chain of a real autonomous agent operating in production - approved within mandate, declined over mandate, revocable at any moment. Inspect it, then verify it yourself under Mastercard's published reference implementation with one command.

Live chain inspector

Read directly from the production verify surface - the same endpoint external indexers poll today. L1 binds the agent's identity, L2 mandates carry the spending authority, L3 presentations are the transactions. Every credential anchors to a versioned governance chain: Constitution → Charter → Passport - and, below, to a real ERC-8004 on-chain registration you can check yourself against the chain and IPFS.

Loading live chain…

Who's verifying us

This surface already has an audience: external ERC-8004 and x402 indexers discover the verify endpoint from our agents' on-chain agent cards and poll it daily - unprompted. One of them is itself an on-chain-registered agent: an on-chain-registered agent is verifying our on-chain-registered agent - today, unprompted.

Loading live counters…

Checked against the Mastercard reference verifier

Mastercard publishes a reference verifier for the Verifiable Intent credential format (agent-intent/verifiable-intent, Apache-2.0). That reference implementation, their code and their format, accepts the credentials this server mints, in both immediate and autonomous modes. We enforce that parity as a strict gate in our continuous integration: every build mints fresh credentials with throwaway keys and runs them through the reference verifier. If it ever rejects one, the build fails.

One configuration note. The reference verifier expects Mastercard's own card credential type at the root of the chain. Our gate tells it to expect this server's credential type instead, so what it proves is wire-format parity. Which root credential type a verifier should trust is a separate decision that this check does not make.

You can run the same check yourself. We publish a vector file of credentials this server minted, in both modes, with fresh throwaway keys, and a verifier script that imports only the reference package. Requirements: python ≥ 3.10 · git

# install Mastercard's reference package at the commit our gate is pinned to
pip install "git+https://github.com/agent-intent/verifiable-intent@356c29635f1c44df7de02edb58699ca9f29bece6"
# fetch the vectors and the script, then run the reference verifier over them
curl -O https://vi.appliedidentities.com/playground/xval/vectors.json -O https://vi.appliedidentities.com/playground/xval/verify.py
python3 verify.py vectors.json

exit code 0 = the reference accepted every vector · the same gate runs on every build of this server

== immediate == PASS (4 checks performed, 2 skipped)
== autonomous == PASS (12 checks performed, 4 skipped)
Verdict: the reference ACCEPTED every vector (wire-format parity at the pinned commit)

What this does and doesn't prove. It proves Mastercard's published reference implementation accepts credentials minted by this server, at the pinned reference commit, under the configuration described above. It does not mean Mastercard operates or endorses this service. The credentials carry production lifetimes, and the reference refuses any final-layer credential older than an hour, so the script checks them at the mint time recorded in the file. Run it with --live-clock to watch the reference reject them as expired. The vector file names the server commit and the reference commit it was built against. The minting source is not public.

Raw surfaces: issuer keys · revocation surface · chain API · Verifiable Intent credential plane