Read Part One: Blockchain and Generative AI Need Each Other

and Part Three Limitations of Blockchain-Based AI Verification, and How They Could Be Solved

In theory, it all works together very well. In practice, the technology exists or is underway. In reality, there are still some major flaws which we will explore in the third part of this series. But here’s the verification chain: AI could produce a claim. A second AI, operated independently, could test it. Ethereum could then certify that the verification occurred, preserve the evidence used and record the result.

The concrete infrastructure, standards, and public advocacy for using ledgers as an identity, provenance, attestation, and accountability layer for AI agents are overwhelmingly coming from the blockchain world: Ethereum Foundation teams, MetaMask, Coinbase, Eigen Labs, Nethermind/ChaosChain, and related crypto projects. ERC-8004 and the surrounding stack are the clearest example.

The AI world is generating the demand, through agent protocols (MCP, A2A), safety incidents that expose ownership and verification gaps, and occasional papers noting risks in agent economies, but it is not yet driving the public-ledger solutions. Major labs remain focused on internal safeguards, evaluations, and permissions rather than treating shared blockchains as a primary governance or verification tool.

There is selective bridging (Google’s contribution to ERC-8004 being the strongest), but the direction of travel is still primarily blockchain reaching toward AI agent problems, not the reverse.

The process could look like this:

AI producer → claim or action package → independent AI verifier → signed result → Ethereum attestation

The technology required for every stage already exists. What does not yet exist is a widely accepted network of independent AI verifiers, shared standards for evidence and agreement about who is responsible when verification fails.

Ethereum would certify the verification event. It would not declare the underlying claim eternally true. That may sound like a limitation. It is actually what makes the idea defensible, and it still relies on trust.

How the process would work

1. The first AI produces a claim or takes an action

The first AI would create a structured record containing:

• the exact claim or action;
• the evidence it relied on;
• when that evidence was retrieved;
• the model and software version involved;
• the agent’s owner and operating mandate;
• its confidence in the result.

A cryptographic hash would identify that exact package. The evidence itself could remain in the company’s systems, while its hash established that it had not subsequently been replaced or altered.

At this stage, the output would still be treated as a claim. The producing AI would not be allowed to certify its own work.

2. A second AI investigates independently

The second AI would receive the claim and attempt to verify it through its own research process.

It could confirm that the sources exist, determine whether they support the precise wording, search for contradictory evidence and identify assumptions that the first system omitted.

The verifier would then produce one of several possible findings:

Verification result	Meaning	Appropriate response
Supported	Available evidence supports the claim	Permit the proposed use or action
Contradicted	Reliable evidence conflicts with the claim	Reject the claim or block the action
Cannot be verified	The evidence is insufficient or inaccessible	Pause and request the missing evidence
Disputed	Credible sources or verifiers disagree	Escalate to another verifier or a human
Expired	The verification is no longer current	Repeat the verification

This is more useful than forcing every investigation into a binary true-or-false result.

3. Ethereum records the verification

The verifier would sign an attestation containing:

• the claim hash;
• a hash of the evidence it examined;
• the producer’s identity;
• the verifier’s identity;
• the verification method;
• the result;
• the date and time;
• the period for which the result remains valid;
• any subsequent challenge, correction or revocation.

The full evidence would not need to be published on Ethereum. Sensitive documents could remain private. The blockchain would preserve their cryptographic fingerprints and the signed account of what the verifier concluded.

Anyone later reviewing the claim could confirm that the evidence had not changed and that the named verifier had signed that particular result.

“Cannot be verified” becomes valuable information

The most important result may be cannot be verified.

AI systems are generally expected to answer. When the evidence is incomplete, they remain under pressure to produce something that resembles a conclusion. A verification system needs to make stopping a legitimate outcome.

The verifier would identify the specific gap preventing verification. For example:

• no authoritative primary source exists;
• the relevant record is private or inaccessible;
• the available sources contradict one another;
• every apparent source traces back to the same unsupported assertion;
• the information is outdated;
• a necessary document or timestamp is missing;
• the claim is too broad or ambiguous to test;
• the verifier lacks the required specialist capability.

That gap report would be signed and recorded with the attempted verification.

A company would then know exactly why the claim could not be used. A later verifier could return to the identified gap instead of repeating the whole investigation. A human reviewer could request the missing document. A smart contract could prevent an agent from acting until the required evidence appeared.

The system would therefore record the boundaries of knowledge as well as successful verification.

It would show what could not be established, why it could not be established and what would be needed to change that result.

What Ethereum would, and would not, establish

Ethereum is especially useful here because it can create a common record among parties that do not fully trust one another.

Ethereum could establish	Ethereum could not establish
The exact claim that was submitted	That the real-world claim is unquestionably true
Which agent or company submitted it	That the producer acted competently
Which verifier examined it	That the verifier was genuinely independent
Which evidence and method were used	That the original source was accurate
When the verification occurred	That the claim remains true indefinitely
Whether the record was later changed	That the reasoning behind the result was sound
Whether the result was challenged, revoked or expired	That several verifiers did not share the same blind spot

The blockchain would make the process attributable and tamper-evident. The quality of the result would still depend on the evidence and the verifier.

An incorrect verification can be recorded immutably just as easily as a correct one. Ethereum supplies provenance. It does not eliminate the need for judgment.

The second AI must actually be independent

A second session with the same model would not provide meaningful independence.

Two AIs may repeat the same mistake because they share training data, retrieval infrastructure or source material. Three verifiers consulting the same incorrect database still have one underlying point of failure.

A credible verification system would therefore require separation across several dimensions:

• different organizational operators;
• different signing identities;
• different model families where possible;
• independent retrieval processes;
• different source sets;
• no access to the first AI’s confidence or private reasoning before verification.

The verifier could also be selected randomly from an approved pool after the claim had been committed, preventing the producer from choosing whichever verifier was most likely to agree.

High-stakes claims could require a two-of-three quorum. Medical, legal, employment or significant financial decisions could also require authoritative records and human approval.

This is an AI version of Ethereum’s existing oracle problem: blockchains can preserve external information once it arrives on-chain, but they cannot directly inspect the outside world and guarantee that the information was correct.

The same architecture can verify agentic behaviour

The process also applies to actions.

A company could assign an agent an Ethereum identity connected to a company-controlled smart account. The agent’s operating policy would specify what it was permitted to do: which tools it could use, which records it could modify, how much it could spend and when it required human approval.

Every action taken through a controlled tool gateway could generate a signed receipt. The receipt would identify the agent, the applicable policy, the requested action, the tool used, the outcome and any human authorization.

An independent verifier could then compare the activity with the mandate.

In the gym leaderboard incident described in Part One, the record could have answered a series of questions that otherwise become difficult to untangle:

Question	Record that could answer it
Who owned the agent?	Agent identity and controlling company account
What was the agent asked to do?	Signed task request
Was it allowed to modify the leaderboard?	Applicable policy and permissions
Which credentials did it use?	Tool-gateway receipt
Did a human authorize the action?	Approval signature
Did the owner benefit?	Resulting account or ranking change
Did the action violate its mandate?	Independent verification attestation

A policy-enforcing gateway might have blocked the change before it occurred. If it succeeded, the audit record could still classify it as unauthorized and identify the parties responsible for granting the agent access.

This is how ownership becomes operational. The system would connect the agent’s behaviour to the company that deployed it, the people who defined its mandate, the systems that supplied its credentials and the verifier that assessed its conduct.

The Ethereum components already exist

A company would not have to build the entire system from nothing.

Requirement	Available or emerging Ethereum component	Current role
Agent-controlled account with company oversight	Safe Smart Accounts	Spending limits, multiple signers, approved addresses and human approval
Signed verification records	Ethereum Attestation Service	Custom on-chain or off-chain attestations
Agent identity and reputation	ERC-8004	Proposed identity, reputation and validation registries
Independent validation requests and responses	ERC-8004 Validation Registry	Records work submitted for validation and the validator’s response
Specialized AI-agent security verification	ERC-8126	Finalized standard covering agent wallets, code, applications and media
Affordable public recordkeeping	Ethereum Layer 2 networks	Batching and anchoring activity at lower cost

ERC-8004 remains a draft, but its Validation Registry is remarkably close to this proposed process. It allows an agent to submit work for verification, attach a hash of the underlying material and receive a response from an identified validator.

That validator could be another AI, a human expert, a group of staked participants, a system that re-executes the work or a cryptographic verifier.

ERC-8126 has reached final status. Its scope currently concerns the security and authenticity of AI agents rather than general factual verification, but it establishes the same basic pattern: independent providers evaluate an agent and post signed results to a validation registry.

What is the timeline?

A company could begin building this now.

Stage	Realistic estimate from August 2026
Demonstration using two AI providers and an Ethereum Layer 2	2–6 weeks
Production pilot in a narrow field with authoritative sources	3–6 months
Network involving several independent verification companies	12–24 months
Widely accepted cross-industry verification network	2–4 years
Universal blockchain certification of accuracy	No plausible timeline

The engineering is not the largest obstacle. The harder questions concern verifier independence, evidence standards, privacy, liability, reputation, disputes and the point at which a human must intervene.

A useful system would provide a certified chain of verification. It would distinguish supported claims from contradicted, disputed, expired and unverifiable ones. It would preserve the gaps instead of hiding them. It would connect agentic actions to the authority under which they were performed.

AI would give blockchain a vast new category of consequential activity requiring durable provenance. Blockchain would give AI a shared record of evidence, verification and ownership. The system would not tell us, with finality, what is true. It would tell us who made the claim or created the action, who checked it, what they could not establish and who chose to act on it anyway.