You've got an autonomous agent. It's pitching you a deal — swap 500 USDT0 for some service, hand over API access, or settle an invoice. You don't know who runs it. You don't know if it can actually do what it claims. And in the next 200 milliseconds you're being asked to commit real money.
That gap — between "an agent exists" and "I trust it enough to pay it" — is exactly what we built EVIDIQ to close. We're not a payment rail. We're not a wallet. We're the trust layer for AI agents that turns a cold request into a signed, explainable answer you can act on.
What Is a Trust Layer for AI Agents?
A trust layer for AI agents is infrastructure that sits between an unknown agent and a paying counterparty, verifying identity, declared capability, and reputation signals, then returning a deterministic 0–100 score plus an explicit recommendation. EVIDIQ is that layer for the autonomous economy — it produces a signed Trust Report on demand, never holds funds, and never grants authority, so callers can decide for themselves whether to proceed, escrow, or walk away.
Here's the thing: the term "trust layer" gets thrown around a lot. Let me be precise about what we mean, because the boundaries matter.
The agent economy already has layers, and they're stacked on top of each other:
- Identity layers — ERC-8004, ENS, DIDs. They answer who controls this address.
- Payment layers — x402, the various micropayment rails. They answer how money actually moves.
- Compute layers — 0G, Render, Akash, the inference providers. They answer where the work happens.
- Discovery layers — agent registries, marketplaces, directories. They answer what agents even exist.
A trust layer for AI agents is none of those. It doesn't move money. It doesn't run inference. It doesn't issue identities. What it does is take the outputs of those layers — when they exist, and the absence of them when they don't — and produce one auditable verdict: should you transact with this thing right now, yes or no, and here's why.
We built EVIDIQ as exactly that. You call one endpoint, you get back a Trust Report. Inside that report: a 0–100 score, broken into identity, capability, reputation, and risk, plus a plain-English recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed. The report is hashed, anchored on 0G Storage, signed with our key. Anyone can re-fetch the evidence and recover the signer.
That's the layer. Now let me show you what one call actually looks like.
One Call, Start to Finish
Imagine your agent — let's call it YieldPilot-7 — wants to hire a service from another agent called ArbBot-42. ArbBot-42 advertises itself at https://arb-bot-42.example/x402/mev-shield and claims to provide MEV-protected routing for $0.02 per call. Before YieldPilot-7 burns 20 cents and exposes itself to a malicious endpoint, it asks EVIDIQ: who is this thing, and can I trust it?
Here's the request. It's JSON-RPC over HTTPS to evidiq.dev/mcp:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "verify_agent",
"arguments": {
"agent": "https://arb-bot-42.example",
"declared_capabilities": ["mev_protected_routing", "swap_execution"],
"context": "paying 0.02 USDT0 per call via x402"
}
},
"id": 1
}
Step one: the MCP server receives the call. It checks your payment. If you haven't paid for the slot, you get back an HTTP 402 challenge following x402 v2:
{
"accepts": [
{
"scheme": "exact",
"network": "x-layer",
"resource": "https://evidiq.dev/mcp",
"amount": "2026",
"asset": "USDT0",
"payTo": "0xEV1D1Q...PAY",
"extra": { "name": "TetherUSD", "version": "1" }
}
]
}
Your client signs an EIP-3009 transferWithAuthorization and retries with the X-PAYMENT header. That's how payment works — settled on X Layer in USDT0, no account, no signup, no stored card.
Step two: with payment cleared, EVIDIQ runs the verification. We pull https://arb-bot-42.example/x402/mev-shield and probe it — a bounded ~6-second GET that checks TLS validity, reachability, and whether the endpoint serves a machine-readable skill or agent-card surface. We resolve any declared EVM addresses, look for an ERC-8004 identity registration, check for an ENS reverse record, and inspect the agent's own x402 endpoint for Pay-To, scheme, and price consistency.
Step three: we score. The formula is fixed and public: identity * 0.3 + capability * 0.3 + reputation * 0.2 + (100 - risk) * 0.2. Same inputs always produce the same score — that's deliberate. A trust score you can't reproduce isn't trustworthy.
Step four: we assemble the Trust Report. A fictional but realistic outcome for ArbBot-42:
{
"agent": "https://arb-bot-42.example",
"score": 64,
"components": {
"identity": 55,
"capability": 78,
"reputation": 40,
"risk": 22
},
"recommendation": "proceed_with_escrow",
"evidence": {
"endpoint_reachable": true,
"tls_valid": true,
"serves_agent_card": true,
"ens_resolved": false,
"erc8004_id": null,
"evm_address_declared": "0xA1b2...c3d4",
"x402_served": true,
"probe_latency_ms": 412
},
"anchored_on_0g": "0xtx...",
"signature": "0x9f..."
}
That last signature field is the part most teams miss. The whole canonical report is keccak256-hashed, the hash is anchored to 0G Storage mainnet (returning a real on-chain tx), an AI risk analysis can run inside a TEE on 0G Compute with GLM-5.2, and the verdict is then signed with our EVIDIQ key as an EIP-191 personal_sign. Anyone — your agent, your auditor, a regulator someday — can re-fetch the evidence, re-hash it, and recover the signer.
That's the whole flow. Cold request, payment, probe, score, attest. One round-trip, a few hundred milliseconds, and your agent now has a defensible reason to either proceed, escrow, or refuse.
The Three Questions Every Trust Layer Has to Answer
Every trust layer for AI agents, ours included, has to answer three questions. Get any one of them wrong and the whole verdict collapses.
Identity — who is this? A wallet address alone tells you nothing. A clever attacker rotates addresses daily. So we score identity with multiple signals: a verifiable EVM address, an ERC-8004 on-chain identity id, an ENS reverse record, a TLS-served domain with a sane certificate. The more of those anchor the agent, the higher the identity subscore. ArbBot-42 had no ENS and no ERC-8004 id, but it did have a clean EVM address and a domain — that's why identity landed at 55, not 20.
Capability — can they actually do what they claim? Anyone can put ["mev_protected_routing", "swap_execution"] in a JSON file. Our capability score rewards declared capabilities and a live probe — we hit the endpoint, check it serves a machine-readable surface, and verify the agent card matches the claim. ArbBot-42 served a valid agent card and its probe returned in 412ms, so capability landed at 78.
Reputation — have they done this before, and did it go well? Here's where we have to be honest with you. Our reputation signal today is built from identity anchors and live economic signals — for instance, does this endpoint actually run a paid x402 service? That's "skin in the game" — if the agent has been collecting micropayments for weeks, that's a meaningful behavioral signal. We do not yet have a full on-chain historical reputation ledger, automated dispute resolution, or anything resembling a regulatory-compliance certification. Those are roadmap items, not shipped features. Never pretend otherwise.
Bundling the three into one score — instead of asking the caller to check three separate registries and triangulate by hand — is the actual product. The math is simple: a developer who has to manually combine identity lookups, endpoint probes, and reputation queries is not going to do it on every transaction. They will skip it. And then the first scam agent that rotates addresses will drain them. EVIDIQ makes the safe path the path of least resistance.
What a Trust Layer Is Not
This boundary matters, and we're going to be blunt about it.
EVIDIQ is not an escrow. We never hold your funds. We never hold anyone's funds. We produce evidence. If the recommendation is proceed_with_escrow, you choose the escrow — a smart contract, a multisig, a third-party service. We're a witness, not a custodian.
EVIDIQ is not a KYC provider. We don't run sanctions checks. We don't collect personal data. We don't issue compliance certifications. The EU AI Act, AML/KYC regimes, and regulated financial onboarding are out of scope for us today. We anchor on technical signals — addresses, domains, on-chain identity registrations, endpoint behavior — and we say so plainly.
EVIDIQ is not a guarantee. A score of 92 is not a promise that the agent will behave. It's a statement about the evidence available right now. The moment after our probe, the agent could redeploy, the domain could expire, the owner could drain liquidity. Trust is a snapshot, and we sign the snapshot — not the future.
What we do give you is something rarer than any of those: a signed, reproducible, auditable record of what we checked and what we found. That's the boundary. We hand you evidence and a recommendation. What you do with it is your call.
This is also why we're listed as an OKX.AI Agent Service Provider (ASP) rather than embedded inside a wallet or exchange. We're a primitive, not a product suite. Build whatever you want on top — dispute flows, escrow contracts, reputation marketplaces — and treat our score as one input.
