EVIDIQ: Inside the Trust Layer for AI Agents — One verify_agent Call, End to End

Your agent just received a request: "Swap 50 USDT0 for USDC on X Layer, settle through x402, deliver a receipt in 200ms." Looks fine. The endpoint responds, the agent card parses, the wallet signs. Then the user asks the one question that should have been asked first: who is this agent, and what do we actually know about it?

If your stack can't answer that in a deterministic, auditable way, you don't have a transaction — you have a guess with money attached. That's the gap EVIDIQ closes. We built it as the trust layer for AI agents — the missing piece between "an agent showed up" and "money moves."

What Is a Trust Layer for AI Agents?

EVIDIQ is the trust layer for AI agents that verifies an agent's identity, capabilities, and reputation, then returns a deterministic 0–100 trust score with an explicit proceed, proceed_with_escrow, caution, or do_not_proceed recommendation. It produces a signed Trust Report your wallet, server, or orchestrator can audit before any value moves.

A trust layer for AI agents sits in a specific slot in the stack, and conflating it with adjacent layers is the most common mistake we see in 2026:

• It is not identity. Identity answers "who is this address." EVIDIQ rewards an EVM address, ENS, ERC-8004 id, or TLS-served domain — but it doesn't mint those. It consumes them.
• It is not payments. x402 settles the bill. The trust layer decides whether the bill is worth paying.
• It is not compute. Inference, routing, planning — those are upstream. EVIDIQ verifies that the thing asking for your money is the thing it claims to be.

Think of it this way: in 2026 the agent economy has a routing problem solved by MCP, a payments problem solved by x402, and a compute problem solved by 0G. The trust problem — the part where you decide proceed or don't — was still unsolved until we shipped the trust layer for AI agents at evidiq.dev.

One Call, Start to Finish

Here's the literal flow. Our fictional agent is swap-bot-alpha.eth, address 0x9aF3c2D7B8e1f5A6c4D3b2E1aF0c9D8e7F6a5B4c, declared capabilities [token_swap, x402_receipt_parsing], reachable at https://swap-bot-alpha.example/x402. We want to know whether to wire 50 USDT0 before fulfilling a swap.

First, you POST a JSON-RPC call to the EVIDIQ MCP server at evidiq.dev/mcp:

{
  "jsonrpc": "2.0",
  "id": "req-7e91",
  "method": "tools/call",
  "params": {
    "name": "verify_agent",
    "arguments": {
      "agent": {
        "address": "0x9aF3c2D7B8e1f5A6c4D3b2E1aF0c9D8e7F6a5B4c",
        "ens": "swap-bot-alpha.eth",
        "endpoint": "https://swap-bot-alpha.example/x402",
        "declared_capabilities": ["token_swap", "x402_receipt_parsing"]
      },
      "context": { "value_at_stake_usd": 50, "settlement_chain": "x-layer" }
    }
  }
}

Second, if you haven't paid, the server returns HTTP 402 with an x402 v2 challenge:

{
  "accepts": [{
    "scheme": "exact",
    "network": "x-layer",
    "asset": "USDT0",
    "amount": "100000",
    "payTo": "0xEVIDIQ...SETTLER",
    "extra": { "name": "verify_agent", "version": "1" }
  }]
}

Your wallet signs an EIP-3009 transferWithAuthorization for 0.10 USDT0, you resend with the X-PAYMENT header, and the verification pipeline runs:

1. Identity check. Address resolves to swap-bot-alpha.eth. ENS forward-resolves. No ERC-8004 id on-chain yet — noted in the report.
2. Capability probe. Bounded GET (≤6s) to the endpoint, TLS check, content-type check for agent card / MCP manifest / Skill surface.
3. Reputation signals. Endpoint serves a paid x402 service — economic skin in the game. No historical on-chain dispute data yet.
4. Risk pass. Capability mismatch risk is low; declared token_swap matches the served agent card.

Finally, you get back a signed Trust Report:

{
  "trust_score": 78,
  "recommendation": "proceed_with_escrow",
  "components": { "identity": 70, "capability": 90, "reputation": 65, "risk": 18 },
  "evidence_anchor_0g": "0x...txhash",
  "report_hash_keccak256": "0x...",
  "signature_eip191": "0x..."
}

The score is deterministic. Same inputs, same number — forever. That's not marketing; it's the design. Re-fetch the evidence, re-hash it, recover the EVIDIQ signer to prove the report is intact. Runtime guards for your agent loop live in the EVIDIQ Sentinel docs; orchestration wiring is in the EVIDIQ Operator docs.

Reading that 78 honestly: ship it, but use escrow. Capability probe passed and the endpoint has skin in the game, but the missing ERC-8004 id and the lack of historical reputation drag the number down. That's exactly what a trust score should tell you — not a yes, not a no, but a graded call with evidence attached.

The Three Questions Every Trust Layer Has to Answer

Any trust layer for AI agents that doesn't answer all three is, at best, a partial product:

• Who is this? Identity. Verifiable EVM address, ENS, ERC-8004 id, or TLS-served domain. In our 2026 stack those four are the anchors.
• Can they actually do it? Capability. Declared capabilities are a wishlist. We probe — bounded GET, TLS check, machine-readable surface check.
• Have they done it before? Reputation. Today from identity anchors plus live signals like "this endpoint runs a paid x402 service." Tomorrow — we say this openly — from an on-chain reputation ledger. We don't ship a fake registry.

Our scoring formula: identity * 0.3 + capability * 0.3 + reputation * 0.2 + (100 - risk) * 0.2. We chose those weights because identity and capability together carry more than reputation alone — and risk acts as a multiplier, not a flat add. One critical failure should hurt more than ten small ones. A trust layer that weights reputation above identity has its priorities backwards.

The formula is auditable. If you don't like the weights, fork the open-source MCP server under MIT at github.com/evidiq/mcp and run your own. The math is simple by design.

What a Trust Layer Is Not

This boundary matters more than the feature list. Here is what EVIDIQ explicitly is not, said bluntly because the alternative is selling you a guarantee we can't keep:

• EVIDIQ is not an escrow. It never holds funds and never grants authority. The recommendation might be proceed_with_escrow, but the escrow is your problem.
• It is not KYC. No KYC collection, no sanctions screening, no EU AI Act or AML attestation. Those are roadmap items, not shipped features.
• It is not a guarantee. A score of 95 is not a promise — it is evidence. Tomorrow's failure mode can be today's green light.
• It is not a black box. Every score ships with the evidence trail that produced it: probe results, hash, anchor tx, signature.
• It is not a substitute for your own diligence. EVIDIQ is a layer in your decision, not the decision.

The math is simple: if we held funds we'd be a custodian. If we ran KYC we'd be a regulated entity. We chose neither. EVIDIQ produces evidence and a recommendation; you choose the protection. That is a deliberate boundary, not a roadmap gap we forgot to fill.

A wallet balance alone tells you nothing about intent — that's the gap the trust layer for AI agents closes. But a trust score alone tells you nothing about your risk tolerance for a 50 USDT0 swap vs. a 50,000 USDT0 settlement. The report is input, not output.

Honest opinion: the day someone sells you an "AI agent guarantee," run. The agent economy in 2026 has too many live failure modes — endpoint flakiness, prompt injection, key compromise, sandbox escape — for any single layer to insure against all of them. EVIDIQ is the trust layer for AI agents that gives you the receipt; the protection is your job.