EIP7702 Revocation: Verify Code, Nonces and Remaining Permissions

Read the authorization record

The decisive record is the account's code at the block being investigated.

A wallet notification saying that a transaction failed cannot establish whether its delegation changed. Under EIP-7702's authorization processing rules, valid authorization tuples are processed before ordinary execution. Their delegation changes survive a later execution failure. That separation is the starting point for an evidence-based recovery review.

EIP7702 revocation clears an externally owned account's delegation indicator through a valid authorization whose target is the zero address. The EOA keeps its address. Clearing that indicator does not instruct token contracts to erase allowances, invalidate every signed message or remove all account storage. Each of those claims would require separate evidence from the system that owns the relevant state.

A set-code transaction contains an outer transaction and an authorization list. The outer sender may be a sponsor. The authority recovered from an authorization signature is the account whose delegation is changed. Confusing those addresses can send an investigation toward the sponsor's history while missing the account that actually granted authority. Record both addresses before interpreting the transaction.

The distinction also changes how a support team should phrase a result. "The account has empty code at the checked block" is a verifiable observation. "The wallet is safe again" joins several additional claims about key custody, token allowances and signed authorizations that the code observation cannot support. Keep the narrow observation even when the interface presents a broad success message.

The signature replay guide covers application nonce and domain design. Here the job is narrower: establish what a delegation-clearing attempt did, then identify which other permission stores require review. A transaction identifier needs its chain and resulting state.

Original model: when a failed transaction still clears code

We implemented the authorization boundary as a small deterministic model and enumerated every combination of its declared inputs. The result makes a specific reporting error visible: some constructed transactions have failed execution and successfully cleared delegation. These are model outcomes derived from the specification, not transactions observed on Ethereum.

Method

Evidence date

October 3, 2026; the fetched EIP and its hash are retained.

Population

72 combinations: 3 chain scopes, 3 tuple nonces, 2 sender relationships, 2 targets and 2 execution outcomes.

Starting state

Current chain 1, authority nonce 7 and an existing delegation.

Nonce boundary

A self-sponsored transaction increments the authority's sender nonce before processing its tuple. A separate sponsor does not increment that authority nonce as the outer sender.

Assumptions

Signatures, field bounds, account eligibility and outer transaction validity all pass. One authorization tuple is present, and execution makes no additional code changes.

Exclusions

No cases removed. Cryptography, transaction fees and network ordering are outside the model.

The replay script is seo/research/authorization-boundaries-2026-10-03/measurements.py. Its complete input and output rows are in seo/research/authorization-boundaries-2026-10-03/eip7702-revocation/measurement.json. These artifacts are retained in the repository and are not public download links. Running the script with --recheck compares every result with the retained output.

Results

The chain scopes are 0, 1 and 2. On the modeled chain, the first two pass the scope check. Tuple nonces are 6, 7 and 8. Only the nonce matching the authority at authorization processing passes. The execution outcome is independent of whether an already valid authorization cleared code, which explains the final row.

For example, a separate sponsor submits a correctly signed zero-target authorization with nonce 7 for the modeled account. The authority nonce advances and its code becomes empty. If the subsequent call reverts, those authorization effects remain. With self-sponsorship, the tuple instead needs the post-increment authority nonce, 8, under these starting conditions.

Limits

• The experiment runs Python state transitions, not an EVM client or wallet.
• The case counts describe a complete constructed grid, not the frequency of failed recovery attempts.
• Only one tuple is modeled. Real authorization lists can contain several tuples, including several for the same authority.
• A successful code clear says nothing about whether a private key is still secret or a token allowance is absent.

Receipt failure is not proof that delegation stayed unchanged. Conversely, receipt success does not prove that the intended tuple was accepted. Both directions require a state read. The model is useful as a fixture specification for client testing, but it does not replace that testing.

Distinguish an ignored tuple from a reverted call

A validity failure while processing an authorization tuple does not have the same effect as a failure in ordinary execution. The EIP directs the client to stop processing that tuple and continue with the next one. A reviewer who sees a clearing target in the authorization list must therefore establish that the tuple reached the code-changing step.

As an illustrative sequence, consider an authority whose expected nonce matches an earlier valid tuple. Applying that tuple advances the authority nonce. A later tuple must match the new processing state if it is to change the delegation again. Looking at each tuple against only the account's starting nonce can misclassify the later entry. This example explains the sequencing rule; it is outside the single-tuple experiment above.

Separate the application's execution trace from this authorization processing evidence. An execution trace showing a reverted call can explain why an application action failed, but the account's final code still needs to be read. Conversely, a successful application call can coexist with an ignored clearing tuple if that tuple did not meet its validity conditions.

For a client integration, add fixtures for a valid tuple followed by an invalid tuple and for successive valid tuples belonging to the same authority. Preserve the expected final code and nonce for each sequence. The acceptance question is whether the client and the interface agree about the resulting state, not whether the interface displayed a reassuring transaction message.

Those fixtures should keep signature validity separate from nonce validity. Otherwise, every negative case can fail at signature recovery and leave the nonce-processing rule untested. Use independently checked inputs and retain the reason each tuple was accepted or skipped.

Separate delegation from other permissions

An account can expose authority through several contracts at once. EIP-7702 changes which code executes in the account's context. ERC-20 allowances live in token contracts. A signed order may be checked by an exchange contract. A session permission may be enforced by a wallet implementation. Clearing one record cannot be treated as an instruction to all those other systems.

Account code

Inspect the delegation indicator and its target at the chosen block.

Token state

Read the relevant token allowance for the owner and spender on the same chain.

Application authorization

Check the verifier's nonce, deadline and revocation rules for outstanding signed messages.

Stored account configuration

Assess the previous storage layout before selecting a replacement delegate.

The ERC-20 allowance interface addresses a different permission store from account code. A spender holding a usable token allowance can rely on that token's transfer logic. No account-code observation proves the allowance was cleared. Read the owner-spender pair rather than inferring it from a wallet's connected-sites list.

Signed messages need their own classification. EIP-712 defines typed signing and domain separation but does not itself provide application replay protection. ERC-2612 specifies a token permit flow with its own nonce and deadline. Other systems use different nonce arrangements. An authorization nonce advancing at the account level therefore does not establish that an unrelated permit has expired or been consumed.

Storage is another independent boundary. The EIP warns that changing delegates can create storage collisions and that the protocol does not natively offer a general storage-clearing operation. An account with empty code may still carry storage written through its previous delegate. Installing new code that interprets those slots differently can make a supposedly fresh setup inherit old configuration.

For an investigator, "unknown" is the correct status when a signed message cannot be enumerated from public chain state. It should not become "none found" without naming the search boundary. Preserve what was checked, such as known token-spender pairs or an application's order nonce, and list the remaining uncertainty separately. This keeps the recovery record usable by the next reviewer.

Verify revocation at a fixed block

Choose a chain and a block before comparing observations. A code read at one block and a nonce read at another may describe different states. A provider returning pending data can also disagree with an explorer displaying a confirmed block. These disagreements require aligned evidence before they justify a conclusion about the revocation.

1. Record the chain identifier, account address and intended clearing target. Identify whether the account itself or a separate sponsor sends the outer transaction.
2. Inspect the authorization list and recover or independently verify its authority. Check the chain scope and nonce against the expected processing state.
3. Record the receipt and inclusion block. Do not turn the receipt status into a delegation verdict.
4. Read account code and nonce at that block through a trusted provider. Preserve the raw response and the block hash, not just an interface screenshot.
5. Inspect any later relevant account activity before presenting the result as current. A subsequent valid authorization can select a delegate again.
6. Verify independent permissions against their own contracts and record unobservable outstanding signatures as unresolved.

Multiple authorizations make the final-state read particularly important. The EIP processes tuples in order and uses the last valid occurrence for an authority. A clearing tuple visible in the transaction is not enough if a later valid tuple selects another target. Invalid tuples are skipped, so neither the first occurrence nor the last textual occurrence necessarily establishes the outcome.

Chain scope also deserves a literal reading. A tuple with chain identifier 0 may be accepted on other chains when the remaining validity conditions match. Clearing delegation on one chain does not perform a cross-chain cleanup. Inventory the networks where the account has relevant activity, then evaluate each chain's state separately. Do not assume a familiar address resolves to the same code everywhere.

Record the provider's block support and any failed responses. If a historical-state request cannot be answered, the historical result remains unverified. A latest-state response cannot silently substitute for it. The distinction matters when a later transaction repairs or reintroduces a delegation, because the latest view can hide the state immediately after the attempted recovery.

The transaction simulation review explains why a preview depends on its state assumptions. Use simulation to test the intended transaction, then verify the included result. The execution and the evidence capture are separate tasks, each with a concrete artifact.

Handle migration and compromised keys

Revoking a delegate and recovering control of a compromised key are different problems. The clearing operation changes account code. It does not make a leaked signing key unknown to whoever obtained it. A holder of that key may be able to authorize another delegation or ordinary transaction. Treat a confirmed key compromise as a continuing authority problem when planning where remaining assets should be controlled.

A migration between delegates needs a compatibility review even when no compromise occurred. Ask what the old implementation wrote, what the replacement reads and how initialization is authorized. The EIP's initialization warning is precise: setting delegation does not run contract-creation initialization code. The setup call must have its own authorization protection so that an observer cannot initialize the account with unintended values.

Do not import an unknown "recovery contract" simply because it advertises storage cleanup. Such a delegate executes in the account's context. Its review must cover the actual authority it receives and the changes it can make. A destructive storage operation also needs an inventory of state that should survive, including any configuration necessary to interpret or reclaim positions.

The broader key rotation and revocation workflow is useful for team-owned accounts. Assign a reviewer who can challenge the proposed migration and a separate operator who preserves the evidence. For an external review, the Pharos Production member profile and the security provider directory help identify assessment options. The engagement scope must explicitly include the delegate and recovery path.

Keep a reproducible recovery record

A closure record should let another engineer repeat the important reads without relying on the first operator's interpretation. Start with the account and chain, then attach the transaction, authorization details and block-specific state. Distinguish observations from judgments. For example, a recorded empty code response is an observation; the belief that no outstanding application signatures exist is a judgment with a defined search boundary.

Before state

Known delegation target, authority nonce, relevant token allowances and the reason the account entered review.

Attempt

Outer sender, authorization authority, target, chain scope and nonce, with secrets excluded.

After state

Receipt, inclusion block hash, code response and authority nonce at the checked block.

Residual authority

Known allowances and application permissions, outstanding-signature uncertainty and key-custody assessment.

Closure condition

The exact observations required by the account owner, with any incomplete checks assigned for follow-up.

Keep private keys and recovery phrases out of this record. Reproducibility requires public identifiers and state observations, not the secret that authorizes transactions. If someone cannot explain why a secret is needed for a proposed verification step, that step has not been scoped adequately.

The narrow conclusion supported by this investigation is that authorization processing and execution status must be checked independently. The original model reproduces that distinction across every declared input combination. The evidence needed for a real account remains its recorded state, its remaining permission stores and the integrity of the key that can change them.