EVIDIQ Is the Trust Layer for AI Agents We Needed Yesterday

What Is a Trust Layer for AI Agents?

A trust layer for AI agents is the verification and attestation fabric that sits between an autonomous agent requesting work and the human or system about to grant it access, money, or data. EVIDIQ is exactly that — it verifies an agent's identity, declared capabilities, and reputation, then returns a deterministic 0-100 trust score with an explicit proceed/proceed_with_escrow/caution/do_not_proceed recommendation, all signed and anchored on-chain so the result is independently verifiable in 2026.

The agent economy in 2026 doesn't look like a chat app anymore. It looks like a marketplace of autonomous services: one agent books flights, another executes trades, a third scrapes and summarizes research, a fourth settles invoices. They find each other through x402 discovery, they pay each other in stablecoins, and increasingly, they negotiate terms without a human in the loop at all. Cool. Also terrifying.

Here's the thing: when an agent says "I am the Stripe-of-agents, my wallet is 0xAbc..., I can refund you via x402, and my endpoint is refunds.example/agent," how does the caller know that's true? It doesn't. It gets a string of claims and a wallet address and... vibes. That's the gap EVIDIQ was built to close. We built EVIDIQ because the rest of the stack — payments, compute, identity registries — only works if you can first prove the counterparty is who and what they say they are.

Think of the stack in layers. At the bottom you have compute — where the model runs (0G, Akash, your laptop). Above that, identity — ERC-8004 on-chain IDs, ENS names, TLS-served domains. Then payments — x402, EIP-3009 transferWithAuthorization, USDT0 on X Layer. The trust layer for AI agents sits perpendicular to all of these. It doesn't replace them. It reads them, probes them, and produces one auditable verdict you can act on.

One Call, Start to Finish

Let's pick a fictional agent — call it Atlas Refunds, wallet 0x9F3a...7c2B, served at atlas-refunds.example/agent. Your agent wants to send it $40 of work and is rightly nervous. You fire one call.

[IMAGE_PROMPT: A clean flat illustration showing two abstract robot-like hexagonal figures facing each other across a glowing vertical data pipeline. The left hexagon holds a glowing request envelope; the right hexagon presents a digital agent card. Between them, a vertical pipeline with three glowing checkpoint stages stacked top to bottom: probe, score, sign. Background includes faint blockchain ledger lines and subtle circuit-board traces. Color palette: deep slate background, teal primary shapes, amber accent highlights, soft gradients. No text in image. No real brand logos.]

The request is JSON-RPC over HTTPS to https://evidiq.dev/mcp, method verify_agent:

{
  "jsonrpc": "2.0",
  "id": "req_01HW...",
  "method": "verify_agent",
  "params": {
    "agent": {
      "address": "0x9F3a8C2e44d901bf23aB7c2B19Ef0c1a8E47f3c2",
      "endpoint": "https://atlas-refunds.example/agent",
      "declared_capabilities": [
        "process_refund",
        "x402_settlement",
        "read_order_history"
      ]
    },
    "context": {
      "task": "issue_refund",
      "value_usd": 40
    }
  }
}

If you haven't paid yet, the server replies with HTTP 402 and a payment challenge — x402 v2, scheme exact, amount 200000 (that's $0.20 in USDT0's 6-decimal units on X Layer), asset USDT0, payTo 0xEVID...PAY. Your client signs an EIP-3009 transferWithAuthorization and retries the same RPC, this time with the X-PAYMENT header attached. The whole paid round-trip typically lands in under eight seconds including the probe.

What happens on our side, fast:

• Identity probe — does 0x9F3a... resolve to an ENS name? An ERC-8004 identity contract entry? A TLS-served domain matching? Each anchor scores independently and contributes to identity.
• Capability probe — we issue a bounded ~6 second GET to atlas-refunds.example/agent, check reachability, TLS validity, and whether the response is a machine-readable skill file, agent card, or MCP surface. We also confirm process_refund is actually advertised there, not just claimed in your RPC payload.
• Reputation & risk — does the endpoint already run a paid x402 service? That's "economic skin in the game," the closest thing to reputation we have today. Risk weighs declared capability vs. probed capability, value at stake, and a few sanity checks.

The formula is plain and published: score = identity*0.3 + capability*0.3 + reputation*0.2 + (100 - risk)*0.2. Deterministic. Same inputs, same score, every time. We publish the formula deliberately — a black-box trust score is useless to anyone writing automation around it.

For Atlas Refunds you get something like:

{
  "score": 78,
  "recommendation": "proceed_with_escrow",
  "breakdown": {
    "identity": 90,
    "capability": 80,
    "reputation": 60,
    "risk": 25
  },
  "evidence_hash": "0x4f2c...",
  "report_uri": "evidiq.dev/report/0x4f2c...",
  "signature": "0x91ab..."
}

The evidence — the raw probe logs, the canonical JSON, the scores — gets hashed (keccak256), anchored on 0G Storage mainnet (an on-chain tx you can verify), and the verdict itself is signed with our EIP-191 key. Anyone can re-fetch the evidence, re-hash it, and recover the signer. That's the design. We don't want you to take our word for it — we want you to verify it. Full lifecycle details live in the EVIDIQ docs.

The Three Questions Every Trust Layer Has to Answer

If you've ever lost money to a sketchy counterparty, you already know the three questions. A trust layer for AI agents exists to answer them in one call, in a way a machine can act on:

1. Who is this? Identity — the agent's address, ENS, ERC-8004 id, TLS domain. Without an anchor, the rest of the score is sand.
2. Can they actually do it? Capability — do they advertise process_refund, and did our probe find a working skill endpoint? Declared capability with zero probe is theater.
3. Have they done it before, and did it go well? Reputation — economic skin in the game today, on-chain attestation history as the registry matures.

Why bundle them? Because in practice you can't separate them. A high-identity, low-capability agent is a fake. A high-capability, low-identity agent is an anonymous ghost that you'll never sue. Reputation without identity is folklore. Any single dimension can be spoofed; the joint signal is much harder to game. Plenty of attackers ace identity (free ENS) and fail capability (no live endpoint) — the joint score catches what isolated checks miss. The breakdown in every report shows exactly where the weakness is.

What a Trust Layer Is Not

We get this question a lot, so let's be direct. EVIDIQ is not:

• Not an escrow. We never hold funds. The parties in the transaction decide whether to settle directly, route through an escrow, or attach dispute rights. Our recommendation might be proceed_with_escrow — that's a hint, not a service.
• Not a KYC / AML provider. We don't know who's behind the wallet. We're not certified for EU AI Act compliance or financial regulation, and we won't pretend otherwise in 2026. Identity here means cryptographic anchors, not passport scans.
• Not a guarantee. A proceed recommendation is evidence-based, not a warranty. If the agent turns out to be a rug, our signed report is part of your evidence trail — it doesn't refund you.
• Not a smart-contract reputation registry yet. Reputation today is built from identity anchors and live signals. A full historical ledger with automated dispute resolution is on the roadmap, but we won't ship it as a feature until it's a feature.

[IMAGE_PROMPT: A minimalist flat illustration showing a large magnifying glass inspecting a stack of three layered translucent shields, each shield subtly tinted differently and stamped with a small abstract glyph representing identity, capability, and reputation. Behind the shields, a faded wallet icon hovers with a soft question mark, suggesting the idea of inspect-don't-hold. Slate background, teal and amber accents, soft gradients. No text in image. No real brand logos.]

The boundary matters because the moment we overpromise, the score stops being trustworthy. EVIDIQ hands you evidence and a recommendation — you choose your own protection. Holding that line is what makes EVIDIQ a real trust layer for AI agents and not a marketing slide. The full architectural split between caller-side orchestration and our attestation service is documented in the EVIDIQ Operator docs, and the actual probe and signing pipeline is in the EVIDIQ Sentinel docs.