It's 3:14 AM. A scheduling agent — yours, or one you depend on — wakes up to an inbound job offer. The offer is structured, looks like the kind of task the agent was built for: a translation gig, a data fetch, a price quote. The counterparty is unknown. The wallet that funded the offer is not. There's no human to wake up. There are roughly six seconds before the agent either commits funds or misses the window.
This is the AI agent trust deficit in its purest form.
The 3 A.M. Problem
An AI agent trust deficit is the gap between what an autonomous agent needs to know about a counterparty before transacting — identity, capability, history, risk — and what it can verify in the time it has to decide. EVIDIQ closes that gap by returning a deterministic 0-100 trust score and an explicit recommendation, so the agent acts on evidence.
Re-run that scenario and watch how the pressure concentrates. The agent isn't choosing between "good" and "bad." It's choosing between "act on partial information" and "miss the opportunity." Most agents today default to act — because the cost of inaction is visible and the cost of being scammed is amortized across thousands of transactions.
We see this pattern constantly when we onboard new partners. The pipeline looks healthy. The agent is booking work, paying peers, settling invoices. Then a single bad counterparty drains the wallet, or a malicious "service" returns garbage data that breaks a downstream workflow. By the time a human notices, the damage is done and irreversible. The agent didn't have a way to ask "who is this, actually?" — it had a wallet address and a clock.
Here's the thing: the AI agent trust deficit isn't a future risk. It's the daily operating reality of anyone running an autonomous agent in production in 2026. Theon us is on builders to either solve it structurally or accept silent losses.
Why Wallet Balance Is a Terrible Trust Signal
When an agent has nothing else, it improvises. We watched a half-dozen teams describe their fallback heuristics, and almost every list starts the same way: "check the wallet balance." A counterparty holding 50 ETH feels safer than one holding 0.04 ETH. It's also mostly meaningless.
Balance is trivially gameable. Flash-loan a million dollars into the address for ten minutes, send the invoice, withdraw. Or split the funds across a hundred wallets, run the scam from each, and let the balance numbers reset per transaction. The balance is a snapshot, not an identity — and snapshots lie.
Domain age is the next favorite. "The counterparty's website is two years old" sounds reassuring until you realize domains cost twelve dollars and two-year-old scam domains are a thriving commodity on the aftermarket. Self-reported ENS names? Even worse — an ENS resolves to an address, but the address still has no verifiable history of behavior, no audit trail, no proof it does what its bio claims.
So what does survive scrutiny?
- A verifiable EVM address tied to an ERC-8004 on-chain identity id, not just a fresh keypair.
- An ENS name with actual resolution history, not a fresh registration from yesterday.
- A TLS-served domain that maps to a real operating entity, not a parked landing page.
- Economic skin in the game — a paid x402 endpoint that's actually settling transactions, which costs the operator real money per request.
The EVIDIQ skill checks all four of these in a single verify_agent call. It returns a 0-100 score plus one of four verdicts: proceed, proceed_with_escrow, caution, do_not_proceed. The score is deterministic — identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. Same inputs, same number, every time. No vibes, no LLM hallucination, no "trust me bro."
What Changes When EVIDIQ Is in the Loop
Same 3 A.M. scenario. Same unfamiliar counterparty. This time, the agent — before committing any funds — calls verify_agent on the counterparty's address.
What it gets back is a single JSON object. Inside it: an identity score (88, anchored to a verifiable EVM address with an ERC-8004 identity id and a four-year-old ENS), a capability score (61, because the counterparty declared "translation" but the live probe to its advertised endpoint timed out or returned a non-machine-readable surface), a reputation score (42, modest — a paid x402 endpoint that has settled transactions, but no track record beyond a few weeks), and a risk score (28, low, no anomalies detected). Combined: 88 × 0.3 + 61 × 0.3 + 42 × 0.2 + (100 − 28) × 0.2 = 63.4.
The recommendation attached to that 63.4 is proceed_with_escrow. Not "no." Not "yes, send everything." A specific, defensible action: pay through an escrow arrangement, settle on completion, and only release on verified delivery.
The math is simple. Without EVIDIQ, the agent's choice was binary and blind — trust or refuse, both with bad expected outcomes. With EVIDIQ in the loop, the agent gets a graded response that maps directly to a transaction structure. A proceed score gets direct settlement. A caution gets a smaller commit. A do_not_proceed blocks the payment and the agent moves on. The transaction isn't decided by courage; it's decided by evidence.
We built EVIDIQ's probe to be bounded on purpose — roughly six seconds, a single GET, checking reachability, TLS validity, and whether the endpoint serves a machine-readable skill, agent card, or MCP surface. Long enough to learn something real, short enough to fit inside a sub-ten-second decision window. The agent doesn't wait. It just makes a better call.
This Isn't a Human Problem With an AI Costume On
A reasonable pushback goes: "Humans do this already. We vet vendors, read reviews, check LinkedIn. Why can't agents?" Honest answer: because the entire stack those habits rest on doesn't exist at machine speed.
LinkedIn reviews took weeks to accumulate. So did the network of referrals a human draws on before hiring a contractor. Those signals assume a human is on the other side of every interaction, with a reputation to protect and a face to lose. An agent has neither. Worse, an agent's "name" is just an address — and addresses are free.
What replaces it structurally has to be three things at once. Machine-readable, because the agent isn't reading a webpage with its eyes — it's parsing JSON. Deterministic, because two agents asking "should I pay this address?" should get the same answer, not vibes. And cheaply composable, because the marginal cost of verifying one more counterparty must be near zero, or agents stop verifying. This is what makes the AI agent trust deficit structural rather than incidental — you can't fix it with better instincts.
That last point is why we chose x402 as the payment rail. The verification itself is a paid API call — EVIDIQ charges per verify_agent request via x402, scheme "exact", EIP-3009 transferWithAuthorization, settled on X Layer in USDT0. The 402 challenge follows x402 v2 with accepts[].amount. There's no subscription. There's no monthly minimum. An agent that runs ten verifications a month pays for ten verifications. One that runs ten thousand pays proportionally. The cost tracks the work.
Every issued report gets a canonical keccak256 hash, the evidence is anchored on 0G Storage mainnet — returning an on-chain transaction receipt — and the verdict is signed with the EVIDIQ key using EIP-191. Anyone can re-fetch the evidence, re-hash it, and recover the signer. We're not asking anyone to trust our word. We're giving them the bytes to verify it themselves.