EVIDIQ: The Trust Layer for AI Agents Before Money Moves

It's 3 AM. An autonomous agent you registered an hour ago tries to spend USDT0 on your behalf, and the only thing standing between that transaction and an address you cannot read is a single request. That request is the difference between a working agent economy and an expensive mistake. EVIDIQ is the trust layer for AI agents that turns that request into something you can actually defend in a postmortem.

Before money moves, keep the decision sequence simple:

1. Ask EVIDIQ to verify the counterparty's identity, live endpoint, and declared capabilities.
2. Read the signed score, recommendation, and evidence rather than treating a successful HTTP response as approval.
3. Match the settlement protection to the result: proceed, use escrow, or stop.

What Is a Trust Layer for AI Agents?

A trust layer for AI agents is a protocol-level service that, before value moves, verifies who an agent is, what it claims to do, and what its history looks like, then returns a single explainable score. EVIDIQ plays this role: it takes a cold request and returns a 0–100 score with a signed verdict — proceed, proceed_with_escrow, caution, or do_not_proceed.

The point isn't to be the agent's identity, payments, or compute layer. It's the thin attestation layer that sits next to them — the one that lets a buyer, a wallet, or a parent agent say "yes, this much, with these warnings" before signing. Try to send value without it in 2026 and you're gambling on vibes, not evidence.

One Call, Start to Finish

Let's walk a literal request. Imagine a freshly registered agent named Lyra-7 at address 0x91b7...4e2A, advertising itself as a legal-translation service at https://lyra-7.example/agent.json. Your orchestrator wants to send it 4 USDT0 to translate a 600-word contract into Japanese. Before settling, it calls verify_agent.

Step 1. Your code calls EVIDIQ's remote MCP server at https://evidiq.dev/mcp. The JSON-RPC body is small enough to hand-write:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "verify_agent",
    "arguments": {
      "agent": "lyra-7.example",
      "address": "0x91b7F3c8d2E4aB91b7F3c8d2E4aB91b7F3c8d2E4aB91",
      "endpoint": "https://lyra-7.example/agent.json",
      "declared_capabilities": ["translation.legal", "x402.invoice", "json_schema.strict"]
    }
  },
  "id": 1
}

Step 2. If you haven't paid yet, EVIDIQ responds with HTTP 402 and an x402 v2 challenge: scheme exact, network x-layer, asset USDT0, amount quoted in accepts[].amount. Your client signs an EIP-3009 transferWithAuthorization message off-chain and replays the same request with the X-PAYMENT header attached. Settlement happens on X Layer in seconds.

Step 3. Once paid, EVIDIQ runs the actual verification. It resolves the domain, validates TLS, and issues a bounded ~6s GET against Lyra-7's endpoint — checking reachability, certificate validity, and whether the response actually contains a machine-readable skill surface (an agent-card, MCP manifest, or a compatible skill.md). It cross-references the on-chain address against any ERC-8004 identity id, ENS name, or domain it can find. Then it computes the trust score: identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. Each input is observable; nothing is hidden behind a black box.

Step 4. The final report is canonicalized, hashed with keccak256, and the hash is anchored on 0G Storage mainnet — that returns an on-chain transaction receipt. An optional AI risk analysis can run on 0G Compute with GLM-5.2 inside a TEE; we record the provider address and request id so the inference itself is auditable. The verdict is signed with the EVIDIQ key using EIP-191.

What you get back isn't just a number. It's the raw inputs, the explainable score, the signed receipt, and the Storage receipt — ready to attach to a postmortem, to a dispute, or to your own internal risk dashboard.

The Three Questions Every Trust Layer Has to Answer

Strip the architecture diagrams away and there's really only one job: answer three yes/no questions, fast, and with evidence you can show.

• Who is this? (identity) — Is the address verifiable on-chain? Is there an ERC-8004 identity id behind it? An ENS name? A TLS-served domain? Identity scoring rewards all four signals; missing all four isn't fatal (a brand-new agent may legitimately have none), but it caps the sub-score. Lyra-7 can lie about its name in its agent.json, but it can't fake the cryptographic linkage between its name, its endpoint, and its signing key without also forging the probe result.
• Can they actually do it? (capability) — Does the endpoint respond with the skill surface Lyra-7 claims? Capability scoring is half declared and half observed: EVIDIQ weights self-declared capabilities and then cross-checks them against the live probe. A declared-capability score of 60 with no live probe result is materially worse than a score of 50 with one.
• Have they done it before? (reputation) — Scored today from identity anchors and live signals — most importantly whether the endpoint runs a paid x402 service, i.e. "economic skin in the game." A full historical reputation ledger isn't shipped yet; we're building it on the roadmap, openly.

Bundling all three into one explainable score beats checking any one alone. Identity-only checks let you transact with a brand-new scam running on a clean address. Capability-only checks let you transact with a polished demo that has never settled a single job. Reputation-only checks let you transact with a formerly-good agent whose endpoint has been parked and put up for sale by a stranger. The intersection is where the actual signal lives, and that intersection is what a trust layer exists to surface.

We designed the scoring formula to be deterministic on purpose. Same inputs, same score, every time, on every region. We didn't want a black box; we wanted something an auditor — yours, ours, or a regulator's — could replay byte-for-byte.

What a Trust Layer Is Not

This is the boundary we draw hardest, because it gets confused constantly as the agent stack consolidates.

• Not an escrow. EVIDIQ never holds funds. We will recommend proceed_with_escrow when risk is non-trivial, but the escrow itself is your problem to wire up using whatever custody, dispute, or refund rail fits your stack.
• Not a KYC or compliance provider. We're not certifying anyone against the EU AI Act or running AML checks. We're not a regulated entity, and we're not pretending to be one. If your use case requires regulator-grade onboarding or sanctions screening, you'll need a separate vendor upstream of us.
• Not a guarantee. A trust score is evidence and a recommendation, not a promise. Lyra-7 could still ship a bad translation tomorrow, and a malicious agent could still game the system for one verification before it gets flagged. What you get instead is rarer: a signed, reproducible artifact that says exactly what we saw, exactly when we saw it.

We've watched too many "trust" platforms quietly expand into taking custody, signing terms of service for users, or making refund decisions on behalf of buyers. We don't do any of that. You stay in charge of the policy. We hand you the receipts.