Last quarter a wallet drained itself in eleven seconds. An agent hit a perfectly reasonable-looking endpoint, accepted a $4,200 invoice for a "translation task," paid it, and never asked the obvious question: is the other side actually who it claims to be? That endpoint had no real operator behind it. The agent card was scraped, the ENS was rented, and the invoice settled against a clean-looking address. By the time the audit trail surfaced, the money was three hops deep.
We wrote this post because that story is not rare. It's the default. The autonomous economy in 2026 moves real value between agents that have never met, often on reputation they couldn't verify even if they wanted to. So we built EVIDIQ to sit between any two agents before money moves and answer one question: should this transaction happen?
What Is a Trust Layer for AI Agents?
A trust layer for AI agents is an external verification service that scores an autonomous agent's identity, capabilities, and reputation before any money or authority moves. EVIDIQ is a trust layer for AI agents: it returns a deterministic 0-100 score with an explicit proceed, proceed_with_escrow, caution, or do_not_proceed recommendation that anyone can independently verify.
That definition sounds simple. In practice the term gets thrown around for anything that touches an agent's name, wallet, or skill file. Worth being precise about what a trust layer actually is, because three adjacent things get confused with it constantly.
Identity layer: registers a name, an address, an ERC-8004 id. Doesn't ask whether the agent can do anything useful or whether anyone has paid it before. A bare identity layer is a phone book, not a credit check.
Payments layer: routes money, settles invoices, handles the x402 dance. Doesn't know who is on the other end. The payments layer is the rail, not the conductor.
Compute layer: runs the agent's brain, hosts models, executes tasks. Doesn't vouch for who you are talking to. The compute layer is the muscle, not the witness.
A trust layer for AI agents sits next to all three. It doesn't move money. It doesn't run models. It doesn't register names. What it does is produce an auditable verdict about whether the party you're about to transact with is real, capable, and has skin in the game. That's a narrow job, and we think it has to stay narrow to be useful.
One Call, Start to Finish
The cleanest way to show what EVIDIQ actually does is walk through one real verify_agent call. Let's say your agent — call it AcmeBuyer, wallet 0xA17C…4f2B on X Layer — wants to hire an unfamiliar data vendor named "Lattice Analytics." Lattice claims ENS lattice-x402.eth, an ERC-8004 identity id of 1247, and the ability to serve 50k rows of cleaned trade data for $480 in USDT0.
Here's the call your agent makes:
{
"jsonrpc": "2.0",
"id": "req_001",
"method": "verify_agent",
"params": {
"agent": {
"address": "0x9b3E…7aC1",
"ens": "lattice-x402.eth",
"identity_id": "1247",
"endpoint": "https://lattice-x402.example/.well-known/agent.json",
"declared_capabilities": ["data.delivery.csv", "x402.invoicing"]
},
"context": {
"task": "data.delivery.csv",
"value_usd": 480
}
}
}
Our MCP server sees the request. It runs three things in parallel:
- Identity resolution — does
0x9b3E…7aC1actually resolve tolattice-x402.eth? Does an ERC-8004 record exist at id1247? Does the TLS certificate on the endpoint match the claimed ENS? - Capability probe — a bounded ~6s GET against the agent's endpoint. We check TLS, reachability, and whether it serves a real machine-readable surface (skill file, agent card, or MCP manifest). No full task execution. Just: is the door real?
- Reputation and risk — has this endpoint served a paid x402 flow before? Does it advertise economic skin in the game, or is it a brand-new domain with a freshly minted ENS?
Then comes the x402 dance. verify_agent is paid per call. If your agent hasn't paid yet, you get back:
{
"status": 402,
"accepts": [{
"scheme": "exact",
"network": "xlayer",
"asset": "USDT0",
"amount": "100000",
"payTo": "0xEVIDIQ…fees",
"extra": { "name": "EVIDIQ", "version": "1" }
}]
}
That's an x402 v2 challenge with accepts[].amount. Your agent pays USDT0 via EIP-3009 transferWithAuthorization, retries the call, and gets the actual report:
{
"score": 78,
"recommendation": "proceed",
"components": {
"identity": 92,
"capability": 84,
"reputation": 61,
"risk": 81
},
"evidence_root": "keccak256:7c4f…91a",
"attestation": {
"anchor": "0G Storage tx 0xab12…",
"signed_by": "evidiq.eth"
}
}
Identity 92 (real ENS, real id, real cert). Capability 84 (probe succeeded, machine-readable surface present). Reputation 61 (endpoint is younger than 90 days, only 4 historical x402 receipts — not bad, just thin). Risk 81 (clean). Final trust score: 92*0.3 + 84*0.3 + 61*0.2 + (100-19)*0.2 = 81.0. Same inputs, same answer, every time. That's the point of a deterministic formula — anyone can replay it and confirm the math.
The report itself is tamper-evident. We hash the canonical report (keccak256), anchor the evidence on 0G Storage on mainnet, and sign the verdict with the EVIDIQ key (EIP-191). Anyone can refetch the evidence, rehash it, and recover the signer. AcmeBuyer now has a signed receipt it can hold onto — and Lattice can't retroactively edit the score after the fact.
The Three Questions Every Trust Layer Has to Answer
If you strip the marketing off every trust framework we've ever read, you get the same three questions underneath. The difference is whether you answer one, two, or all three — and whether the answers are independent or self-claimed.
Identity — "Who is this?"
Is there a verifiable principal behind the agent? EVM address, ENS, ERC-8004 id, TLS-served domain. None of these individually prove identity, but stacked together they make impersonation expensive. A wallet balance alone tells you nothing about intent — that's the gap a real identity check closes.
Capability — "Can they actually do it?"
Declared skills are worthless without a probe. Anyone can write data.delivery.csv into an agent card. The probe hits the endpoint with a bounded request and confirms the agent serves a real machine-readable surface. We don't run the full task — that would be a benchmark, not a verification. We just confirm the door is real and the agent speaks the protocol it claims.
Reputation — "Have they done this before, and was it good?"
Here's where we have to be honest about 2026. There is no mature on-chain reputation ledger yet — not from us, not from anyone credible. What we score today is reputation-shaped: identity anchors that have aged, endpoints with real uptime, and most importantly economic skin in the game — the agent serves a paid x402 flow, so lying has a cost. In the EVIDIQ docs we treat this as a 0-100 signal that we'll keep tightening as more signal sources come online.
The reason these three have to be one score, not three separate checks, is that a single check is gameable. Identity alone is rented. Capability alone is performed. Reputation alone can be farmed. Bundle them, weight them, and the attack surface shrinks fast. Our formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Deterministic. Auditable. Same inputs, same number.
A few practical patterns we've seen work in 2026:
- For high-value transactions (>$5k), agents refuse to even begin the handshake until the trust score is above 70.
- For medium-value jobs ($200–$5k), they accept scores above 60 but require escrow on top of the verdict.
- For low-value micro-tasks, they often run unverified — but the cost of being wrong is bounded, so the math holds.
We didn't invent that pattern. The market did. We just made it easy to express as a single threshold check.
What a Trust Layer Is Not
This is the section where most trust frameworks get vague. We won't.
A trust layer for AI agents is not an escrow. EVIDIQ never holds funds. We don't custody, we don't settle, we don't have a refund button. When our recommendation says proceed_with_escrow, we are saying: we'd use escrow here. The actual escrow is up to you and your counterparty. If you want the mechanics, the EVIDIQ Sentinel docs walk through how our verifier integrates with common escrow flows — but the money never touches us.
A trust layer is not a KYC provider. We don't collect names, passports, or selfies. We don't have an AML pipeline. We don't have an EU AI Act certification (and we won't pretend we do — that's roadmap, not shipped). Identity, in our model, is a cryptographic anchor — an address, a name, a cert — not a passport. If a regulated counterparty wants regulated KYC, they should do KYC; that's a different layer for a different job.
A trust layer is not a guarantee. The trust score is a probabilistic verdict, not a refund. A 95 doesn't mean "this agent is safe." It means "the available evidence supports proceeding." A 5 doesn't mean "this is a scam." It means "the available evidence doesn't support proceeding — go ask more questions or walk away." Agents and humans misread this constantly, so we're blunt: the score is evidence. The decision is yours.
A trust layer is not a regulator. We don't have authority over who is allowed to transact. We don't blacklist addresses. We don't arbitrate disputes. We produce signed reports. The agents and humans on either side pick their own protection — direct settlement, escrow, holdback, arbitration, none of the above.
If you want the technical boundary drawn out, the EVIDIQ Notary docs cover what an attestation actually binds and what it doesn't. Short version: it binds the report to the evidence at the moment of signing. It doesn't bind the future behavior of the counterparty.
Worth saying out loud: the worst trust-layer failure mode isn't a bad score. It's an over-trusted score. When a downstream agent treats "EVIDIQ said proceed" as a substitute for thinking, we've done harm. We've spent real engineering time making the score hard to misinterpret — the recommendation field exists explicitly to push back against "I'll just take the number."
