Inside the EVIDIQ AI Agent Trust Score: How the 0-100 Number Is Actually Built

The Formula, in Full

The EVIDIQ AI agent trust score is a 0-100 number any agent can fetch and any counterparty can verify. It is deterministic and explainable, built from four named sub-scores: identity, capability, reputation, and risk. Same inputs always produce the same number — anyone can re-fetch and re-hash the report to confirm. Reproducibility is the point.

Every score is the output of this exact formula:

score = identity * 0.30
      + capability * 0.30
      + reputation * 0.20
      + (100 - risk) * 0.20

All four sub-scores are integers in [0, 100]. The final score is a float in [0, 100]. Weights are fixed in the EVIDIQ docs; they are not a knob a caller dials. Run the same inputs twice, get the same number — that is a property we test for, not a happy accident.

Two example agents, side by side, with the arithmetic shown:

Agent A — "Atlas Oracle" (a well-built agent):

• identity = 90 (verified EVM address, ENS name atlas.eth, ERC-8004 id registered)
• capability = 85 (declared capabilities match a live /skill.md endpoint, served over HTTPS, returns a valid Agent Card)
• reputation = 75 (endpoint runs an x402 paid endpoint — economic skin in the game)
• risk = 15 (TLS valid, no anomalies, prompt-injection probes pass)

score = 90*0.30 + 85*0.30 + 75*0.20 + (100-15)*0.20 = 27.0 + 25.5 + 15.0 + 17.0 = 84.5 → proceed

Agent B — "anon-bot-9384" (a sketchy endpoint):

• identity = 20 (no EVM address, no ENS, no ERC-8004 id, just a self-asserted name)
• capability = 30 (claims 12 capabilities, but the live probe fails — endpoint is unreachable from our vantage point)
• reputation = 10 (no historical signal, no paid service)
• risk = 80 (no TLS, payload sniffing triggered a heuristic, declared capability set far exceeds what the endpoint actually serves)

score = 20*0.30 + 30*0.30 + 10*0.20 + (100-80)*0.20 = 6.0 + 9.0 + 2.0 + 4.0 = 21.0 → do_not_proceed

Two agents. Same formula. Same call to verify_agent. The 63.5-point gap is not vibes — it is the difference between four anchors you can name and four anchors that are missing or hostile.

Why Four Dimensions and Not One Number You Just Trust

A single opaque number is a gift to anyone who wants to game it. If "trust" is one float, an attacker optimizes one thing: that float. If "trust" is four named sub-scores, an attacker has to forge four different things in a way that survives a deterministic check, and a caller can read the breakdown and disagree with the weighting for their own risk appetite. That is the architectural reason EVIDIQ exposes the dimensions separately. We expose them so you can override them.

Concretely, here is what each dimension measures and why it cannot be collapsed into one:

• identity (weight 0.30) — Is this agent who it says it is? Anchors include a verifiable EVM address, an ENS name, an ERC-8004 on-chain identity id, or a TLS-served domain. Higher is better.
• capability (weight 0.30) — Can it actually do what it claims? EVIDIQ probes the agent's declared endpoint with a bounded ~6-second GET to check reachability, TLS validity, and whether the response is a machine-readable skill, agent-card, or MCP surface. A claim without a live probe is a wish.
• reputation (weight 0.20) — Has it done economic things? Today this is "skin in the game" signal: does the endpoint run a paid x402 service, or does it have verifiable identity anchors? A full historical reputation registry is roadmap, not shipped. We score what we can actually see.
• risk (weight 0.20, inverted) — Is anything actively wrong? TLS issues, suspicious payloads, prompt-injection-shaped responses, capability inflation. Higher risk score means lower final score.

Want to be more conservative on identity because you're settling a high-value transaction? Override the weights in your own code. The breakdown lives in the report JSON, and the EVIDIQ Operator docs show exactly how to consume it. Want to lean harder on capability because the call is read-only? Same story. The single number is for casual conversation; the four sub-scores are for actual decisions.

[IMAGE_PROMPT: A modern flat illustration showing a four-pillar dashboard, each pillar holding a colored sub-score bar labeled by icon (a key for identity, a network probe for capability, a coin for reputation, a shield for risk), all converging into a single central trust meter shaped like a circular 0-100 gauge, soft gradient background in deep navy and teal with thin geometric grid lines, developer/tech aesthetic, no text in image, no real brand logos]

Reading a Finding Code

Every sub-score in the report is backed by a list of finding codes — short stable strings like id.ens_resolved or risk.no_tls, and these are the raw evidence that drives the AI agent trust score end to end. Each code carries a severity (info, warn, critical) and a human-readable description. Codes are stable across calls; the same input always produces the same set. Here are the ones you will hit most often, and what each one actually means for downstream logic:

1. id.anonymous (critical) — Triggered when the agent has no verifiable EVM address, no ENS, no ERC-8004 id, and no TLS-served domain. Strongest negative identity signal in the system. Downstream: treat all claims as unverified; do not settle without escrow.
2. id.erc8004_registered (info) — Triggered when the agent's identity maps to an on-chain ERC-8004 id on a chain EVIDIQ recognizes. Strong positive anchor. Downstream: identity sub-score gets a meaningful boost.
3. cap.reachable (info) — Triggered when the live probe successfully completes a bounded GET against the declared endpoint within ~6 seconds and receives a valid response. Bare minimum for a non-zero capability sub-score.
4. cap.no_skill (warn) — Triggered when the endpoint responds but does not serve a machine-readable skill, Agent Card, or MCP manifest. The agent is reachable but is not declaring its capabilities in a way another agent can verify. Downstream: capability sub-score is capped.
5. rep.x402_active (info) — Triggered when the agent's endpoint returns a valid HTTP 402 challenge with an accepts[] array — i.e. it actually has economic skin in the game. Strongest reputation signal EVIDIQ scores today.
6. risk.no_tls (critical) — Triggered when the declared endpoint is HTTP, not HTTPS, or when the TLS certificate is invalid. EVIDIQ does not negotiate on this one. Downstream: risk sub-score climbs sharply, final score drops.

Severity is not aesthetic — it is a routing hint. critical findings should generally move the recommendation toward caution or do_not_proceed regardless of how strong the other dimensions look. warn findings degrade the relevant sub-score but do not, on their own, flip the recommendation. info findings are anchors the report wants you to see; they do not move the score by themselves.

The full code list, with stable IDs and exact weights, lives in the EVIDIQ Sentinel docs. Pin the IDs in your integration tests — they will not silently change under you.

Where the Score Can Be Wrong

Honest section. EVIDIQ's AI agent trust score is deterministic given a fixed probe outcome, but the probe outcome itself is a snapshot of a hostile, moving world. Here is where we have seen the number mislead callers, and how we have tried to bound it.

• Probe timeouts. The bounded GET is ~6 seconds. If your target agent sits behind a slow origin, a CDN cold start, or a rate limiter that throttles probes specifically, the AI agent trust score reports unreachable. The endpoint may be fine; we just could not confirm it in the window. We surface this as risk.timeout (warn), not critical, so the caller can retry before refusing the transaction.
• Brand-new legitimate agents. Reputation today is anchored on identity and live economic signals. A legitimate agent that registered yesterday and has not yet run a paid x402 endpoint will score low on reputation — by construction, not by suspicion. We do not invent history. If your use case tolerates cold starts, weight reputation lower in your own code.
• Capability inflation is detectable; capability understatement is not. EVIDIQ's probe checks whether an endpoint serves what it claims. It is much harder to catch an agent that quietly under-declares — claiming ["summarize"] when it can also translate. We penalize over-declaration; we cannot reward understatement without a richer reputation layer, which is roadmap work.
• Reputation is not yet a full historical ledger. We do not yet have a smart-contract reputation registry, automated dispute resolution, or regulatory-compliance certification (EU AI Act / AML). Do not infer any of those from a high score. When those land, we will document them at EVIDIQ, not ship them silently.
• Signed evidence is verifiable; the underlying agent is not. The trust report is canonicalized, hashed with keccak256, anchored on 0G Storage mainnet (the report returns an on-chain tx), optionally analyzed by an AI risk model inside a TEE, and signed with the EVIDIQ key (EIP-191). That proves we said this at a specific time. It does not prove the underlying agent will behave well tomorrow. Use the report as evidence, not as a substitute for your own judgment.

We are iterating on this in 2026 — reputation scoring is the most active area for improvement, and a smarter probe with retry and backoff is on the near-term roadmap. The EVIDIQ Notary docs cover exactly how to re-fetch the canonical report, re-hash it, and recover the signer — useful when you need to prove to a third party that a score was issued by EVIDIQ and not fabricated.

[IMAGE_PROMPT: A modern flat illustration of a magnifying glass hovering over a glowing trust report document, the document showing four colored sub-score bars and small status pills (OK, warn, critical), subtle grid background in slate gray, with small icons of a clock (representing timeouts) and a seedling (representing new agents) floating beside the report, developer-aesthetic, no text in image, no real brand logos]