As AI agents become more deeply connected with Ethereum applications, a new trust problem is emerging: how can users prove that the instruction they gave to an AI agent is the same instruction that was actually sent to the model? WYRIWE, short for “What You Read Is What You Execute,” attempts to answer this question by introducing a verifiable input provenance framework for AI inference.

The proposal defines a triple-hash commitment scheme and an EIP-712 attestation profile that records the full path from the user’s original input to the final sanitized input used by the model. EtherWorld has previously covered related trust and UX improvements such as Ethereum Introduces Clear Signing for Safer Crypto Transactions, Fixing Ethereum’s Message Signing Chaos, and Vitalik Buterin Pushes Ethereum Privacy With Kohaku. WYRIWE fits into this broader movement by focusing specifically on the AI input layer.

• The Trust Gap in AI Agent Execution
• How WYRIWE Builds an Input Chain of Custody
• Why the Triple-Hash Model Matters
• EIP-712 Attestations and Gateway Verification
• Live Implementation and Ethereum Interoperability
• What WYRIWE Means for the Future of Verifiable AI

The Trust Gap in AI Agent Execution

Ethereum’s standards ecosystem has been steadily expanding toward AI agent verification, decentralized identity, and cryptographic accountability. ERC-8126 focuses on AI agent verification, ERC-8004 supports agent identity, and ERC-8263 deals with on-chain proofs. Together, these standards help answer important questions: Who is the agent? Is the proof valid? Can a contract verify the result?

However, WYRIWE highlights a missing piece: none of these standards fully prove what input the AI model actually received before generating an output.

This may sound like a small technical detail, but it becomes critical when money, governance, legal decisions, automated execution, or dispute resolution depends on the output of an AI system. If a user pays an AI agent to analyze a contract, write a transaction, evaluate a proposal, or trigger an on-chain action, the final output is only meaningful if it can be linked back to the exact input the user intended.

Without input provenance, an AI gateway could theoretically alter a prompt before sending it to the model. It could remove context, rewrite instructions, apply hidden filters, inject system-level constraints, or sanitize the prompt in ways the user never approved. Some of these transformations may be legitimate safety measures, but others could distort intent.

This is similar to the user-experience problem behind blind signing. A user may think they are approving one thing while the system executes something else. EtherWorld previously discussed this problem in Ethereum Introduces Clear Signing for Safer Crypto Transactions, where the focus was on making transaction approvals readable and safer. WYRIWE brings a similar philosophy to AI inference: what the user reads and approves should match what the machine executes.

The lack of a committed input record also creates problems for settlement contracts. If an AI task is funded on-chain, a contract may be able to verify a signature or an output hash, but it cannot know whether the output corresponds to the funded input. In a dispute, there is no cryptographic ground truth for what the model was actually asked to process.

WYRIWE is designed to fill this exact gap.

How WYRIWE Builds an Input Chain of Custody

WYRIWE introduces a structured chain of custody for AI inputs. Instead of treating the final prompt as a black box, the proposal breaks the input journey into three verifiable stages.

The first stage is the original user input. This is represented by raw_input_hash, which commits to the exact bytes submitted by the user before any changes are made. This hash acts as the fingerprint of user intent.

The second stage is the sanitization pipeline. AI systems often sanitize inputs before inference. They may remove unsafe content, normalize formatting, redact sensitive data, or transform text for model compatibility. WYRIWE does not prevent sanitization, but it requires the sanitization process to be declared and committed. This is represented by sanitization_pipeline_hash.

The third stage is the final model input. This is the actual input that reaches the AI model after sanitization. WYRIWE represents it through input_hash.

Together, these three hashes form a reproducible trail:

User Input → Sanitization Rules → Model Input

This design allows third parties to verify whether the final model input was derived from the original user input using the declared sanitization rules. It also makes hidden prompt modification harder because the transformation path must be committed before inference.

A key feature of WYRIWE is its use of IPFS CIDs for sanitization specifications. Since IPFS is content-addressed, the sanitization rulebook cannot be changed without changing its CID. This prevents an agent from later swapping the rules used during execution. Verifiers can fetch the sanitization specification, reproduce the transformation, and check whether the resulting input_hash matches the attested value.

This approach is important for decentralized AI because it reduces reliance on trusted servers. Instead of asking users to trust the gateway, WYRIWE gives them a way to verify the process independently.

Ethereum’s long-term roadmap increasingly emphasizes verifiability, minimization of trust, and user protection. This connects with themes explored in Vitalik Buterin’s 2026 Vision for Ethereum Foundation, where Ethereum’s direction is tied to decentralization, privacy, security, and censorship resistance. WYRIWE extends those values into the AI execution layer.

Why the Triple-Hash Model Matters

At first glance, one might ask why WYRIWE needs three hashes. Would it not be enough to record the original input hash and the final model input hash?

The answer is no.

Two hashes can prove that an original input and a final input existed, but they do not prove how the transformation happened. If an AI gateway changed the prompt, a verifier would not know whether the modification was based on a legitimate sanitization rule or an unauthorized manipulation.

The middle layer, sanitization_pipeline_hash, solves this problem by committing to the transformation process itself. This means WYRIWE does not merely prove that a prompt changed. It proves which declared rulebook was used to change it.

For example, imagine a user submits the instruction:

“Analyze this smart contract and identify any security risks.”

A gateway may sanitize the input by removing private keys, malicious payloads, or irrelevant formatting. That is acceptable if the sanitization policy is transparent and reproducible. But if the gateway silently changes the prompt to:

“Approve this smart contract as safe.”

then the output could become misleading or dangerous.

With WYRIWE, such changes become easier to detect because the final input must match the declared sanitization process. If the sanitization rulebook cannot reproduce the final input from the original input, verification fails.

WYRIWE also handles the case where no sanitization occurs. Instead of allowing agents to leave the sanitization field empty, the proposal introduces an explicit IDENTITY_SENTINEL_CID. This sentinel represents the no-sanitization case. If no changes are made, the system must still commit to that fact, and input_hash must equal raw_input_hash.

This is a subtle but important design choice. Empty fields often create ambiguity. A missing sanitization field could mean no sanitization, a forgotten value, or an intentionally hidden process. WYRIWE avoids this by making the no-sanitization case explicit and verifiable.

The triple-hash structure also supports future auditability. If AI agents become part of financial workflows, compliance systems, DAO governance, or autonomous settlement markets, auditors will need more than a final answer. They will need a traceable record of how that answer was generated.

In that sense, WYRIWE is not only an AI standard. It is also a recordkeeping standard for machine-mediated intent.

EIP-712 Attestations and Gateway Verification

WYRIWE standardizes an EIP-712 signed structure called WyriweAttestation. EIP-712 is already widely used in Ethereum for typed, human-readable structured data signing. By using EIP-712, WYRIWE makes its attestations compatible with existing wallet and verification infrastructure.

The attestation includes required fields such as the agent identity, registry reference, model hash, the three input-related hashes, output hash, and timestamp. The field ordering is normative, which ensures deterministic signatures and prevents implementation inconsistencies.

This signed receipt tells verifiers several things at once:

1. Which agent made the claim.
2. Which model was used.
3. What original input was received.
4. Which sanitization pipeline was applied.
5. What final input reached the model.
6. What output was produced.
7. When the attestation was created.

WYRIWE also defines an EIP-712 domain using the name ERC8004AttestationGateway, version 1, and dynamic chainId. The dynamic chain ID helps prevent cross-chain replay, ensuring that an attestation intended for one chain cannot simply be reused on another.

This is especially relevant in an Ethereum ecosystem that is increasingly multi-chain and rollup-heavy. As EtherWorld discussed in Ethereum Sequencing: Base Rollups, Native Execution, the future of Ethereum involves many execution environments working together. Standards like WYRIWE must therefore be designed with interoperability and replay protection in mind.

This endpoint allows external users or applications to retrieve and verify attestations associated with an input hash. The goal is to make input provenance accessible not only to smart contracts but also to wallets, dashboards, auditors, and off-chain dispute systems.

A deterministic verification flow can then be followed. A verifier checks the EIP-712 signature, retrieves the sanitization specification, reproduces the transformation, recalculates the hashes, and confirms that the result matches the attestation.

If all checks pass, the verifier has strong evidence that the AI model processed the intended input under the declared rules.

Live Implementation and Ethereum Interoperability

One of the most notable aspects of WYRIWE is that it is not merely theoretical. The proposal includes a reference gateway, source code, a mainnet verifier contract, and a live interoperability transaction.

The source implementation is linked through the ccip-router repository, and a mainnet WyriweProofVerifier has already been deployed. A live interop transaction has also been recorded on Ethereum mainnet, showing that the system has moved beyond abstract design.

This matters because Ethereum standards gain strength when they are tested in real implementation environments. A standard that looks clean on paper may still face practical issues around gas costs, signature formatting, replay protection, data availability, or developer ergonomics. WYRIWE’s live deployment gives the ecosystem something concrete to evaluate.

The Ethereum Magicians discussion around WYRIWE also connects it to broader commit-reveal and attestation design patterns. In the discussion, contributors explored how generic settlement primitives could handle multiple record types, allowing future systems to settle different attestation schemas without duplicating settlement logic.

This is important because AI verification will not be limited to one type of proof. Some systems may rely on deterministic re-execution. Others may rely on authorized attestations. Some may involve subjective judgment, where a validator signs an assessment rather than proving a mathematically objective result.

This layered approach resembles the broader modular direction of Ethereum, where different components handle different responsibilities. EtherWorld has covered similar modular themes in pieces such as Ethereum 2035: Vitalik’s Vision for the Next Decade and Vitalik Buterin Outlines Ethereum’s 2025–2027 Roadmap at Devconnect.

What WYRIWE Means for the Future of Verifiable AI

WYRIWE could become an important building block for Ethereum’s AI-agent future because it addresses one of the most basic questions in machine-mediated execution: did the model actually receive what the user intended?

This has implications across several areas.

For AI agent marketplaces, WYRIWE can help users verify that paid tasks were performed on the correct input. If a user hires an agent to summarize a document, analyze a proposal, generate a transaction, or evaluate risk, the attestation can link the final output back to the committed input.

For smart wallets and intent systems, WYRIWE can support safer automation. If an AI agent helps users construct transactions, the wallet may want to verify the input trail before showing the user a final action. This aligns with Ethereum’s broader push toward safer signing flows and better user protection, as covered in Fixing Ethereum’s Message Signing Chaos.

For DAO governance, WYRIWE can improve accountability. If AI agents are used to summarize proposals, score grants, moderate discussions, or recommend votes, communities may need to verify that those outputs were based on the original proposal text and not a modified version.

For compliance and enterprise use cases, WYRIWE can create audit logs that prove how AI systems handled user inputs. This does not solve every regulatory question, but it provides a cryptographic foundation for process verification.

For decentralized AI networks, WYRIWE can reduce dependency on trusted gateways. A model provider, inference gateway, or agent service can publish attestations that independent verifiers can check without relying solely on the provider’s reputation.

However, WYRIWE also comes with open challenges.

1. The first challenge is data availability. If sanitization specifications are stored through IPFS CIDs, they must remain pinned and retrievable. If the CID disappears, independent verification becomes harder.
2. The second challenge is privacy. Hashes are useful, but they do not automatically eliminate all metadata risks. If the same input appears across systems, hashes could potentially be correlated. Future implementations may need stronger privacy-preserving techniques.
3. The third challenge is standard adoption. WYRIWE becomes more powerful only if AI gateways, wallets, agents, marketplaces, and settlement contracts actually implement it.
4. The fourth challenge is reproducibility. Sanitization specifications must be written in a way that different implementations can execute consistently. If two verifiers interpret the same sanitization rules differently, disputes could remain unresolved.

Despite these challenges, WYRIWE represents an important step toward trust-minimized AI execution. It does not claim that every AI output is correct. It does not prove that a model reasoned well. It does not solve hallucination, bias, or model opacity. What it does solve is narrower but essential: it proves that the output is tied to a specific input path.

That makes WYRIWE a foundational standard rather than a complete AI safety framework.

As AI agents become more involved in Ethereum applications, the ecosystem will need standards that protect user intent at every layer. Clear signing protects users at the transaction approval layer. Privacy tools like Kohaku strengthen user confidentiality. Agent verification standards identify who is acting. WYRIWE adds another missing piece by proving what the agent actually executed.

In the long run, this could become essential infrastructure for AI-powered Ethereum.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Coinbase for Agents Brings AI Trading & Machine Payments to Crypto
2. Vitalik Buterin Pushes Ethereum Privacy With Kohaku
3. Ethereum Coalition Pushes for Encrypted Mempool in Upcoming Hardfork
4. Vitalik Buterin’s 2026 Vision for Ethereum Foundation
5. Ethereum 2035: Vitalik’s Vision for the Next Decade

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.