Reading the Room on AI Agent Escrow Risk: How EVIDIQ Returns a Verdict

Four Verdicts, Not a Yes/No

AI agent escrow risk is the gap between an agent being reachable and being trustworthy enough to settle with. A binary trust answer fails the middle case where most counterparties actually sit. EVIDIQ returns four explicit recommendations — proceed, proceed_with_escrow, caution, do_not_proceed — each tied to a deterministic 0-100 score. It's a wire-ready directive, not a vibe.

Here's the thing. When a developer asks "should I send funds to this agent?", the honest answer is rarely yes or no. It depends on identity, on whether the endpoint actually responds, on what work is being claimed, on who has skin in the game. Collapse all of that into a single green checkmark and you've lied.

So we built EVIDIQ to return one of four explicit recommendations per counterparty check: proceed, proceed_with_escrow, caution, or do_not_proceed. Each is paired with a 0-100 trust score and a short evidence trail. No opaque LLM verdict behind the curtain. Same inputs, same score, every time, and the whole thing is auditable by re-running the request.

The middle two tiers are the ones people skip past in design docs and then rediscover the hard way in production. A brand-new agent with a verifiable address and a working endpoint but no settled history should not get the same verdict as a long-running service with a thousand paid invoices on file. The four-tier output is what lets your code branch correctly when reality is genuinely ambiguous.

The Thresholds, Exactly

The numbers below are what the EVIDIQ skill computes and what verify_agent returns in its JSON response. We've published them because hiding them would defeat the point of a deterministic score.

The composite score is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Each sub-score is itself 0-100. The recommendation maps onto the composite and the risk sub-score together — not either alone. proceed_with_escrow, the middle tier, exists precisely for counterparties you have not seen enough times yet to trust naked settlement.

• proceed — composite ≥ 75 AND risk ≤ 25. The agent has a verified EVM address or ERC-8004 identity id, an HTTPS-served skill or MCP endpoint that responded in the probe window, and at least one signal of economic skin in the game (e.g. they serve a paid x402 surface). The middle of the road looks safe.
• proceed_with_escrow — composite 55–74, OR risk 26–50 regardless of composite. The agent has a reachable endpoint and plausible identity anchors, but capability or reputation is thin. Settle, but do not settle naked.
• caution — composite 40–54, OR risk 51–70. Identity, capability, or both are weak. A human should be in the loop, amounts should be capped, and dispute terms pre-arranged.
• do_not_proceed — composite < 40, OR risk > 70. Unverifiable identity, dead endpoint, or material risk flags. Stop.

Worth noting: an agent can sit at composite 78 with risk 20 and still land in proceed_with_escrow if the risk sub-score alone ticks above 25 for an independent reason — say, the capability claims do not match what the live probe saw. That is not a bug. A single sub-score crossing a threshold is supposed to escalate the verdict. The whole point is to refuse a clean bill of health when one dimension is screaming.

If you want the exact fields and order of operations, EVIDIQ docs walks through the formula in source-level detail. Nothing hidden behind a sales call.

Why proceed_with_escrow Is the One Most Deals Land On

The middle tier is not a hedge. It is the honest read.

A working agent with a fresh wallet, a decent MCP card, and no settled history is a normal Saturday morning in this space. It is not fraud. It is not innocence either. It is a counterparty you have never seen before trying to do real work, and the rational response is "I'll pay you, but I'll pay through something that gives me recourse." That something is escrow — and proceed_with_escrow is the tier where EVIDIQ is telling your agent the same thing.

In practice it looks like this:

1. Agent A calls verify_agent on Agent B and gets proceed_with_escrow with composite 62 and risk 38.
2. Agent A's own logic reads that field and routes payment through an escrow contract the two parties agreed on earlier.
3. Work happens. Escrow releases on either an external signal or a dispute window.

The key move: EVIDIQ produces the recommendation, the calling agent decides what to do with it. We are emphatically not telling you which escrow vendor to use, which arbitrator to hire, or which dispute logic is "approved." EVIDIQ is the trust oracle. You are the principal. Stay that way.

The mistake we keep seeing in design reviews is treating proceed_with_escrow as "almost proceed" and collapsing it into the green tier because "the score is fine." It is not. It is a tier with its own implications, and it expects protection.

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

There is a tempting version of this product where we hold the funds. We could. The infrastructure is not hard. We deliberately don't, and the reasoning is the actual point of this article.

Custody is authority. The entity holding escrow has the power to release or withhold, which makes it a privileged counterparty on every deal it touches — with the regulatory surface (KYC, AML, money transmission), the operational surface (hot wallet, key management), and a target profile that attackers will spend real effort on. Mix that role with "we tell you whether the counterparty is real," and you have built a single point of failure that owns both trust signal and settlement.

That is a worse design than the one we shipped. So the boundary is:

• EVIDIQ — produces a deterministic, explainable recommendation plus cryptographically anchored evidence. We do not choose the trustee, the payer, or the dispute arbiter.
• Caller — chooses the settlement rail, escrow contract, dispute policy, and amount caps. EVIDIQ never holds funds, never grants authority, and never signs anything that moves money.

Tying it back to the keyword: this is exactly why AI agent escrow risk has to be split into "trust oracle risk" and "settlement risk" rather than collapsed into one bucket. The trust oracle can be replaced, fork-compared, and re-run. The settlement rail cannot — not in flight. Separating them means a compromise on one side does not poison the other.

We anchor the report itself on 0G Storage, hash it with keccak256, optionally run an AI risk analysis on 0G Compute (GLM-5.2 inside a TEE), and sign the verdict with the EVIDIQ key per EIP-191. Anyone can refetch the evidence, rehash it, and recover the signer. We publish the receipts because that is the only way the recommendation stays useful independent of us.