Skip to content

Back to the catalog

EIP-TBD: Resolution — Non-Self-Authorizing State Transitions
ethereum-magicians.orgthread

EIP-TBD: Resolution — Non-Self-Authorizing State Transitions

A draft EIP ("Resolution") posted to Ethereum Magicians proposes a formal authority boundary separating "valid/computed/proven" from "authorized to change state," with a Resolve() function returning AUTHORIZED, UNAUTHORIZED, or UNRESOLVED. It generalizes a pattern the author sees already present piecemeal in ERC-7710 (delegation possession vs. exact capability), ERC-8196 (autonomous transaction vs. owner policy proof), and ERC-8354 (proposed action vs. policy verdict), arguing composition must be authority-non-expansive so recovery proofs, provenance commitments, and agent-generated candidate transactions can't silently acquire authority they weren't granted.

TL;DR Draft EIP proposes a formal "Resolution" authority boundary (AUTHORIZED/UNAUTHORIZED/UNRESOLVED) to stop valid proofs, evidence, or agent-computed actions from silently gaining state-changing authority in delegation, recovery, and agentic execution on Ethereum.
Document

What it is

A draft EIP titled "Resolution" formalizes a three-way authority check — Resolve(currentState, evidence, procedure, authority, proposedTransition) → AUTHORIZED | UNAUTHORIZED | UNRESOLVED — intended as a generic boundary any Ethereum mechanism can be built behind, separating proof that something is valid from proof that it is authorized to change state.

How it works

The core move is the third output, UNRESOLVED. A binary AUTHORIZED/UNAUTHORIZED check forces an answer even when authority genuinely cannot be derived yet, which lets the procedure manufacture authority just by being forced to choose. UNRESOLVED removes that pressure: it says no authorized successor can currently be derived, full stop. The proposal also states a non-expansion invariant for composing proofs over time: evidence accumulating (E_n ⊆ E_n+1) does not imply authority accumulating (A_n ⊆ A_n+1) — a revoked key or superseded recovery commitment remains valid historical evidence but must not retain authority to produce new state.

The page gives a concrete falsification test for whether a system actually has this boundary: hold admitted evidence fixed, change an uncommitted outcome-relevant input or transformation, and check whether the authorized successor changes. If it does, something outside the committed resolution procedure can alter the authoritative result — meaning the transition is self-authorizing somewhere it shouldn't be.

flowchart TD
    C[Candidate transition] --> E[Evidence]
    E --> AD[Admissibility]
    AD --> AU[Authority]
    AU --> R[Resolve]
    R -->|AUTHORIZED| S[Successor state]
    R -->|UNAUTHORIZED| X[Rejected]
    R -->|UNRESOLVED| H[No change — held]

Preconditions / Affected

Applies to any EIP or system where a separate layer (recovery proof, provenance commitment, agent-generated transaction, auction result, delegation) could be mistaken for carrying authority simply because it is valid or newly computed. The author names ERC-7710, ERC-8196, and ERC-8354 as existing designs that already implement narrower, piecemeal versions of this split.

What to do

This is a draft proposal, not a shipped standard — there is no code or reference implementation in the text. The actionable item for an engineer is the falsification test itself: apply it to any state-transition design (especially recovery, delegation, or agent-execution logic) by fixing the evidence and varying an uncommitted input to see if the authorized outcome shifts. If it does, the design has an implicit self-authorizing path that needs an explicit Resolution/UNRESOLVED gate.

Caveats

The author explicitly invites a counterexample: a system where an uncommitted or unauthorized dependency changes consequential state while the resulting transition stays fully authorized. If such a case exists, the stated invariant narrows; the post does not claim the invariant is proven, only unfalsified so far. No implementation, gas cost, or concrete EIP number is given — this is a discussion-stage framing post.

Organisations named here

  • ERC-8196
  • ERC-8354

Technologies named here

  • Ethereum
  • ERC-7710

Techniques named here

  • Resolution boundary / authority-non-expansive composition
  • Falsification test for a Resolution boundary