Inside EVIDIQ's Take on AI Agent Escrow Risk

Picture this: it's 2 AM, your agent just signed a $4,000 inference job with another agent, and the seller side has vanished mid-delivery. The work isn't done. The money is on a chain somewhere. Nobody is on the hook. That's the exact failure mode we built EVIDIQ around — and it's the reason a binary trust/no-trust answer doesn't cut it.

Real deals in the AI agent economy live in a wide middle. Some counterparties are obviously fraudulent and should be rejected outright. Some are obviously fine. But most land somewhere in between: a new wallet, an unverified capability claim, no reputation history yet, an endpoint you haven't actually probed. For that middle, "yes" or "no" is malpractice. You need a verdict that names the risk and tells you what to do about it.

Four Verdicts, Not a Yes/No

AI agent escrow risk is the gap between "is this counterparty safe?" and "what should I do next?" EVIDIQ closes it with four recommendations: proceed, proceed_with_escrow, caution, or do_not_proceed, computed deterministically from identity, capability, reputation, and risk sub-scores (0–100). The verdict matches the underlying AI agent escrow risk so autonomous workflows can act on it directly.

The instinct for a lot of teams building agent-to-agent commerce is to ask the trust oracle a yes/no question. We think that's wrong. It's wrong because the honest answer for most counterparties is "I can't tell yet, but here's what to do about it." A real AI agent trust score needs to land somewhere in the middle — and that middle is where escrow lives.

Every verify_agent call returns:

• A 0–100 combined score
• A recommendation tier (one of the four)
• The four sub-scores broken out (identity, capability, reputation, risk)
• A keccak256 hash of the canonical report
• An anchoring transaction on 0G Storage mainnet
• An EIP-191 signature from the EVIDIQ key

The recommendation is not a vibe. It's a deterministic output of our formula: identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. Same inputs, same score, same verdict — every time. You can replay it tomorrow and get the same number. That's the whole point of building a trust layer you can audit instead of a black box you have to trust.

The Thresholds, Exactly

Let's get boring and specific. Here is exactly how a combined score and risk sub-score map to a verdict in the current scoring logic:

1. score ≥ 75 and risk ≤ 25 → proceed. Identity and capability are strong, no meaningful risk flags, reputation signals are positive. Settle normally.
2. score ≥ 55 and risk ≤ 50 → proceed_with_escrow. The counterparty is plausible but not solid. Settlement should route through a third-party escrow contract.
3. score ≥ 35 and risk ≤ 70 → caution. Identity is thin, capability is unproven, or risk signals are elevated. Proceed only with explicit per-deal terms, low value, and a kill switch.
4. score < 35 or risk > 70 → do_not_proceed. The agent cannot be reasonably authenticated, declared capabilities contradict probed behavior, or live probes failed outright. Walk away.

[IMAGE_PROMPT: A modern flat illustration of a horizontal score axis running from 0 to 100 with four colored bands: a deep green band labeled proceed, a yellow band labeled proceed_with_escrow, an orange band labeled caution, and a red band labeled do_not_proceed. Above the axis are four circular sub-score dials showing identity, capability, reputation, and risk. Geometric data-viz aesthetic with thin connecting lines between the dials and the axis, soft blue and teal accents, no logos, no text in image]

Worth noting: these are intentionally narrow bands, not cliffs. A score of 76 and a score of 74 get different recommendations. That's not a bug — it's the whole point. AI agent escrow risk is not a binary property of a counterparty; it's a continuous signal, and the verdict changes as the signal crosses thresholds.

We've also published these bands in EVIDIQ docs so anyone integrating verify_agent can build decision logic on top without re-implementing the formula. The score is deterministic, the receipts are anchored on 0G Storage mainnet, and the verdict is signed under EIP-191. You can re-fetch, re-hash, and recover the signer later if a deal goes sideways. That's the auditability story.

Why proceed_with_escrow Is the One Most Deals Land On

Here's the part most teams underestimate: in real traffic, the vast majority of agent-to-agent counterparties land in proceed_with_escrow territory, not proceed and not do_not_proceed. That sounds like noise until you look at why.

A typical fresh agent in 2026 has:

• A new EVM wallet, or a domain but no on-chain identity id
• Declared capabilities it hasn't yet proven at scale
• No historical disputes, because there is no historical data yet
• A reachable endpoint, but one that hasn't been seen serving paid x402 traffic

That profile is not a scam. It's a Tuesday. Most legitimate agents look exactly like this for the first few weeks of their life.

The temptation is to treat "I'm not sure" as "no." That's how you stall an economy. The honest move is to name the uncertainty, then price it. proceed_with_escrow does that. The math is simple: most counterparties are neither obviously safe nor obviously fraudulent, and pretending otherwise is a worse AI agent escrow risk posture than just saying so.

What it actually means in practice:

• Use a third-party escrow contract — Safe modules on X Layer, multichain escrow services, or whatever your settlement layer already exposes
• Lock funds on agreed milestones (delivery proof, agent-card update, capability re-verification)
• Set a short dispute window after each milestone
• Require verify_agent re-calls at the start of each milestone, not just at deal opening

EVIDIQ does not provide the escrow contract itself. We don't need to. Our job is to tell you when to use one, and we've published reference patterns in EVIDIQ Operator docs for common settlement layers.

The honest version: most deals in the middle band aren't dangerous, but the cost of a 5% loss on the rare bad outcome swamps the saved escrow fees on the other 95%. Pairing a proceed_with_escrow verdict with an actual escrow contract is the sweet spot between throughput and safety.

EVIDIQ Doesn't Hold the Money — Here's Why That's the Point

A question we hear a lot: "Doesn't a trust layer that doesn't hold funds feel incomplete?"

Honestly? It's the opposite. The decision to keep EVIDIQ custody-free is a deliberate design choice, and it's the most important one in the system.

If we held funds, we'd be a custodian. We'd take on regulatory scope we'd rather not, we'd be a target for every attacker who ever wanted to drain a hot wallet, and — worst — we'd have authority. Authority over money means authority over outcomes, which means every dispute becomes "did EVIDIQ rule correctly?" instead of "did the parties honor the deal they struck?"

Our model is evidence-and-recommendation. The custody-and-authority model is a different trust shape, and the two are not safe to combine. Here's how they compare:

• Custody model. Single point of failure on the operator. Catastrophic if breached. Reputation is governed by the operator's choices.
• Evidence model. Failure is local to a deal. Reputation is built from independently verifiable receipts. Anyone can re-hash and recover the signer.

[IMAGE_PROMPT: A modern flat illustration split into two visual halves: on the left, a single large cracked safe icon under a magnifying glass with a red warning, representing the custody model; on the right, a constellation of small document cards with hash symbols and tiny checkmarks scattered across the half, representing the evidence model. Geometric, clean lines, developer/tech aesthetic, teal and orange accents, abstract blockchain nodes connecting the right side, no real brand logos, no text in image]

Mixing them is the bad version. A trust layer that both scores the counterparty and holds the money collapses two distinct trust surfaces into one — and the blast radius of any compromise becomes "every active deal on the platform." That's a worse AI agent escrow risk profile than the agent counterparty you were trying to evaluate in the first place.

What we do provide is the receipts to make your own custody decision robust. Every verified report comes with a canonical keccak256-hashed payload, an evidence anchor on 0G Storage mainnet (you get a real on-chain tx back), an optional AI risk analysis run on 0G Compute with GLM-5.2 inside a TEE that records the provider address and request id, and an EIP-191 signature from the EVIDIQ key. Anyone — you, your counterparty, a third-party auditor — can re-fetch the evidence, re-hash it, and recover the signer.

If you're wiring this into a production pipeline, EVIDIQ Sentinel docs walks through per-deal receipt re-verification, and EVIDIQ Notary docs covers the dispute bundle format you can hand to your settlement layer if a deal breaks down. The receipts are the product — the verdict is just the headline.