ETL's Five Machine States Turn Ethereum Governance Into a Replayable Proof

Same evidence, same output—every time, on any machine. That's the bet the Ethereum Transparency Layer (ETL) makes. Two independent observers feed identical governance transactions into the deterministic verifier runtime; both get identical five-state outputs: VALID, INVALID, UNDECLARED, INCONSISTENT, or UNKNOWN. No confidence scores, no severity rankings, no probabilistic threat scoring. Just machine-state purity.

The Observability Trap

Current Ethereum governance infrastructure leans hard on observability. You can inspect transactions, events, proposals, and multisig actions. But observability isn't verification. Two observers using different indexers or custom pipelines can reconstruct the same governance history in divergent ways. The source material calls this a problem of “information continuity,” not information availability. The ETL paper, posted on ethresear.ch, argues that visibility alone fails to guarantee replay-equivalent reconstruction across independent environments. The core shift: move from analytics to deterministic execution verification.

The ETL Stack: From Disclosure to DAG

ETL wraps governance activity in a four-layer constitutional stack. ERC-8241 defines canonical governance disclosure structures—declared authority, execution targets, executor relationships. The Proof-of-Operation layer transforms execution traces into replayable evidence. The Execution Trace Normalization Layer (ETNL) eliminates semantic ambiguity before verification begins. Finally, the Execution Graph layer models governance causality as a directed acyclic graph (DAG), capturing parent-child lineage, delegated authority propagation, and execution ancestry.

Each layer feeds into the deterministic verifier runtime, which implements a sequential pipeline: canonical evidence law → deterministic ordering → evidence ingestion → execution reconstruction → DAG construction → authority verification → graph consistency verification → deterministic rule engine → replay certification. The runtime is constitutionally prohibited from operating as an analytics system, recommendation engine, or AI reasoning system. It exists solely to validate governance execution continuity.

Five Machine States, No Probabilistic Fuzz

The outputs are brutally simple. The runtime emits exactly one of five constitutional states: VALID, INVALID, UNDECLARED, INCONSISTENT, UNKNOWN. No gradient, no nuance, no “maybe.” The invariant theorem is stated as: ∀E: Canonicalize(E) → Order(E) → Reconstruct(E) → DAG(E) → Verify(E) → Output(E) such that E1 = E2 ⇒ Output(E1) = Output(E2). If you give the runtime the same evidence twice, you get the same output—regardless of insertion order, runtime environment, execution timing, or infrastructure implementation. The system defends against malformed evidence injection, replay divergence attacks, and cyclic causality manipulation through deterministic admissibility enforcement, not probabilistic scoring.

What Replay Certification Enables

The replay certification layer validates that every pipeline step produces identical outputs across repeated executions, different operating systems, distributed infrastructure, and separate replay cycles. That means a DAO treasury audit can be run independently by a watchdog group and a protocol team, and both will produce the same verification verdict. The paper notes this transition “from governance observability systems toward deterministic governance execution infrastructure.” As Ethereum governance systems evolve into long-lived institutional infrastructure, the ability to produce machine-verifiable governance histories without relying on a trusted indexer becomes a prerequisite for trust minimization. ETL makes that deterministic, one canonical state at a time.

Source: Deterministic Governance Verification for Ethereum
Domain: ethresear.ch