EVIDIQ: The Trust Layer for AI Agents Before Money Moves

Your agent just got a job offer from another agent. Maybe it's a swap routing job for $4,200 USDC. Maybe it's a data-aggregation task worth $80. Maybe it's nothing — just a "hello, please call my MCP server." Every one of those moments has the same question hiding inside it: can you actually trust this counterparty?

In 2026, that question is the bottleneck. Agents are signing deals, paying for endpoints, and chaining tool calls at machine speed. The rails underneath them — x402 payments, EVM settlement, MCP servers — are all real and production-ready. What's missing is the layer that says "yes, this one is who they say they are, and they've put something on the line."

That's the gap we built EVIDIQ to close.

What Is a Trust Layer for AI Agents?

A trust layer for AI agents is the infrastructure between an agent receiving a task and acting on it. EVIDIQ is a deterministic scoring service that verifies identity, declared capabilities, and live reputation signals, then returns a 0–100 trust score with an explicit recommendation. Delivered via the open Agent Skill and remote MCP server, it produces signed, tamper-evident Trust Reports any party can audit.

That's the one-paragraph version. Now let's pull it apart, because the distinction matters more than the definition.

The trust layer for AI agents is not the same as an identity layer, even though identity is one of its inputs. It is not the same as the payments layer — EVIDIQ settles in USDT0 on X Layer via x402, but it never holds funds and never authorizes a transfer. It is not compute, storage, or orchestration. Think of it like a credit bureau for non-human counterparties: you bring the question, we hand back a number, a recommendation, and a signed receipt. The decision is still yours.

Why this layer has to exist at all is brutal in its simplicity. A wallet balance tells you nothing about intent. A domain name tells you nothing about whether the endpoint actually serves what it advertises. An on-chain history tells you nothing about whether the operator behind the key is honest today. You can verify any single dimension. None of them, alone, is enough.

One Call, Start to Finish

Here's what actually happens when your agent hits our MCP server with verify_agent. We'll trace one request, end to end, against a fictional counterparty — let's call it solver.arb.gamma.eth at 0x9aF3c2D7e1B8c4E0a5F6b3D2c1A0e9F8D7c6B5a4.

Your agent sends a JSON-RPC request over HTTPS:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "verify_agent",
    "arguments": {
      "agent_id": "eip155:1:0x9aF3c2D7e1B8c4E0a5F6b3D2c1A0e9F8D7c6B5a4",
      "declared_capabilities": ["x402-routing", "evm-quote", "mev-protection"],
      "endpoint": "https://solver.arb.gamma.eth/.well-known/agent-card.json"
    }
  }
}

If you've never paid for a call before, you don't get a score. You get an HTTP 402, x402 v2 style:

{
  "accepts": [{
    "scheme": "exact",
    "network": "x-layer",
    "resource": "/verify_agent",
    "amount": "50000",
    "asset": "USDT0",
    "payTo": "0xEV1D...Q"
  }]
}

The agent pays — transferWithAuthorization, EIP-3009, no gas UX to worry about — and resubmits the same request with an X-PAYMENT header carrying the signed authorization. From here on it's our problem.

We look up the identity anchor. The address has an ENS reverse resolution to solver.arb.gamma.eth — that's worth something. There's no ERC-8004 identity id on-chain yet, so the identity component leans on ENS plus the cryptographic ownership of the EVM address itself. Capability scoring starts with what the agent declared, then we run a live probe: a bounded ~6-second GET to https://solver.arb.gamma.eth/.well-known/agent-card.json, checking TLS validity, reachability, and whether the response actually parses as a machine-readable agent card or MCP surface.

Reputation is where we get opinionated. Today, our reputation component scores from identity anchors plus live economic signals — most importantly, does this endpoint actually run a paid x402 service? That single check catches a startling number of impersonators, because running a real paying endpoint means "skin in the game" in a way a freshly generated address never does. We don't yet have a full on-chain historical reputation ledger — that's roadmap work, and the EVIDIQ docs say so plainly.

Risk is the inverse side of the same coin: known scam-report feeds, malformed or unreachable endpoints, declared capabilities that contradict each other. Risk can drag a perfectly identified agent down to a caution recommendation if something smells off.

Our scoring formula is auditable by design:

score = identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2

For our fictional solver.arb.gamma.eth, suppose identity = 72, capability = 88, reputation = 60, risk = 18. That's 21.6 + 26.4 + 12 + 16.4 = 76.4 — a Trust Score of 76, recommendation proceed_with_escrow. Same inputs tomorrow, same score. No model drift, no nightly retraining, no surprises.

What you get back is a signed Trust Report — the score, the breakdown, the raw evidence, the timestamp, and the EVIDIQ signer's address. The canonical JSON gets hashed with keccak256, the hash anchored on 0G Storage mainnet with a real on-chain tx receipt, and the verdict signed under EIP-191. Anyone can re-fetch the evidence, re-hash it, and recover the signer. The full lifecycle for the notarization step is documented in the EVIDIQ Notary docs.

One call. Roughly two seconds. A signed receipt your agent can hand back to its own log, its human owner, or its downstream settlement layer.

The Three Questions Every Trust Layer Has to Answer

If you strip a trust layer for AI agents down to its skeleton, three questions have to be answered for every counterparty. EVIDIQ answers them in this exact order, every call:

1. Identity — who is this? Verified via a controlled EVM address, an ERC-8004 on-chain identity id when one exists, an ENS reverse record, or a TLS-served domain tied to the same operator. Without identity, the rest of the report is theatre.
2. Capability — can they do what they say? Declared capabilities are scored, then probed. We hit the endpoint, time-box it at ~6s, and check whether the response is real, reachable, and machine-readable. A claimed x402-routing capability on an endpoint that 404s is a zero, not a benefit of the doubt.
3. Reputation — have they done this before, and did it stick? This is where we earn our keep. Today, that means identity anchors plus live economic skin-in-the-game signals. Tomorrow it includes a fuller historical ledger.

The reason all three have to land in one number is straightforward: each one alone is gameable. Identity without capability lets a well-funded scam operator pretend to be anything. Capability without reputation lets a fly-by-night endpoint pass one probe and disappear. Reputation without identity is vanity — a star rating attached to a name that means nothing. Bundled, they check each other. A 90-capability, 12-identity score is shouting "look at me" for a reason, and the formula hears it.

This is also why we deliberately did not build a single ML-based "trust model." Deterministic beats clever when the receipt has to hold up in a dispute or an audit. The math is simple, the math is public, and the math is the same at 3am as it is during a market crash.

What a Trust Layer Is Not

Beating the boundary drum matters as much as describing what's inside.

• Escrow: no. We never hold funds. We never authorize a release. If your report says proceed_with_escrow, that means you should use an escrow — your choice of one, with your choice of terms.
• KYC or compliance: also no. We don't run AML, we don't certify against the EU AI Act, and we don't collect passports. Identity anchors are technical, not legal.
• A guarantee: definitely no. A Trust Score of 95 is not a promise the counterparty will behave. It's the highest-confidence evidence our formula can produce from public signals. Bad actors still exist; we make them expensive to impersonate, not impossible to exist.
• A black-box reputation oracle: no. There is no hidden model. Every component is explainable, every weight is published, every input is part of the returned report.

Honest moment: this boundary is the part most people want us to cross. "Just hold the funds." "Just insure it." "Just be the regulator." No. We are evidence, signed and timestamped. The parties choose what to do with it — settle direct, route through an escrow, attach dispute rights, refuse outright. That separation is what keeps the layer trustable in the first place. A trust layer for AI agents that could itself seize funds or block counterparties would just be a different kind of counterparty risk.

One practical consequence: because we never custody anything, our payments model is also honest. Each verify_agent call costs USDT0 via x402. The Agent Skill and the install tools (how_to_install, get_evidiq_skill) are free and MIT-licensed at github.com/evidiq/mcp. Pay only when you actually want a score.