A buyer-side agent hits your endpoint and pulls the trigger on a $40,000 settlement. Two seconds earlier it asked for an AI agent trust score. What comes back is a number with a recommendation — but is it real math, or just vibes? Here's how we actually build it.
The Formula, in Full
The EVIDIQ AI agent trust score is one deterministic number from 0 to 100. It combines four sub-scores — identity, capability, reputation, and risk — into a single weighted verdict, paired with an explicit recommendation (proceed, proceed_with_escrow, caution, or do_not_proceed). Same inputs always produce the same score, so the result is auditable, not a black box.
Here's the math, every time, no exceptions:
score = identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2
We deliberately split the weight 30/30/20/20, not because it's the only valid weighting, but because it's the one we ship. Callers can reweight the four inputs on their end if their risk appetite is different.
Now contrast two agents against that formula. Agent Alpha is a known-good payment agent: a verified EVM address, an ERC-8004 identity id on-chain, a live endpoint reachable over TLS, a signed agent card, and a working x402 paid service — "economic skin in the game."
- Identity: 95 (EVM + ERC-8004 + ENS)
- Capability: 90 (declared + reachable + signed card)
- Reputation: 75 (paid x402 service, age, signals)
- Risk: 10 (clean TLS, no anomalies)
95*0.3 + 90*0.3 + 75*0.2 + (100-10)*0.2 = 28.5 + 27 + 15 + 18 = 88.5 → proceed
Agent Bravo comes in cold. No EVM address, no domain, an HTTP-only endpoint that timed out on the probe, and no payment surface to test.
- Identity: 15 (no EVM, no ENS, no domain)
- Capability: 30 (declared but unreachable)
- Reputation: 10 (no signals)
- Risk: 80 (no TLS, suspicious pattern)
15*0.3 + 30*0.3 + 10*0.2 + (100-80)*0.2 = 4.5 + 9 + 2 + 4 = 19.5 → do_not_proceed
Same formula, very different result. The numbers aren't vibes — they're the explicit output of a deterministic pipeline. You can re-fetch inputs, recompute, and you'll land on the same figure. That's the property that turns an AI agent trust score from a marketing badge into infrastructure.
Why Four Dimensions and Not One Number You Just Trust
The honest answer: a single opaque number invites gaming. The moment one number governs access, every adversary on the network optimizes for that number and nothing else. We've seen this pattern in PageRank, in credit scoring, in ad quality scores. A composite is only useful if you can decompose it.
So we don't return one number. We return four: identity_score, capability_score, reputation_score, risk_score, each in [0, 100], plus the combined verdict. Each sub-score rides on its own evidence — the EVM address, the ENS, the agent-card signature, the probe result, the TLS check, the x402 reachability.
Why does this matter to a builder downstream? Because your risk appetite isn't ours. A wallet paying $2 to fetch a public dataset doesn't care much about an 80-capability score; it cares whether the call will succeed and not double-charge. A $40,000 settlement very much cares about identity and risk. Decomposing the AI agent trust score lets each caller weight dimensions for their own tolerance — without us pretending there's one universal definition of trust.
The other reason: explainability. A score of 19 next to four labels and a do_not_proceed is a thing you can show an auditor, an LLM judge, or a regulator later. A score of 19 alone is a thing you argue about at 2am.
Reading a Finding Code
Every sub-score is built up from findings — small, code-tagged observations the verifier records while inspecting an agent. They're the receipts.
Four codes you should know cold.
id.anonymous — fires when the verifier can't tie the agent to any identity anchor: no EVM address, no ENS name, no TLS-served domain that resolves to the same controller. Severity is high when nothing else is present; the identity sub-score drops into the 10–30 range, and the recommendation engine tends to push toward caution or worse on top-line. For an agent that is literally brand new and will earn anchors over time, we keep this finding present rather than masking it — it's an honest signal of present state, not a permanent verdict.
cap.reachable — fires when the ~6-second bounded probe GET returned a 2xx, served a machine-readable surface (skill, agent card, or MCP manifest), and matched the declared capability. Severity is low; it's the green light. A failed probe is its own finding (cap.unreachable) and usually caps the capability sub-score at 30.
risk.no_tls — fires when the endpoint is HTTP-only, or TLS is misconfigured (expired cert, hostname mismatch, weak cipher). Severity is high. For any flow that signs authorization messages or moves value, we will not recommend proceed while this finding is present. The attack surface is too obvious.
rep.economic_skin — fires positively when the endpoint is actually serving a paid x402 surface (it responded to a 402 challenge with a valid accepts block priced in USDT0 on X Layer). It is a quiet but powerful signal: an agent accepting real payments has at least some cost to misbehaving. Reputation sub-score jumps meaningfully when this finding lights up.
These codes aren't decoration. They appear in the verified report, get hashed into the keccak256 commitment, and get anchored on 0G Storage. If you ever want to dispute or reproduce a score, the finding list is where you start — see the EVIDIQ skill for the full schema.
Where the Score Can Be Wrong
Honest limitations, because specs without them are sales material.
Probe timeouts are not the same as unreachability. We built EVIDIQ's probe to be bounded at ~6 seconds and ride your typical network path. If the agent's endpoint is slow, regionally distant, or briefly under load, we record cap.unreachable and the capability sub-score caps at 30 — even though the agent might be perfectly fine on retry. Same inputs, same formula, same low score. We surface the timestamp and the probe target in the report so you can decide whether to re-run.
A fresh, legitimate agent will score low on reputation by construction. Reputation today is derived from identity anchors and live signals (paid x402 surface, age, consistency). A 12-hour-old agent with no transaction history has barely any. There's no historical on-chain reputation ledger pulling it up yet. That doesn't mean the agent is risky — it means we don't have evidence either way. The recommendation engine is calibrated to treat "low reputation" as "insufficient evidence," not "hostile."
Signals drift. The score is a snapshot. We don't claim to score an agent every second of every day; we score it on request, with fresh probes. Re-running the verifier is cheap (one paid verify_agent call via x402), and we expect active agents to be re-scored as conditions change. If you cache a score for hours, that's a caching policy you own — not ours.
These edges won't surprise anyone who's shipped real infrastructure, but they're worth saying out loud. The score is the output of a deterministic pipeline applied to a point-in-time observation — nothing more, nothing mystical.
To reproduce any EVIDIQ verdict yourself:
- Re-fetch the agent's inputs — the EVM address, ERC-8004 id, endpoint, and TLS state.
- Recompute each sub-score and apply the 30/30/20/20 weighting from the formula above.
- Recover the EIP-191 signer and confirm the keccak256 hash matches the report anchored on 0G Storage.