Output validation, smart contract audit, attestation verification, TEE and zkML verifiers, and compliance agents. The accountability layer that turns claims about agent behaviour into auditable, on-chain evidence.
A Verification Agent is an autonomous software agent whose primary function is to verify specific claims, outputs, transactions, or behaviour produced by other agents. Where Identity & Trust establishes the substrate (who an agent is, what reputation it carries), Verification operates on top of that substrate to answer the more specific question: did this thing actually happen as claimed, and is it actually correct?
Verification is the smaller-cohort cousin of Identity & Trust. Both categories interlock with ERC-8004: the Identity and Reputation registries are settled and live, but the Validation Registry portion of the spec is under active revision with the TEE community as of mid-2026, and a follow-up spec update is expected later this year. The smaller agent count for this category reflects standards-track immaturity rather than a lack of demand: the demand for verification primitives is large and growing, but the standards layer is not yet fully crystallised.
The Validation Registry workflow is mature enough to anchor concrete commercial prototypes (ChaosChain Genesis Studio is the canonical example) but the spec remains under active revision in collaboration with the TEE community. As that work lands, the Verification cohort is expected to grow significantly — both through new validator agents registering against the Validation Registry, and through reclassification of agents currently caught at the Identity / Verification boundary.
In the Phase 2.2 classification run, Verification Agents were anchored on ProblemManager, AgentCoin, and EAS (Ethereum Attestation Service). The first two are specific contract anchors used in the AHM lookup table; EAS is a general-purpose attestation primitive that also serves Identity & Trust use cases — the same primitive can anchor both depending on what is being attested. The methodology is documented in the POC summary; subsequent classification phases are expected to expand the anchor set toward the ERC-8004 Validation Registry once that spec stabilises.
Verify task outputs produced by other agents — typically via re-execution, stake-secured verification, or evaluator workflows. The ERC-8004 Validation Registry pattern fits here.
Autonomous code review, vulnerability detection, and risk scoring on smart contracts. Boundary case with Research: classified here when output is a binary verdict, in Research when output is a scored report for human reading.
Agents that consume EAS attestations or W3C Verifiable Credentials, check validity, and propagate trust signals to downstream consumers. The connective tissue between attestation primitives and agent decisions.
Verifiers using Trusted Execution Environments (Intel TDX, Phala Cloud) or zero-knowledge machine learning proofs to provide cryptographic attestation that specific computation ran on specific inputs without tampering.
Agents checking regulatory compliance, KYC/AML, content authenticity, or product provenance. Increasingly important as agents transact in regulated contexts and brand-authenticated commerce.
The agents and protocols below are well-known illustrations of the Verification category as defined above. ChaosChain Genesis Studio is the most fully-realised end-to-end prototype anchored on ERC-8004's Validation Registry; the others demonstrate adjacent verification patterns that also fit the category. Several entries operate as platforms rather than discrete agents — appropriate for a category where the unit of analysis is often the verification protocol, not the registrant.
Described as the first end-to-end commercial prototype of ERC-8004. Implements a Triple-Verified Stack: Google AP2 Intent Verification ("did the human authorise?"), ChaosChain Process Integrity ("was the code executed correctly?") via local code hashing and optional TEE attestations, and ERC-8004 Adjudication ("was the outcome valuable?") via the Validation Registry. Demonstrates the three-agent commercial pattern (server / validator / client) with stake-secured verification gating USDC escrow release. The "no work, no pay" guarantee is enforced cryptographically rather than relationally — the headline economic feature of the category.
Trust intelligence platform for AI agents with an ERC-8004 bridge: identity stamps, 0–100 reputation scoring, forensic audit trails, and x402 micropayments. Provides lookup, trust check, and linking endpoints for ERC-8004-registered agents. Open-source Node.js server with MCP tools, HMAC signature verification, and admin audit endpoints. Representative of the verification-as-a-service pattern: an agent commissions a verification check and pays per call rather than running the verification itself.
EAS is general-purpose attestation infrastructure — included on the Identity & Trust page as a credentialing primitive and on this page as a verification primitive, because the same protocol serves both depending on what is being attested. Agents acting as attestation verifiers consume EAS-issued claims (audit results, capability proofs, compliance status) and use them to make trust decisions about counterparties. The neutrality of EAS as tokenless public-good infrastructure makes it suitable as the verification substrate for high-value verticals.
The validator role of Phala's ERC-8004 TEE Agent stack: agents running inside Intel TDX TEEs that produce cryptographic attestations of correct execution. Where ERC-8004's reputation layer relies on social signals and the validation layer relies on stake-secured re-execution, TEE validators provide a third path — cryptographic guarantees that specific code ran on specific inputs without tampering. Particularly relevant for high-stakes verification where re-execution non-determinism would otherwise be a problem.
Swiss trust infrastructure using W3C DID-based identity and Ed25519 signed Verifiable Credentials anchored on Base mainnet. Operates across seven verticals including MT Salesguard for brand and product provenance — BrandRegistryCredentials, AuthorizedResellerCredentials, and ProductProvenanceCredentials are all verifiable by shopping agents before purchase. Representative of the compliance-and-provenance verification pattern, increasingly important as agents transact in branded commerce and regulated contexts.
"No work, no pay" enforcement. The clearest commercial use case for Verification is conditional escrow: USDC locked at job creation, released only after verification confirms the work was done correctly. ChaosChain's Triple-Verified Stack demonstrates this end-to-end. The pattern eliminates a class of fraudulent chargebacks and relational disputes that would otherwise constrain agent-to-agent commerce. As Verification primitives mature, expect this to become the default rather than a special configuration.
Tiered trust matched to value at risk. ERC-8004 deliberately supports three trust models: reputation aggregation for low-stakes social interactions, crypto-economic staking for medium-stakes commercial work, and TEE / zkML attestation for high-stakes financial or sensitive-data workflows. Verification Agents are the operational layer of those models. A trader agent risking $100 might rely on reputation; a treasury agent moving $100M will require TEE attestation. The same registry serves both.
Continuous audit and re-verification. Verification is not a one-time event. As contracts upgrade, dependencies change, and operational posture drifts, previously-valid attestations become stale. Continuous-audit agents that re-evaluate on schedule, or whenever upstream conditions change, are an emerging pattern — particularly for smart contract audit and compliance verification where the cost of a missed regression is large.
Compliance and provenance for regulated commerce. Agents transacting in branded commerce or regulated contexts need verifiable claims about counterparty identity, product authenticity, and regulatory status. MolTrust-style verifiable credential infrastructure is the substrate that makes this practical without bottlenecking on per-transaction human approval. As more economic activity routes through agents, the demand for verification-as-infrastructure scales with it.
Composite 0–100 health score blending behavioural consistency, claim-vs-reality alignment, and operational stability. Calibrated for verification primitives where validator integrity is itself the unit of trust.
Full diagnostic for verifiers — operational patterns, attestation cadence, claimed verification scope vs observed activity, validator-set diversity.
Surface validator ownership clusters, attestation correlation patterns, and the agents that depend on this verifier's outputs. Designed to expose Sybil validator clusters and capture relationships.
Operational health scan for verifiers: failed-validation patterns, gas-spend anomalies, attestation degradation indicators across the validator's history.
@misc{ahm_taxonomy_verification_2026,
title = {Verification Agents --- AHM Taxonomy v1},
author = {{Agent Health Monitor}},
year = {2026},
month = {May},
url = {https://intelligence.agenthealthmonitor.xyz/taxonomy/verification},
note = {Accessed: 2026-05-07}
}
Classification methodology and category boundaries are documented in the AHM Taxonomy v1 POC summary.
Counts reflect the Phase 2.2 classification run (25 April 2026): a 1,000-agent random sample from Base mainnet wallets, of which 757 (75.7%) were classified across 6 anchored categories. Updated as new classification phases complete.