Illustrative demo · Fictional companies and example credentials. Scenario buttons replay saved outcomes; they do not run verification, move money or create an on-chain anchor. Live check runs the real verifier on synthetic credentials. Inspect saved and hosted evidence →
Agent commerce · provenance
Provenance — a verified chain of custody
Explore how agents could check legal identity at each handoff: raw material → manufacture → customs → freight → delivery. This animation illustrates a chain of custody; its companies, goods and receipt codes are fictional. No handoff verification or anchoring runs in this scenario.
vLEI verified to GLEIF goods handoffillustrative verification at each hop · click a party for detail
📦
Why provenance. When agents move real goods across borders, “who handled this, and were they authorised?” must be answerable after the fact. Each leg here is the same vLEI check from the deal flow — chained together, the trade carries its own tamper-evident audit trail.
DACS-2 · Vet
How verification works
Demos gives a buyer's agent a verification gate: its SDK reads the native KERI/ACDC chain, checks authority against a pinned trust root, and signs a digest-only attestation. That result can gate settlement and be anchored for later audit. The scenarios illustrate this flow with a demo trust root; production use requires accepted GLEIF credentials and current status checks.
At a glance
🎯
A verifier, not an issuer
Consumes vLEI and emits a verdict. Not a wallet, not a QVI.
🔒
Digest-only
Credential contents stay out of the attestation; digests let another party correlate the checked chain.
⚓
Pinned trust anchor
Schema SAIDs are pinned; the chain root must be the GLEIF root AID.
⛔
Fail-closed
Unresolvable, revoked, off-root or out-of-scope → FAIL. Silence is never a pass.
The pipeline — presentation to verdict
Each check talks to KERIA over the network (OOBI, key-state, TEL, IPEX, schema) — not a pure function over local data.
📨
0 Presentation & key-control
The holder presents the chain over IPEX. The agent proves live control of its delegated key over a fresh challenge bound to this transaction — so a captured proof can't be replayed.
🔑
1 Keys & schemas
KERIA resolves OOBIs, pulls each issuer's Key Event Log, and fetches the vLEI schemas — each pinned by SAID.
🔗
2 Key-state & delegation
For an agent, confirms the agent AID is a delegated identifier whose delegator (di) is the issuing entity — the entity holds the rotation & kill switch.
🧬
3 ACDC chain walk
Breadth-first walk of the e.* edges to the root. Each SAID + issuer↔issuee lineage authenticated (I2I) or exempted (NI2I), with the operator governance-pinned.
🚫
4 Revocation (TEL)
Each credential's Transaction Event Log status at time-of-use. Anything but status=0 fails closed.
⚖️
5 Verdict
Evaluates the transaction against the credential's authorityScope and emits a signed record with a recordDigest — ready to anchor.
Finance officer view
What your agent did in the last 24 hours
Your agents
Every agent your company has authorised: who granted its authority, what it may do, what it did today, and the controls your officers keep over it.
Counterparties
Every company your agent dealt with today. Click one to see who they are.
Activity
▤
Illustrative activity for a fictional company. Each outcome follows the verifier's saved verdict for that counterparty.
Agent commerce · control room
Agents that trade only with agents they can trust
Before your AI agent pays, it checks which company stands behind the other agent and what that agent may do. Good deals go through; risky ones are stopped before any money moves.
Industry lens
Powered by Demos: identity and authority are checked before payment, with signed evidence kept for audit.
Swipe the network left or right to see every company.
verified chain to GLEIF deal request broken / refusedclick any agent to run its deal · click a company or the root for detail
Counterparties in the network
Click a company to see who they are, or run a deal with it.
Showing 4 key examples.
◆
Why this matters. AI agents now act with real money. Every business needs to know which company is behind an agent and what it may do, checked per deal, revocable and auditable.
Simulated deal · your point of view
Simulate a deal
From Nordbank AB · treasury-bot's point of view. Pick a counterparty, then run the deal — Contact to Verify. Verification gates settlement: value only moves if the seller checks out and the transaction is within its granted authority.
Hosted KERI stack · live
Live check
Run the verifier for real. The server mints a fresh synthetic vLEI chain on its own KERIA agents, presents it, checks identity, authority and key control, then signs the result and keeps the exact evidence. The saved scenarios elsewhere on this page do not change.
Checking for a hosted verifier…
Native vLEI read
Trust chain
Flow 2 — chained through an accountable officer. Authority flows left-to-right from the GLEIF root down to the
delegated agent. Each card is one credential; the label under the arrow is the ACDC edge that links it to its parent.
Who's who in the chain
⚓
GLEIF root
The global root of trust — every chain must terminate here.
🏛️
QVI
Qualified vLEI Issuer — GLEIF-authorised to credential legal entities.
🏢
Legal Entity
The company itself, credentialed by a QVI.
👤
Accountable officer
A person (ECR) the entity stands behind — the human in the loop.
🤖
Agent (delegated)
The AI agent, delegated by the entity — revocable, scoped authority.
Fail-closed
Verification verdict
The same verifier, run over a valid presentation and three tampered ones. Every negative fails closed.
Demo data
The verdicts below are saved illustrative cases. Live check verifies a fresh synthetic credential chain on the hosted stack and shows its signed result separately; it does not authorize a commerce purchase.
DACS-1 & DACS-2
Attestation & anchor
Demos signs the verification result so another agent can inspect who checked it, what was checked and when. The saved example below illustrates the digest-only attestation and DACS VerifyResult. A storage locator alone does not prove an on-chain anchor.
Hosted evidence — separate from the scenario
Load the server's latest saved dataset without running or revoking credentials. A saved pass records an earlier check; it does not establish current credential status or authorize a new purchase.
Not loaded. The illustrative receipt below is unchanged.
VerdictrecordDigest
→
SignDACS-1 · Ed25519
→
AnchorSR-2 storage
→
VerifyResultDACS-2 · §7.5
Saved illustrative receipt — embedded example, not the latest API result
🧾
A human-readable view of the signed VerifyResult below — every value is a real field of that object. How checked reads verifiable-credential because DACS has no KERI method kind yet; we map to the closest one.
Under the hood — digest-only, nothing added
Signed attestation DACS-1
AttestationRef §7.5.2
VerifyResult §7.5
🔒
No credential contents ever enter the attestation. A relying party re-presents the chain and recomputes recordDigest / chainDigest to correlate; the anchor itself leaks nothing.
Wire it in
Integration
The verifier lives in the SDK (@kynesyslabs/demosdk/identity/vlei) and takes no KERI-client dependency — it reads through one injected interface, so you plug in any transport.
This page + the /api/run live-verification endpoint.
✅
No sandbox keys needed — it runs fully standalone today. The stack is built from public images (GLEIF's schema server, weboftrust KERIA/witness); the only credential is a locally-generated 21-char passcode, not a partner key. Sandbox endpoints matter only to verify real-world credentials on a partner's hosted network — an env-URL swap (KERIA_ADMIN_URL, …), a config change, gated on the agreement.
Reference
Status & glossary
What's built
✓
Verifier
5-step flow, both grant flows, delegation + scope + replay-proof.