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

EIPs EIPs informational
1

There is a common authority boundary showing up across recovery, agents, provenance, adjudication, and cross-standard composition that is worth defining directly. Anything Ethereum can define, it can put behind Resolution.

Resolution is the transition between something being produced or proven and that thing acquiring authority to change consequential state.

The minimum distinction is:

COMPUTATION
does not imply
AUTHORITY

EVIDENCE
does not imply
AUTHORITY

VALIDITY
does not imply
AUTHORITY

A valid object can exist without being authoritative for the state transition it points at.

The general form is:

candidate transition
↓
evidence
↓
admissibility
↓
authority
↓
resolution
↓
successor state

Each arrow is a separate transition. If an arrow can change the consequential state, its authority semantics have to be defined.

The invariant is:

No successor state may contain more authority than can be derived from the admitted evidence, the committed procedure or policy, and the current authority state.

Conceptually:

Resolve(
currentState,
evidence,
procedure,
authority,
proposedTransition
)
→ AUTHORIZED
| UNAUTHORIZED
| UNRESOLVED

AUTHORIZED permits the exact transition.

UNAUTHORIZED rejects it.

UNRESOLVED means no authorized successor can currently be derived.

That third state is necessary. If the procedure requires an answer even when authority is unresolved, the procedure can manufacture authority simply by being forced to choose. This also gives a cleaner boundary for autonomous systems.

The problem is not whether a machine can discover a transition nobody anticipated. The machine can compute arbitrary candidates.

The relevant question is whether the candidate can become consequential state without crossing an independent authority boundary.

machine
↓
candidate
↓
Resolution
↓
AUTHORIZED | UNAUTHORIZED | UNRESOLVED
↓
state transition

The machine producing the candidate does not inherit authority over the transition from the act of producing it. So increased capability does not have to imply increased authority.

Anything the system can define can be put behind Resolution.

A transfer can be resolved.

A signature can be resolved.

A tool invocation can be resolved.

A delegation can be resolved.

A policy change can be resolved.

A contract call can be resolved.

A newly discovered capability does not acquire authority merely because it has now become reachable or describable.

This seems to already exist in narrower forms across Ethereum.

ERC-7710 separates possession of a delegation from the exact capabilities that delegation authorizes. ERC-8196 separates an autonomous transaction from proof that it satisfies the owner’s committed policy. ERC-8354 separates a proposed action from the policy verdict required before execution. The same distinction appears outside agent execution.

A valid recovery proof does not necessarily establish successor authority. A valid provenance commitment does not necessarily establish execution. A valid auction result does not necessarily authorize mutation of the referenced target. Historical evidence that an authority once existed does not imply that the authority still exists.

These all reduce to the same form:

VALID(X)
does not imply
AUTHORITATIVE_FOR(Y)

until the authority edge from X to Y has itself been established.

Composition should therefore be authority-non-expansive.

VALID(A)
+
VALID(B)

does not produce authority that neither input, nor an already-authorized composition rule, supplies. The same applies across time. Evidence can accumulate while authority changes.

E_n ⊆ E_n+1

does not imply:

A_n ⊆ A_n+1

A revoked key remains historical evidence. A previous owner remains historical evidence. A superseded recovery commitment remains historical evidence. Preserving those facts does not preserve their authority to produce new state. This gives a simple falsification test for a Resolution boundary:

hold the admitted evidence fixed

change an uncommitted outcome-relevant input or transformation

does the authorized successor change?

If yes, something capable of changing the authoritative result exists outside the committed resolution procedure. The same test can be applied to authority directly:

can a valid proof, result, observation, identity, or composed object

cause a transition stronger than

the authority it actually establishes?

If yes, the transition is self-authorizing somewhere.

The proposal is not that every decision belongs onchain, or that Ethereum needs one universal policy language. The proposal is narrower:

Any consequential transition that a system can identify and mediate can require independent Resolution before becoming effective. Machines can generate possibilities. Evidence can establish facts. Policies can define permitted transitions. Authority determines which transitions may become effective. Resolution is the boundary that prevents one of those layers from silently acquiring the authority of another.

The shortest form is still:

Anything Ethereum can define as a consequential transition, it can put behind Resolution.

The useful counterexample would be a system where an uncommitted or unauthorized outcome-relevant dependency can change consequential state while the resulting transition remains fully authorized. If that case exists, it narrows the invariant. If it does not, this may be the common boundary underneath several mechanisms Ethereum is already building.

2

the “historical evidence doesn’t imply current authority” part is where i hit this concretely in erc-8403 (account authority lifecycle): ERC-8403: Account Authority Lifecycle

a case for your falsification test. an account keeps its keys in sync across chains by relaying a history of signed changes. every change in it is validly signed. but on a chain whose copy is behind, anyone can apply the history up to a point they pick and stop right before a revoke. so where the relayer stops is an uncommitted input that changes which key is authoritative there, and every step still verifies.

what bounded it for me was not a general layer but narrow rules: the signed digest has to cover a counter the record store consumes, and an authority granted by an all-chains change has to carry an expiry and can’t sign lifecycle changes.

do you see Resolution as something with an interface (a contract, a precompile), or more as a checklist each standard applies to itself?

3

I see Resolution as the invariant first, not as a contract or precompile. Each standard should close its own Resolution boundary in whatever way fits its state machine. In 8403 that can be counters, expiry, committed roots, and lifecycle rules. Another standard may need epochs, nonces, proofs, or something else entirely. The common requirement is that anything capable of changing the authoritative successor state has to be inside the committed resolution procedure. A shared interface only becomes necessary when one resolved authority state needs to compose with another system. Until then the invariant should stay mechanism neutral

4

Thanks again @AnkushinDaniil

Resolution is now narrow enough to move from discussion into a falsifiable Informational EIP draft. I’m taking the invariant, AUTHORIZED | UNAUTHORIZED | UNRESOLVED, and the outcome-relevant-input falsifier into the formal draft rather than expanding the idea further here.

My GitHub account currently cannot fork ethereum/EIPs, so I can’t carry the draft into the repository myself. Since you’ve been helping pressure-test this from the beginning, if you’d like to carry the fork and open the PR, please do. I’ll remain the listed author and explicitly approve the submitted text and any subsequent changes here or on the PR. Otherwise, this thread remains the discussions-to location for the proposal. From here, the useful work is falsification. If Resolution is wrong, the draft should make it possible to show exactly where.

5

@chugarchugarr a falsification case from deployed state, for the outcome-relevant-input test. Two Base mainnet USDC payments by EIP-3009 transferWithAuthorization, both mine, each preceded by a signed review verdict over the same action arguments, both settled.

  • 0xd105a8f5…d112: the authorization’s nonce is 32 random bytes from the x402 SDK. The verdict’s bound arguments contain that signed authorization, nonce included, so the verdict names this exact payment. The payment does not name the verdict: the same authorization would have settled whatever the verdict said. Hold the evidence fixed, change the uncommitted input (whether the executor waited for the verdict), and the chain records the same valid transfer.
  • 0x2afb35e2…c4a7: the authorization was signed after the verdict with nonce = the verdict’s decision_ref, so USDC’s AuthorizationUsed log records which verdict the payment carried, and the authorization could not exist before it.

Evaluated as “payment P executed under the authority of verdict V”, over three edges (V covers P, P carries V, a committed rule says which verdicts permit execution), neither reaches AUTHORIZED. The first is UNRESOLVED for two reasons, the second for one: neither payer committed the execution rule before paying. A REJECT verdict carried as the nonce under a declared rule is UNAUTHORIZED (synthetic, test key). Vectors and a stdlib checker: resolution-payment-pair-v0, 10 cases (2 real, 3 synthetic, 5 negative), and five wrong checkers each caught, including one that reads “verdict before block” as binding. --live re-reads both receipts from a public Base RPC.

One question for the draft. The first payment is UNRESOLVED because no committed input binds the authority; the producer has to change, and nothing fetched later can fix it. A payment whose receipt cannot be obtained is UNRESOLVED because the evidence is unavailable, and fetching can fix it. Should the draft keep these as one UNRESOLVED, or require a reason that tells them apart, since relying parties act on them differently?

6

A deployed instance of the three-state outcome, from prediction-market settlement, in case it is useful as a reference case.

On Polymarket an answer goes from candidate to authority in separate steps: a proposer posts it to UMA’s optimistic oracle (candidate), it can be disputed (twice, then a UMA token-holder vote decides), and only the CTF adapter resolving the condition makes it consequential for payouts. Two of your arrows show up there as real gaps:

  1. VALIDITY does not imply AUTHORITY. We keep a vector where the oracle request is SETTLED but the condition’s payoutDenominator is still 0: the answer is valid on the oracle and not yet authoritative for payouts. A validator that treated “settled” as final would write a final that is true on the oracle and false for the money. Our rule is final only after the adapter has resolved the condition. Vector: erc8004-outcome-validator/grounded-feedback/test-vectors/12-final-in-settled-not-resolved-window.json at main · predgeAI/erc8004-outcome-validator · GitHub

  2. UNRESOLVED has to be a first-class answer. While a dispute is in the vote, our validator on Monad mainnet records the request and answers “pending until the dispute settles” instead of a yes or no. An agent about to trade reads that as “no authorized successor yet” and does not act. If the procedure were forced to choose, it would manufacture exactly the authority you describe.

Happy to contribute the settled-but-unresolved case as a test fixture if the EIP grows one.

7

@chugarchugarr if nobody has picked up the fork yet (I don’t see a Resolution PR in ethereum/EIPs), we can carry it: your #4 text as the Informational draft, you as the listed author, nothing submitted or changed without your approval here or on the PR. We’d only handle the fork, the eip-1 formatting and the editor bot.

If it’s useful as a worked example in the draft, the falsification case from #5 (two Base payments, same evidence, one whose authorization commits to the verdict and one that doesn’t) is yours to use or leave out. @AnkushinDaniil, happy to step aside if you’re already on it.

1 Like
8

That works for me. Thank you.

1 Like
9

@chugarchugarr great, thank you. Before I open anything, here is the
draft for you to check:

I only moved your text from #1, #3 and #4 into the sections EIP-1
requires; no new content. Can you confirm two points? First, the
author line: right now it reads chugarchugarr (@chugarchugarr). Tell
me if you’d like a name or an email added. Second, the worked example:
it sits as a comment at the end of Rationale, so it can stay in or
come out. If @predge-ai agrees, their settled-but-unresolved case
could go next to it as a second reference. When you’re happy with it,
I’ll open the PR and deal with the editor bot.