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.