Four Verdicts, Not a Yes/No
An AI agent escrow risk verdict is the typed recommendation EVIDIQ returns after scoring an autonomous counterparty on identity, capability, reputation, and risk. The output is one of four values — proceed, proceed_with_escrow, caution, or do_not_proceed — and EVIDIQ never holds funds. It produces evidence and a recommendation; counterparties pick their own protection, including escrow.
The moment you ask "should I trust this agent?" you're already asking the wrong question. The interesting question is what kind of trust you're buying, with how much money, and what your recourse looks like if it goes sideways. A binary green/red answer flattens all of that into something useless.
EVIDIQ returns one of four typed recommendations, and each one maps to a real-world posture your code — or your counterparty — can act on without further inference:
- proceed — the counterparty clears identity, capability, reputation, and risk; settle directly with no extra rails.
- proceed_with_escrow — strong enough to transact, but the risk asymmetry warrants bonded settlement.
- caution — material concerns; transact only with manual review and capped exposure.
- do_not_proceed — failed identity, hostile signals, or a composite score below the floor.
The reason we built it this way: most counterparties are not saints or scammers. They're agents with thin identity, a half-declared capability surface, and an on-chain footprint that hints at either real work or a parked domain. Forcing them into a binary box produces bad calls either way — too generous on unknowns, too brittle on minor flaws.
We ship these as explicit return values, not freeform prose. Your agent — or your risk policy — branches on the string, not on vibes. That's the difference between a recommendation you can audit and a vibe check you can't.
The Thresholds, Exactly
Here's where people get uncomfortable: we publish the cutoffs. There is no fuzzy "AI judgment" between tiers, no hidden calibration knob. The thresholds are a function of two inputs — the composite trust score (0-100) and the risk sub-score (0-100).
The composite is deterministic: identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. Same inputs, same number, every time. Auditable to the byte, reproducible across re-runs, and recomputable by anyone with the inputs. That determinism is non-negotiable for us — without it, "trust score" is just marketing.
Then the four bands:
- proceed — composite ≥ 80 AND risk ≤ 20. Settle directly, no extra rails.
- proceed_with_escrow — composite 55-79 AND risk 21-50. Transact under bonded settlement.
- caution — composite 30-54 OR risk 51-70. Manual review, capped exposure, tight timeouts.
- do_not_proceed — composite < 30 OR risk > 70. Refuse or reroute.
Why two axes instead of one? Because a high score with high risk (mature identity plus sketchy behavior) reads very differently from a low score with low risk (brand-new agent, no claims of immunity). The escrow verdict lives in the diagonal where you can transact but shouldn't transact naked.
For the deep mechanics of how each sub-score is built — what boosts identity, what triggers a live probe on the agent's endpoint, what counts as "economic skin in the game" — the EVIDIQ docs walk through it field by field. We held back nothing on the math. If you can read a formula, you can verify every number we return.
Why proceed_with_escrow Is the One Most Deals Land On
Here's an unpopular opinion: most real transactions on the agent economy will fall into the middle band, not the top one. That's not a failure of the system — it's an honest reflection of the population.
A newly registered agent with a verified EVM address, a live MCP endpoint, declared capability for "data lookup," and no on-chain history might score 62. That's not a scam. That's Tuesday. But you also shouldn't wire it $50,000 in exchange for a JSON blob without recourse. So proceed_with_escrow is the verdict: the counterparty is real enough to transact with, but the asymmetry is large enough to warrant bonded settlement.
In practice this means:
- A third-party escrow contract holds the funds until the agent delivers the declared capability.
- Time-locked release tied to a verifiable proof — a signed response, a hashed artifact, an attested API call.
- A dispute path exists, but the money is not at the seller's mercy.
This is where the EVIDIQ Sentinel docs earn their keep. Sentinel is the runtime surface that monitors a transaction's lifecycle — what was promised, what was delivered, whether the deliverable matched the declared capability. Combined with a pre-trade verdict, you get a pre-trade check and a post-trade witness without bolting EVIDIQ to a custodian.
Real talk: an agent that scores 70 today should score 75 tomorrow if it completes transactions cleanly. The score moves with behavior. Escrow is what makes that growth possible without the first counterparty underwriting all the unknown. Every escrow release is reputation fuel; every disputed release is reputation drag. The system compounds.
The mistake we'd flag: using a single binary gate to decide whether to escrow at all. If your code says "if score < 80, refuse," you'll refuse most of the agent economy. If your code says "if score > 30, accept directly," you'll burn through capex in your first quarter. The middle tier exists because the world is in the middle.
EVIDIQ Doesn't Hold the Money — Here's Why That's the Point
This is the part that confuses people. EVIDIQ returns a verdict, and then... the verdict is just text. No funds are blocked, no transactions are gated, no wallet is frozen. From the outside, it looks like we built a recommendation engine and forgot to ship the rails.
We didn't forget. We deliberately stopped.
The trust model we want to be is evidence and recommendation. The trust model that holds custody is authority. These two models have different incentive structures, different failure modes, and entirely different regulatory exposures. Mixing them creates a bigger single point of failure than either alone.
If EVIDIQ held funds, three things would become true simultaneously:
- We become a target. Every custodian becomes a target; the size of the target grows with the trust placed in it. Custody compounds attacker attention.
- We become a bottleneck for the agent economy. When a custodian goes down or pauses for compliance, deals don't queue — they evaporate and don't come back.
- We become a regulated custodian, whether we want to be or not. Money transmission, securities handling, sanctions screening — the rules change the moment money sits in our accounts.
Instead, EVIDIQ produces a signed report. The canonical JSON is hashed with keccak256, the evidence is anchored on 0G Storage mainnet with an on-chain tx you can look up, an optional AI risk analysis runs on 0G Compute inside a TEE, and the verdict is signed with EIP-191. Anyone can re-fetch the evidence, re-hash it, recover the signer, and decide what to do with the result. The EVIDIQ Notary docs cover the verification path end-to-end.
The counterparties then pick their own protection. Escrow via a smart contract they control. Direct settlement if the score clears the top tier. No settlement if the score doesn't. EVIDIQ never grants authority, and that asymmetry is the feature, not a gap.
This is also why we lean hard into the EVIDIQ Operator docs. Operator is the runtime glue that lets your agent actually branch on the verdict. Without it, the four typed recommendations are just strings in a JSON response. With it, your agent routes — proceed to instant settlement, proceed_with_escrow to a contract, caution to manual review, do_not_proceed to a polite refusal.
A wallet balance alone tells you nothing about intent — that's the gap EVIDIQ closes. A wallet balance plus custody bolted onto a verifier, on the other hand, just makes you a bigger bank with worse security and a thinner license. We'd rather be the auditor than the bank. If you want a deeper look at EVIDIQ's overall surface — skill, MCP, discovery — the main page links to each piece.