Every vc.issued, agent.registered and vp.verified is salted-hashed into a Merkle batch; batches are hash-chained and the roots anchored on-chain (AnchorRegistry). "Verify in MY browser" recomputes the whole chain with WebCrypto and reads the on-chain root straight from the RPC — without trusting this server.
no batches yet — run a flow and the worker folds it within a minute
These entries are read from the IdentityRegistry ERC-721 — each agent is an NFT owned by its organisation's account, pointing at a Registration File. The raw context (chain · registry ) lets anyone re-verify against any node. The chain check runs in YOUR browser: WebCrypto verifies the ES256 signatures — this page cannot fake them.
no agents minted on-chain yet — the publisher sweeps the registry every minute
Payment scope requires registered or higher: genesis ▸ org ▸ registered may authorize payments; traced_ephemeral and bilateral may not. The node badges above read the live registry — Genesis, Org, Registered, Traced-ephemeral, Bilateral.
Two open SDKs (python + node) implement the same crypto contracts, cross-tested byte-for-byte. Deployed as a single docker compose behind a Caddy edge — what you are looking at is the production stack, not a diagram of intent.
A DID is an address you own because you hold its private key — like an email address no provider can confiscate or impersonate. Each agent generated a keypair and published a DID document: "this is my public key, this is where to reach me."
Before the network trusts an agent, it passes KYC-A ("Know Your Agent"): register the DID, prove key control by signing a fresh challenge, declare capabilities, get them approved, receive an agent credential. From then on every message it sends can be checked against its public key.
The order itself is ordinary business data — no cryptography in the payload yet. What matters is who is speaking: every agent-to-agent request rides an authenticated handshake where each side proves control of its DID key, so NorthBuild knows it's really Cobalt, and vice versa.
That kills impersonation before the interesting part starts: you can't forge an invoice conversation if you can't sign as the counterparty.
The Trust Layer doesn't sign the invoice fields directly. It salts and hashes each fact separately, then signs the list of hashes. The signature covers everything — yet each fact can be shown or withheld later without breaking it.
Think of a passport that can prove "over 18" without showing your birthdate. The trick is decided at issuance: hiding must be designed in from the start.
The credential is also bound to Cobalt's key (cnf), so only Cobalt can use it.
Cobalt doesn't send the credential to the bank. It builds a Verifiable Presentation: the signed hash-list plus only the disclosures it chooses to open. The hidden facts travel as opaque hashes — present, verifiable, unreadable.
It adds a key-binding proof (KB-JWT): a signature over the bank's fresh nonce, made with the same key the credential was issued to. Stolen credentials die here — a thief can't produce that signature.
Meridian checks four things: the Trust Layer's signature on the hash-list; that each opened fact hashes to an entry in that list; that the KB-JWT was signed by the credential's holder key over Meridian's own nonce; and that nothing is expired or revoked.
For the sealed facts, the hashes prove they exist and were covered by the signature — while revealing nothing about their content. That's the asymmetry that keeps selective disclosure honest: you can hide, but you can't lie.
Factoring fraud is usually a data problem: invented invoices, inflated amounts, the same invoice sold twice. Each one forces the bank to distrust the document and call the buyer.
Here the document proves itself: the buyer's confirmation is cryptographically inside the credential, the amount can't change without breaking the signature, and holder binding stops resale of someone else's invoice. Verification is instant — capital moves in minutes, not weeks.
The pattern generalizes: an issuer signs claims, a holder stores them and chooses what to show, a verifier checks math instead of making phone calls. Nobody needs a shared database — and the issuer never learns where the credential gets used.
Swap invoices for diplomas, licenses, KYC files or agent permissions — the machinery is identical. That's what AgentID proves: agents that can trust each other's claims without trusting each other.
Issuance flows top ▸ bottom: the registry verifies the organisation's domain (KYB-A), the organisation issues the agent's credential.
Every signature this agent produces can be checked against the public key behind this DID — that registry entry is why the other agents trust it without ever having met it.
This agent sits above the payment line: its credential was issued by its organisation (see the DID chain above). Press below and the buyer agent itself signs a pay-scoped presentation with the same key that passed KYC-A — the authorization comes straight from the Trust Layer, the mirror image of the guest's typed refusal.
The IdentityRegistry mints one NFT per agent; its owner is the organisation wallet. The ValidationRegistry records the Trust Layer's attestations against it. The response carries the raw chain facts (chain id, registry addresses, owner, tokenURI) so you can re-verify every read against the RPC yourself.
The neutral root of trust: it registers agent DIDs through KYC-A, issues SD-JWT credentials and verifies presentations. It never sees the sealed facts and never learns where a credential gets used.
Everything below was created in this browser. The private keys are non-extractable — the Trust Layer only ever saw public keys and signatures.
This is what the trust layer adds: any agent can now resolve your DID to your public key and verify your signatures — without asking you, and without a shared database.
A session-bound guest sits below the payment line: the matrix needs level registered or higher to authorize a payment. Press below and the Trust Layer verifies your presentation with a pay scope for real; the refusal — and the resolved level — come straight from the backend, not from this page.
Payment requires level registered or higher (registered ▸ org ▸ genesis). The same presentation under a non-payment scope still verifies fine — the block is about the class of agent, not the credential.