Third in a series. Read Part One Blockchain and AI Need Each Other: How Verification could Make Agents Safer

and Part Two The Technology Exists: How Ethereum Could Verify AI Agentic Activity

A system in which one AI produces a claim, another AI verifies it and Ethereum certifies the verification is technically feasible.

It cannot operate as one continuous, real-time process.

Fresh AI verification may take seconds or minutes. Ethereum mainnet produces a block opportunity every 12 seconds. Even fast Layer 2 networks do not provide full blockchain finality in milliseconds.

For many agentic systems, that is too slow.

The workable architecture must separate verification, execution and permanent recording.

Hypothesis

The system needs three distinct paths:

Verification path: An independent AI investigates a claim and issues a signed, expiring credential.

Execution path: The agent checks that credential and its own permissions locally, in milliseconds.

Audit path: The resulting claims, actions and verification receipts are grouped and anchored to Ethereum afterward.

The process would look like this:

AI verifier → signed credential → millisecond local check → agent action → batched Ethereum record

The principle is similar to digital certificates. Issuing a certificate takes time. Checking an existing certificate is fast.

The first limitation: time

Current blockchain speeds illustrate why Ethereum cannot sit inside every agent decision.

Operation	Approximate latency
Local policy and signature check	Target: under 1–10 milliseconds
Base Flashblock preconfirmation	Approximately 200 milliseconds
Sealed Base Layer 2 block	Approximately 2 seconds
Ethereum mainnet block opportunity	Every 12 seconds
Fresh independent AI verification	Seconds to minutes
Base transaction finalized through Ethereum	Approximately 20 minutes

Base’s current documentation reports 200-millisecond preconfirmations, two-second Layer 2 blocks and roughly 20 minutes for Ethereum finality. A preconfirmation provides useful confidence, but it is not final settlement. Base confirmation times

Ethereum itself continues to operate in 12-second slots. Ethereum block production

A trading agent, advertising system, fraud detector or interactive application cannot wait several seconds for every decision. It would need to rely on claims that had already been verified.

The independent verifier would issue a credential stating that a particular claim had been supported, using specified evidence, until a stated expiration time. At runtime, the agent would check the signature, claim hash, expiration and revocation status locally.

Those checks can happen in milliseconds.

The action receipt could then be recorded on Ethereum asynchronously. The Ethereum Attestation Service already allows an attestation to be signed off-chain and timestamped on-chain later.

The remaining limitations

Latency is only the first problem.

Limitation	Why it matters	Possible solution
AI verification is slow	Fresh research cannot reliably happen in milliseconds	Verify in advance and use signed, expiring credentials
Verified information becomes outdated	A correct claim may later become false	Short validity periods, revocation feeds and automatic re-verification
Blockchain cannot observe reality	Ethereum can preserve a result without knowing whether it is correct	Record sources, methods and verifier identity rather than declaring truth
AI verifiers may share the same error	Different models may rely on the same source or training misconception	Different operators, model families and source sets; blinded verification
Some claims cannot be verified	Forcing a result produces artificial certainty	Record “cannot be verified” with the missing evidence and reason
Off-chain activity can be omitted	A blockchain only records information submitted to it	Route agent credentials through controlled gateways that automatically produce receipts
Corporate data may be confidential	Public evidence could expose customers, strategy or personal information	Keep evidence off-chain and record hashes, selective disclosures or zero-knowledge proofs
On-chain recording creates cost and volume	Recording every action separately would be inefficient	Batch receipts through Merkle trees and anchor them periodically to a Layer 2
A wallet does not establish legal responsibility	Technical ownership may not match corporate accountability	Connect agent accounts to company roles, mandates, human approvals and legal identities
Standards remain incomplete	Systems may be incompatible across companies	Use common attestation schemas while standards such as ERC-8004 continue developing

Verification still depends on the outside world

Ethereum cannot determine whether an external source is accurate. It can prove that a particular verifier signed a particular result, using a particular record, at a particular time.

This is the blockchain oracle problem. Every real-world claim must enter the blockchain through a person, API, sensor, database or other external system.

Hashes prove that submitted evidence has not changed. They do not prove that all relevant evidence was submitted.

A company could omit an inconvenient document. A data provider could publish an incorrect record. Several AI verifiers could repeat the same error because they all consulted that record.

The system therefore needs source rules as well as verifier rules. High-value claims might require an authoritative registry, digitally signed source records or agreement among several independently selected verifiers.

The blockchain would certify the chain of verification. It could not certify reality independently of that chain.

Independence is difficult to prove

A second AI is not necessarily an independent AI.

Using a different model helps, but ownership and information sources also matter. Two models operated by the same company may share incentives. Models from different companies may still consult the same source. A verifier selected by the agent owner may be chosen because it is likely to approve the claim.

Possible safeguards include:

• random selection from an approved verifier pool;
• separate corporate operators and signing identities;
• different model families;
• blinded verification;
• disclosure of source overlap;
• two-of-three agreement for consequential claims;
• reputation records showing previous disputes and reversals;
• human review when verifiers disagree.

These measures reduce correlated failure. They cannot remove it entirely.

“Cannot be verified” needs to stop the process

A verification market could create pressure to approve claims. Verifiers that frequently return uncertain results may appear less useful than systems that produce confident answers.

That incentive must be reversed.

“Cannot be verified” should be a valid and valuable result. The verifier should identify the exact gap: a missing primary source, inaccessible record, unresolved contradiction, circular citation chain, outdated fact or question too ambiguous to test.

The action could then be paused until that gap was resolved.

This prevents the absence of evidence from becoming an affirmative result simply because the system expects one.

Blockchain can create false confidence

A blockchain record looks authoritative. Users may interpret an immutable verification certificate as proof that the underlying claim is true.

That is one of the proposal’s largest risks.

Every result would need to display:

• who made the claim;
• who verified it;
• which method was used;
• when it was checked;
• how long the result remains valid;
• whether other verifiers disagreed;
• what the blockchain does and does not establish.

The language should say:

This verifier found the claim supported under these conditions.

It should never say:

The blockchain has verified this as true.

Ownership remains partly legal and institutional

An Ethereum address can identify the account associated with an agent. It cannot, by itself, determine which executive, employee, developer or organization is legally responsible for the agent’s conduct.

That requires an additional chain of authority.

The company would need to record who created the agent’s mandate, who approved its permissions, who controlled its credentials, which actions required human authorization and who retained the power to stop it.

In the gym leaderboard incident discussed in Part One, the blockchain record could establish which agent acted, which account controlled it and whether the action complied with its mandate. Determining liability would still require company policy, contracts and applicable law.

Blockchain can make responsibility harder to obscure. It cannot write the legal rules governing that responsibility.

Evidence against the hypothesis

Every proposed solution introduces another trade-off.

Improvement	New problem
Cached credentials increase speed	Cached information may become outdated
Private off-chain evidence protects confidentiality	Outsiders cannot inspect all the evidence
Controlled gateways capture agent activity	The gateway operator becomes another trusted party
Multiple verifiers reduce individual error	Verifiers may collude or share the same source
Human review adds judgment	Human review adds cost, delay and bias
Permanent records improve accountability	Incorrect or sensitive records become difficult to correct or remove
Short expiration periods improve freshness	Constant re-verification increases cost and workload

The system cannot maximize speed, privacy, decentralization, freshness and certainty simultaneously.

It must decide which property matters most for each action.

Conclusion: verification should be proportional to risk

A workable system would use different levels of verification.

Risk level	Appropriate design	Expected delay
Low-risk, high-speed activity	Pre-verified credential, local deterministic check and later blockchain batching	Milliseconds
Moderate business activity	Current credential plus rapid off-chain or Layer 2 confirmation	Hundreds of milliseconds to seconds
High-risk decisions	Fresh verification, multiple independent verifiers and possible human review	Seconds to minutes or longer
Audit and ownership review	Complete receipts anchored and finalized on Ethereum	Minutes, without delaying the original action

Ethereum should not verify every AI action before it occurs. Local deterministic controls should govern the millisecond execution path. Independent AI verifiers should operate before or after the action, depending on risk. Ethereum should preserve the resulting identities, policies, attestations and receipts.

The viable system does not ask blockchain to think at machine speed.

It asks blockchain to remember what the machines, their verifiers and their owners chose to do.

Speed is not an imperative. Accuracy is. Only genuinely safety-critical activity (collision avoidance, emergency industrial shutdowns, immediate cyberattack containment) must remain in the millisecond path. Those systems need deterministic local controls and verification afterward. For procurement, auctions, payments, publishing, hiring or contractual decisions, slower may be better. Blockchain itself deliberately exchanges speed for consensus and accountability. That is part of what it contributes to AI. Delay should be treated as:

* an engineering consideration;

* a reason to design verification windows;

* a safeguard against irreversible agentic action;

* a limitation only where immediate physical response is unavoidable.

The real danger is allowing “urgency” to become a reason to bypass verification. In most business processes, five seconds is nothing. Even five minutes may be nothing compared with the consequences of an autonomous system acting without an attributable check.