[Pre-Draft] Toward a Standard for Portable Verification of Execution Outcomes

Magicians
1

Summary

Ethereum provides strong guarantees around execution correctness and data availability.

However, it does not define a standard, system-independent way to verify a specific execution outcome as a portable claim.

As a result, verifying “what happened” remains largely a reconstruction problem, requiring the verifier to depend on the same system—or its tooling or interpretation layer—that produced the result.

Problem Statement

Given a claim:

“This specific outcome occurred”

there is no canonical way for a third party to verify that claim independently, without relying on:

  • an RPC endpoint

  • an indexer

  • a specific client implementation

  • application-layer logic applied to logs, calldata, or state

Even with direct access to chain data, the verifier must still derive the claimed outcome from execution context.

Even when the underlying data is:

  • correct

  • available

  • cryptographically sound

…the verification procedure itself is not standardized or portable.

In practice, the verifier relies on the originating system—or its interpretation layer—to establish meaning.

This implies:

verification implicitly reintroduces trust in the system that produced the result.

Existing Mechanisms

Ethereum exposes:

  • calldata

  • logs / receipts

  • state

  • Merkle / SSZ proofs

  • ZK validity proofs (in some systems)

These mechanisms provide:

  • correctness guarantees

  • data availability

  • proof that computation was valid

However, they do not define a canonical, portable procedure for verifying a claimed outcome without external interpretation of those artifacts.

Gap Definition

The gap is not:

  • access to data

  • correctness of execution

  • availability of proofs

The gap is the absence of a verification boundary.

Specifically, there is no minimal, standard way to:

  • represent an outcome deterministically

  • bind that representation to a public commitment

  • enable third-party verification without reliance on system-specific interpretation

This is not a proposal to standardize application semantics, but to standardize the verification procedure once an outcome is deterministically represented.

Motivation

Without a portable verification boundary:

  • outcome claims remain system-dependent

  • verification is not portable across environments

  • third-party validation requires shared infrastructure or interpretation layers

This limitation is often abstracted away in crypto-native contexts, but becomes significant when:

  • verification must occur outside the originating system

  • systems interoperate across domains

  • independent auditability is required

Framing

Ethereum provides strong answers to:

  • “Was computation correct?”

  • “Is the data available?”

But does not directly answer:

“Can a third party verify a specific execution outcome without relying on the system—or its interpretation layer—that produced it?”

Open Questions

  • Is there an existing canonical approach to portable outcome verification that avoids reconstruction?

  • Are logs, receipts, and proofs sufficient in practice, and if so, what is the canonical verification procedure?

  • Should a standard for portable verification artifacts be defined?

  • Where would such a standard most appropriately live (execution layer, ERC, or off-chain convention)?

  • Is this a protocol-level gap, or an inherent property of application-layer interpretation?

Intent

This is not a proposal for a specific standard.

The intent is to evaluate whether there is a recognized gap between:

execution/data guarantees and independently verifiable execution outcomes.

2

Interesting framing. My proposal sits in a very small part of the problem space you describe. Curious to see what concrete examples surface here.

1 Like
3

Tomoglava — appreciate this. Your preset_root work is a clean example of tightening inputs to execution.

A concrete case of the gap I’m pointing to:

Take a simple claim:
“User X received reward Y from contract Z at time T.”

All underlying data exists (logs, state, calldata), but a third party still has to:

• select the relevant artifacts
• interpret contract semantics
• reconstruct the outcome from execution context

Two different verifiers can follow different procedures and still be “correct.”

There’s no canonical artifact that represents that outcome itself—only the raw materials to derive it.

So verification becomes:

“re-run the system’s logic (or trust a tool that did)”

—not—

“verify a portable claim directly”

Your work reduces ambiguity at the input layer.
What’s still missing is a minimal, standard way to bind a deterministic outcome representation → public commitment, so verification becomes:

recompute → compare → confirm inclusion

independent of the system that produced it.

Curious if you’ve seen any approach that defines that boundary explicitly, or if this is inherently left to application layers.