Your agent just got a job offer. A counterparty wants it to fetch market data, sign a transaction, and get paid 50 USDT0 on X Layer. The counterparty says they're at 0xA17c...9Ef4, they speak x402, and they've been "active for six months." How do you decide whether to hand your agent the keys?
In 2026, that question is the entire game. Agents negotiate, agents pay, agents settle — and almost nothing sits between a cold request and a value-moving transaction. EVIDIQ is what we built to sit there. It's the trust layer for AI agents — verifiable, deterministic, and opinionated about what "trust" actually means when the counterparty is software.
What Is a Trust Layer for AI Agents?
A trust layer for AI agents is infrastructure that verifies an agent's identity, capabilities, and reputation before value moves between parties. EVIDIQ is a trust layer for AI agents: it returns a deterministic 0-100 score plus a proceed / proceed_with_escrow / caution / do_not_proceed recommendation, with evidence anchored onchain and a signed report any party can independently verify.
The phrase gets used loosely, so let's draw a clean boundary. The trust layer for AI agents is not the same thing as the identity layer, the payments layer, or the compute layer — it sits across all three. Identity says who minted this address. Payments says how value moves. Compute says where the inference happens. Trust says: given who this is, what they claim to do, what others have seen them do, and what's risky about the deal right now — should I proceed, and if so, with what protection?
We didn't want another black box. Our scoring formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Same inputs, same score, every time. The trust score is auditable because the inputs are auditable, and the report is signed. You can rebuild it yourself if you want to. That's the difference between a trust layer and a vibes engine — and it's why we open-sourced the math instead of burying it behind a model.
One Call, Start to Finish
Let's follow one real request, end to end. Your agent has heard about a service called PriceSage, run by an address it doesn't recognize. Before paying, it calls our MCP server.
POST https://evidiq.dev/mcp
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": "req_9821",
"method": "tools/call",
"params": {
"name": "verify_agent",
"arguments": {
"address": "0xA17c3D2bF9e8c4A11c0dE7b9Ef4",
"chain": "x-layer",
"capabilities_declared": ["crypto_prices", "x402_paid_endpoint"],
"endpoint": "https://pricesage.example/.well-known/agent-card.json"
}
}
}
No payment attached. The server replies with HTTP 402 and an x402 v2 challenge — accepts[] carrying the price in USDT0, scheme exact, and the transferWithAuthorization payload your agent signs with EIP-3009. The agent pays, retries with the X-PAYMENT header, and the server does its work.
Behind the scenes, four things happen in parallel:
- Resolve the address — pull any ENS reverse record, any ERC-8004 identity id, and the chain-of-control on X Layer.
- Probe the endpoint — a bounded ~6s GET against the agent-card URL, checking TLS, reachability, and whether the response is a real, machine-readable skill manifest.
- Score reputation — look for "economic skin in the game": does this endpoint actually serve a paid x402 endpoint, how long has it been reachable, and what identity anchors back it?
- Run an AI risk analysis — if requested, this part routes to 0G Compute running GLM-5.2 inside a TEE, recording both the compute provider address and a request id.
About 800ms later, the agent gets back a JSON object. The headline is a number — say 72. The recommendation is proceed_with_escrow. And the body is a full Trust Report: each input broken out, each score with its weight shown, the keccak256 hash of the canonical report, the 0G Storage tx that anchored the evidence onchain, and an EIP-191 signature from the EVIDIQ key. Anyone — your agent, your auditor, your counterparty — can re-fetch the evidence, re-hash it, and recover the signer. That's not a marketing line. It's literally a one-line ethers call.
The whole flow lives in the open. We documented every step in the EVIDIQ Sentinel docs, and the operator-side tools for running your own MCP gateway are in the EVIDIQ Operator docs.
The Three Questions Every Trust Layer Has to Answer
Any trust layer worth the name has to answer three questions about a counterparty agent. Skip one and you're back to vibes.
Who is this? The identity question. A wallet address is not an identity — it's a pointer. The trust layer resolves that pointer against verifiable anchors: an ENS name, an ERC-8004 on-chain identity id, a TLS-served domain, or a verifiable EVM address with chain-of-control. The stronger the anchor, the higher the identity sub-score. A burner wallet with no reverse record gets near zero, and rightly so.
Can they actually do it? The capability question. A declared capability is a marketing claim until you check it. Our probe hits the agent's endpoint — bounded, time-boxed, polite — and verifies that the agent-card, MCP surface, or skill manifest is real, reachable, and matches what was declared. Mismatched claims tank the capability score. We built the probe to be aggressive about real reachability and conservative about reading too much into a 200 OK.
Have they done it before, and did it go well? The reputation question. In 2026, reputation is the hardest of the three, because most agents are young. We don't pretend otherwise. Today's reputation score is built from identity anchors and live signals — economic skin in the game, uptime, declared-vs-observed capability — not a deep historical registry. That's the honest answer. A full on-chain reputation ledger is on our roadmap, not in this release.
Bundling all three into one 0-100 number is what makes it a trust layer for AI agents instead of three separate lookups you'd forget to run. One call, one verdict, one signed report. If you want the raw inputs, they're in the response. If you only want the recommendation, that's there too. The verification primitives are documented in EVIDIQ docs.
What a Trust Layer Is Not
Some things need to be said bluntly, because the category is full of companies calling themselves trust infrastructure while quietly being something narrower.
- Not an escrow. EVIDIQ never holds funds. We have no custody, no multisig, no ability to freeze or release money. If the recommendation is
proceed_with_escrow, that's our advice to you — and you pick the escrow provider. - Not a KYC provider. We do not verify humans behind agents. We're not a regulated identity bureau, and we don't pretend to be one. Compliance certifications (EU AI Act, AML) are roadmap work, not a shipped feature.
- Not a guarantee. A trust score of 95 is not a promise that nothing will go wrong. It's a probability-weighted read on the inputs we could see, signed and timestamped, that you can show to a counterparty or a judge later.
What we do produce is evidence — anchored on 0G Storage, signed with the EVIDIQ key, hashable by anyone. Evidence is the thing you actually need when something goes wrong. Promises are what you wanted when it was too late to collect them. We chose evidence.
The notarization layer that signs and anchors each report is itself a separate module — the EVIDIQ Notary docs walk through exactly how the keccak256 canonicalization, the 0G Storage tx, and the EIP-191 signature fit together. If you're integrating this into a high-value workflow, start there.
