A callable interface can show that software exposes expected function shapes. It cannot, by itself, prove that two implementations agree on permitted state changes, failure ordering, runtime identity, or the external meaning of an action.
The research claim and its non-official status
Author-published research — open proof; not an official Ethereum standard, audit, certification, or regulator-approved method. An identified author published “Can We Verify an ERC, Not Just Its Code?” on Ethereum Research on 6 September 2026 at 12:31:04 IST. The post proposes “whole-standard assurance” as a way to inspect several linked evidence layers rather than treating interface detection as conformance.
The forum is a research venue and the supporting manuscript is a preprint. Publication there does not imply Ethereum Foundation approval, adoption by the EIP process, a completed security assessment, or acceptance by a regulator.
Interface compatibility versus behavioral agreement
An application binary interface describes callable names, inputs, and outputs. Two contracts can expose the same shapes while disagreeing about when a call succeeds, which state changes occur, how failure is reported, or whether an identifier can be replayed. Interface compatibility is therefore useful evidence about accessibility, not complete evidence about behavior.
This is especially important for privileged actions. If two commands are individually valid but their order produces different final states, a standard must say which preconditions, ordering rules, and event meanings are shared. Otherwise multiple implementations can each appear interface-compatible while producing incompatible outcomes.
Semantics and ordering are explicit design choices
The research uses a model of typed regulatory actions to make sequencing visible. Its examples distinguish applied, rejected, and operational-failure outcomes and define state-transition rules around replay, epochs, terminal states, and receipts. The broader lesson does not depend on endorsing that candidate: prose needs an agreed behavioral model before a proof can show that software matches it.
A model also has a boundary. It can express and test chosen rules but cannot determine external facts such as legal title, entitlement, settlement, or regulatory validity from on-chain inputs alone. Those questions require evidence and authority outside the contract.
What each evidence layer can cover
Tests observe selected executions. Mutation checks ask whether deliberately altered implementations are detected. Formal models establish properties inside stated assumptions. Symbolic tools cover selected paths and environments. Deterministic builds connect pinned inputs to reproducible output. Runtime-identity checks compare deployed bytes with a reviewed artifact.
Each artifact answers a different question. Passing tests does not prove the prose is coherent; a theorem about an abstract model does not detect a missing runtime guard; reproducible bytes do not show that the intended behavior was correctly specified. CryptossInsights’s smart-contract risk guide likewise treats audits and tests as bounded evidence rather than final guarantees.
Runtime identity and deployment evidence
Evidence about source code can become stale when code, compiler settings, libraries, metadata, or deployment inputs change. A review chain therefore needs identities for the exact artifacts it covers. Runtime bytecode can be compared with a deterministic build, while deployment records can show which address received those bytes.
Even an exact byte match proves identity, not correctness. Reviewers still need to connect the runtime to the intended semantics and account for mutable dependencies, administrators, proxies, or external components that can influence behavior.
The open proof gaps
The author explicitly says the general runtime-to-model proof remains open. The preprint also says its results do not establish complete Isabelle-to-Solidity-to-EVM refinement, compiler correctness, audit completion, production readiness, deployment verification, or external legal truth. Counts of passing evidence lanes or mutations are inventories within a declared scope, not a percentage of universal assurance.
Open obligations are useful because they prevent one strong artifact from being stretched into a stronger conclusion. A visible gap identifies the next proof or review task; it does not certify safety and does not show that proof is impossible.
A reusable evidence-scope matrix
Readers can review a conformance claim by asking seven questions: What behavior does the prose require? Is there an explicit semantic model? Do generated interfaces match it? Which implementation paths are tested or proved? Which compiler and build inputs are pinned? Do runtime bytes match the reviewed artifact? Which external facts remain outside the system?
A stronger claim should add evidence at the missing layer or falsify a competing behavior, not simply repeat an interface identifier. This framework is educational and has no identified effect on Indian law, tax, or regulatory approval. Continue with the standards-stage guide, uncertainty method, editorial policy, and risk disclosure.