Picture this: your agent just received a quote from another agent over x402. The price looks fair. The endpoint answered. So you authorize the payment.
Then the counterparty ghosts — or, worse, the "counterparty" was never an agent at all, just a 402-shaped script that minted invoices forever and walked away.
In 2026, agents move real money on behalf of real users, often across chains and counterparties they have never met. The question every builder is now asking isn't "can my agent pay?" — it's "is the agent on the other end real, capable, and worth paying?"
That's the whole reason we built EVIDIQ. We call it a trust layer for AI agents, and once you see what one call actually does, you'll understand why payments alone aren't enough.
What Is a Trust Layer for AI Agents?
A trust layer for AI agents is infrastructure that scores how reliable an autonomous agent is before any value moves between it and another party. EVIDIQ is a trust layer for AI agents: it verifies identity, capability, and reputation, then returns a 0–100 deterministic score with a signed Trust Report. Built for x402 payments.
Every modern agent stack has layers. You've got the identity layer — ENS names, ERC-8004 identity ids, EVM addresses. You've got the payments layer — x402, EIP-3009 transferWithAuthorization, settled on a chain. You've got the compute layer — TEE inference, models like GLM running inside attested sandboxes.
Each of those is necessary. None of them tells you whether to trust the counterparty.
That's the gap. Identity tells you a key exists. Payments tell you money moved. Compute tells you a model produced an answer. None of them answer whether the agent on the other end is what it claims to be, can actually do what it advertises, and has any reason not to rip you off.
A trust layer sits above (or beside) all three. It pulls signals from each — an address, an endpoint, a payment-accepting service, a declared capability list — and turns them into a single decision a builder can act on. In our case, that decision is a number from 0 to 100 plus a recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed.
The worth-noticing part: the score is deterministic. Same inputs, same score, every time. Anyone can re-run the scoring and recover the same number. It's not a vibe — it's an audit trail with a cryptographic signature attached.
One Call, Start to Finish
Enough framing. Here's what an actual integration looks like against the EVIDIQ MCP server, start to finish.
Say your agent is considering a job from a counterparty that calls itself YieldPilot. It advertises itself at https://yieldpilot.example/.well-known/agent-card.json and the only handle you've been given is an EVM address: 0x4b9C8e7A3F2D1b6E5a17Dc9F8e2B4A6c8d0e2f4A. No history. No reputation. No reason to assume good faith.
Your agent issues a single MCP JSON-RPC call:
POST https://evidiq.dev/mcp
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": "yieldpilot-check-001",
"method": "tools/call",
"params": {
"name": "verify_agent",
"arguments": {
"agent": "0x4b9C8e7A3F2D1b6E5a17Dc9F8e2B4A6c8d0e2f4A",
"endpoint": "https://yieldpilot.example/.well-known/agent-card.json",
"declared_capabilities": ["x402-acceptor", "swap-quoter"],
"context": "evaluating inbound quote for 500 USDT0 of rebalancing work"
}
}
}
First response — before you've paid:
HTTP/1.1 402 Payment Required
x402-version: 2
WWW-Authenticate: x402 scheme="exact",
network="x-layer",
accepts=[{ asset="USDT0", amount="100000", payTo="0xEVID...abc", extra="{nonce:...}"}]
That 402 is the price of admission. verify_agent is paid per call — a fraction of a cent of USDT0, settled on X Layer via an EIP-3009 transferWithAuthorization. Your agent signs the authorization with its own key and replays the same JSON-RPC body with an X-PAYMENT header attached.
Second response — with payment:
HTTP/1.1 200 OK
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": "yieldpilot-check-001",
"result": {
"score": 41,
"recommendation": "caution",
"subscores": {
"identity": 65,
"capability": 70,
"reputation": 8,
"risk": 82
},
"summary": "Address verifiable on EVM; agent-card served and parses; no completed x402 flow history; declared vs probed mismatch on 'swap-quoter'.",
"evidence_uri": "https://evidiq.dev/reports/0x9f...c2",
"evidence_hash": "keccak256:9f3a...c2",
"storage_anchor_tx": "0xab12...ef on 0G mainnet",
"compute_anchor": {
"provider": "0xC0MP...77",
"request_id": "req_882",
"ran_in_tee": true
},
"signed_by": "0xEVID...SIGNER",
"signed_at": "2026-03-14T11:42:08Z",
"schema": "evidiq/trust-report@v1"
}
}
That's the whole flow. One MCP call, one sub-cent payment, one signed verdict.
Notice what your agent just got — and what it didn't have to do itself:
- No manual probe or hand-parsed agent-card.
- No parallel ENS / ERC-8004 lookups to glue together.
- No homegrown heuristic for "new vs fake" reputation gaps.
- No separate signing, anchoring, or schema reasoning.
If your agent's policy is "anything below 60 → route through escrow," it acts on that 41 automatically. If YieldPilot disputes the verdict later, the evidence_uri is replayable: fetch the canonical report, re-hash it, recover the signer. That's the part we care about most at EVIDIQ — an evidence trail you don't have to take our word on.
The deeper plumbing — schema enforcement, storage anchoring, the TEE-bound risk analysis — lives in the EVIDIQ Sentinel docs.
The Three Questions Every Trust Layer Has to Answer
Every trust check, anywhere in the world, answers three questions in some form:
- Who is this? (Identity.)
- Can they do what they say they can do? (Capability.)
- Have they done it before, and did it go well? (Reputation.)
A useful trust layer for AI agents answers all three with evidence you can replay — not three vibes stitched together.
Identity is the cheapest to check and the easiest to fake. We score it from a verifiable EVM address, an ERC-8004 identity id, an ENS name, or a TLS-served domain. Highest weight goes to a domain that proves control over both a wallet and a DNS name, because that's a thing bots can buy but mostly choose not to.
Capability is where we get our hands dirty. A declared capability list is just a text file. Anyone can write a text file. So our probe — bounded at roughly six seconds — hits the agent's endpoint and checks: is it reachable, is the TLS clean, does it actually serve a machine-readable skill / agent-card / MCP surface, and do the declared capabilities match what that surface advertises? If an agent claims to be an "x402-acceptor" but its endpoint returns a 200 with {"name": "blog"}, that mismatch shows up in the score and the summary.
Reputation is the hardest, and we're honest about that. As of 2026, we don't yet have a fully populated on-chain historical reputation registry. What we can score today: identity anchors with economic skin in the game (a working x402 endpoint isn't free to keep alive), declared-vs-probed consistency, and any first-party records we can independently fetch. Our reputation score is conservative on purpose. We refuse to invent history. The full historical ledger is a roadmap item, not a shipped feature — see our public EVIDIQ Operator docs for what's live versus what's queued.
The formula is dead simple:
final = identity * 0.3 + capability * 0.3 + reputation * 0.2 + (100 - risk) * 0.2
We publish this formula. We've documented it. There is no hidden model layer quietly reweighting things. Run the same four numbers through the same arithmetic and you'll get the same answer we did. That's the design choice that makes the score auditable instead of authoritative.
What a Trust Layer Is Not
Plenty of products in 2026 claim to add "trust" to agent flows. Worth being blunt about what EVIDIQ is not:
- Not an escrow. We don't hold funds, don't take custody, and don't freeze anything. If your policy says "route to escrow on caution," you pick the escrow — a multi-sig, a market-maker, whatever. We produce the signal. The protection itself is yours.
- Not a KYC provider. We don't verify that a real human named Alice lives at a real address. We're verifying an agent. Identity here means "this key controls this endpoint." That's a meaningful claim. It's not a legal one.
- Not a guarantee. A score of 92 doesn't mean the counterparty will perform. It means the available evidence is consistent with a high-trust outcome. Stuff still goes wrong. New agents still turn out to be bad. Our recommendation is a recommendation, not a contract.
- Not regulatory certification. We do not certify under the EU AI Act. We do not perform AML checks. If you need that, you need a different vendor — and we'd tell you so.
The framing we use internally: EVIDIQ is the evidence layer. We hand you a signed report and an evidence URI you can re-fetch at any time. The decision — pay directly, pay with escrow, walk away, demand a higher score next round — is yours.
That's the boundary. Some teams want us to be bigger than that. We'd rather be small, deterministic, and verifiable than big and full of caveats.
If you want to see exactly which fields the signature covers and what the canonicalization rules are, the EVIDIQ Notary docs have the schema and verification recipe.
