EVIDIQ: The Trust Layer for AI Agents Before Money Moves

Your agent just got a signed offer to settle a $4,200 invoice on X Layer. The counterparty's address looks fine. The 402 challenge is clean. Everything checks out — until you ask the one question nobody encoded in the request: who is this thing, really?

That's the gap. EVIDIQ exists to close it. We built it because, in 2026, AI agents are moving real money against each other with nothing more than a wallet address and a smile, and the tooling to ask "should I trust this counterparty?" is years behind the tooling to actually pay them. This post is a walk through what EVIDIQ does, how a single verify_agent call actually flows, and where the boundary sits — because we think the boundary matters as much as the feature.

What Is a Trust Layer for AI Agents?

A trust layer for AI agents is infrastructure that takes a raw counterparty — an address, a domain, or a capability list — and returns a single auditable verdict a downstream agent can act on. EVIDIQ is exactly that: it verifies identity, probes claimed capabilities, and returns a deterministic 0–100 trust score with an explicit recommendation in one signed report.

That definition is the spine of everything else. A trust layer is not the same as the layers it sits next to, and we find most confusion in 2026 comes from collapsing them. The identity layer (ERC-8004, ENS, on-chain attestations) tells you who claims to be at a key. The payments layer (x402, transferWithAuthorization, the 402 challenge) tells you how value moves once you've decided. The compute layer (0G Compute, TEEs, model providers) tells you where the inference ran. The trust layer for AI agents is the missing connective tissue: it reads from those other layers, weighs them, and hands the calling agent a single decision it doesn't have to recompute.

Concretely, EVIDIQ is delivered three ways: an open Agent Skill at evidiq.dev/skill.md, a remote MCP server at evidiq.dev/mcp with free install helpers and a paid verify_agent tool, and a discovery endpoint at evidiq.dev/x402. You call it. It gives you a number, a verdict, and a receipt. The whole contract is small on purpose.

One Call, Start to Finish

Let's make this concrete. Say your agent, Treasury-1, is considering a deal with a counterparty it found through a discovery feed: an agent called Nimbus Treasury Agent, claiming to settle USDT0 invoices for SaaS vendors on X Layer. The address is 0x9c4E…7A21. No prior relationship. No history.

Treasury-1 makes one MCP call. Here's the request, simplified:

{
  "jsonrpc": "2.0",
  "id": "tv-9921",
  "method": "tools/call",
  "params": {
    "name": "verify_agent",
    "arguments": {
      "address": "0x9c4E…7A21",
      "chain": "x-layer",
      "declared_capabilities": ["usdt0_settlement", "invoice_discounting"],
      "endpoint": "https://nimbus-agent.example/.well-known/agent-card.json"
    }
  }
}

What happens next is the part nobody shows. EVIDIQ's MCP server, before it does any work, returns a 402 Payment Required. This isn't a failure — it's the protocol. The response carries the x402 challenge: scheme exact, network x-layer, asset USDT0, and an accepts array with the per-call price. Treasury-1 signs an EIP-3009 transferWithAuthorization for the micro-amount, retries the request, and now the work actually runs.

[IMAGE_PROMPT: A clean modern flat illustration depicting a single request flowing left-to-right through a labeled pipeline of stages: '402 challenge', 'signed payment', 'identity probe', 'capability probe', 'score computation', 'signed report'. The aesthetic is developer-diagrammatic with a soft pastel palette of slate, mint, and amber, thin connecting lines between geometric stage icons (a 402 card, a key, a probe needle, a calculator, a signed document), no real brand logos, no people, no text other than the stage labels in a clean sans-serif font.]

Inside the call, EVIDIQ runs four checks in parallel and combines them:

1. Identity anchors for 0x9c4E…7A21 — verified EOA, ERC-8004 on-chain id, ENS reverse, domain-to-address TLS resolution.
2. Capability probe against the declared endpoint with a bounded ~6 second GET to confirm reachability, TLS health, and whether the URL serves a machine-readable agent card, MCP manifest, or Skill file.
3. Economic-skin check — does the endpoint itself run a paid x402 service? An agent that accepts money is structurally different from one that only spends it.
4. Risk signals — chain heuristics, declared capability mismatches, and known-bad lists applied to the address and the endpoint.

The output, returned to Treasury-1, looks like this:

{
  "report_id": "rep_8f3c1a2b",
  "subject": "0x9c4E…7A21",
  "score": 72,
  "verdict": "proceed_with_escrow",
  "components": {
    "identity": 85,
    "capability": 70,
    "reputation": 55,
    "risk": 80
  },
  "evidence_anchors": [
    "erc8004:0x9c4E…7A21#7421",
    "tls:nimbus-agent.example",
    "x402_endpoint:paid"
  ],
  "report_hash": "keccak256:0xab12…ff",
  "evidence_tx": "0g:mainnet:0x77e2…9c1d",
  "signature": "0x...",
  "signer": "evidiq"
}

That score: 72 and verdict: proceed_with_escrow is the part Treasury-1 actually uses to decide. The signature is what makes the report auditable downstream — anyone can re-fetch the evidence, re-hash it, and recover the EVIDIQ signer key per EIP-191. We hash the canonical report with keccak256, anchor the evidence blob on 0G Storage mainnet, and the report is bound to a specific on-chain tx. If the evidence ever changes, the hash breaks.

The anchoring flow is documented in the EVIDIQ Notary docs if you want the receipts behind the receipts.

The Three Questions Every Trust Layer Has to Answer

Beneath the API surface, every trust layer has to commit to answering three questions, and committing to all three together is what makes the layer a layer instead of just another oracle:

• Identity — "Who is this?" A key alone is not an identity. A trust layer has to weight verifiable anchors: an EVM address with a transaction history, an ERC-8004 on-chain id, an ENS name, or a TLS-served domain that resolves back to the address. The more of these reconcile, the higher the identity score climbs.
• Capability — "Can they actually do what they claim?" This is the live-probe half. Declared capabilities are cheap; we treat them as a starting point, not a conclusion. The bounded endpoint probe is what separates a real service from a parked domain. We built EVIDIQ's probe to fail closed — if the agent card doesn't parse, capability takes the hit, not the score average.
• Reputation — "Have they done it before, and what happened?" This is the part we are most explicit about. Today, reputation in EVIDIQ is computed from identity anchors and live economic signals (e.g. the endpoint accepts x402 payments — that is skin in the game), not from a full historical on-chain reputation registry. We don't pretend otherwise. A complete dispute and reputation ledger is a roadmap item, not a shipped feature, and we'd rather say so than fake a score.

Why bundle all three into one number? Because checking any one in isolation is the trap. An address with no capabilities probed is just a wallet balance — and a wallet balance tells you nothing about intent. An endpoint that pings cleanly is just a server — plenty of those serve scams. The point of a trust layer for AI agents is that the combination is what produces a defensible decision. Same inputs, same score, every time, every caller.

Our scoring formula is published in the EVIDIQ docs and is intentionally boring math:

• final = identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2
• final is clamped to 0–100, then mapped to a verdict: ≥80 proceed, 60–79 proceed_with_escrow, 40–59 caution, below 40 do_not_proceed.
• Same inputs always produce the same score. No model jitter. No "vibe-based" rounding.

That determinism is the design choice we are most willing to defend. AI agents writing code, posting collateral, and routing invoices cannot rely on a black-box number. They have to be able to log the inputs, replay the formula, and explain the verdict to whoever audits them next. EVIDIQ's score is auditable by construction — that is the entire point of the signed report.

What a Trust Layer Is Not

Here's where we draw the line, because agents in 2026 are going to be pitched a lot of "trust" things that aren't.

EVIDIQ is not an escrow. We never hold funds. We never have custody. The x402 payment is a per-call micro-fee to the MCP server for the verification work; it is not a deposit against your counterparty's behavior. If you want escrow, use an actual escrow contract — there are good ones on X Layer — and let EVIDIQ's verdict be the signal that tells you whether to bother.

We are not a KYC provider. We do not collect real-world identity documents, do not run sanctions screening against named individuals, and do not hold any PII. The identity side of our score is anchor-based (keys, ENS, domains, on-chain ids), not documentary. If your regulator wants a KYC trail, that is a different product from a different vendor, and conflating the two helps nobody.

EVIDIQ is not a guarantee. A proceed verdict is a probability, not a promise. The signed report is evidence that we ran the checks we said we'd run, on the inputs we received, at the time we ran them. What the counterparty does with that information afterwards is on the calling agent. We hand you evidence, not a promise. The EVIDIQ Sentinel docs explain how the live probe stays bounded and how risk signals decay; the EVIDIQ Operator docs cover how to run the MCP server yourself if you want zero dependence on our hosted tier.

The blunt version: a trust layer for AI agents is a better decision input, not a substitute for a decision. Anyone marketing a trust layer as a guarantee is selling you a lawsuit magnet. We're selling a number and a receipt.

[IMAGE_PROMPT: A modern flat illustration showing three contrasting pairs of icons side by side, each pair split by a vertical dotted line. Pair 1: a stack of coins (escrow) on the left vs. a magnifying glass over an address (verification) on the right. Pair 2: an ID card (KYC) on the left vs. a chain of cryptographic anchors on the right. Pair 3: a handshake (guarantee) on the left vs. a signed document with a numeric score on the right. The aesthetic is editorial-tech with a muted palette of indigo, coral, and cream, geometric shapes, no real brand logos, no human faces.]