EOA delegation: follow code authority beyond one transaction
An EOA’s code delegation can outlive the application action that introduced it. Under enabled EIP-7702 rules, an included transaction can process a valid authorization, fail during application execution and still leave the processed delegation in place. A failed application receipt therefore does not by itself establish that the account retained its previous code authority.
Research this as a state history. Record authorization processing, the resulting delegation indicator, application execution and later replacement or clearing separately. Counting a transaction or reading one success flag cannot complete that history.
State the network and activation assumption
This guide uses a fictional network on which EIP-7702 is already enabled. Its labels H0, H1 and H2 denote ordered observation blocks, not Ethereum mainnet activation heights. For an actual network, verify the applicable fork rules before applying the mechanism to historical records.
EIP-7702, Set code transaction and Behavior, specifies authorization processing before application execution. It describes chain and nonce checks, writing a delegation indicator, skipping failed tuples and preserving processed indicators when execution fails. These statements concern a transaction handled under the specified rules; an invalid transaction rejected by consensus is a different case.
Retain network identity, relevant rule version, transaction type and block hash. If the data source merely labels a familiar action as delegated, obtain the raw authorization list and observed code before accepting that classification.
Separate the outer sender from the authority
An outer transaction has its own sender and nonce. Each authorization tuple concerns the account recovered as its authority. The two roles can differ. A sponsor’s transaction being included does not mean the sponsor owns the delegated account, and the sponsor’s nonce is not a substitute for the authority’s authorization nonce.
For each tuple, retain its chain domain, target address, nonce and signature fields. Record the recovered authority and processing position. Evaluate it using state at its processing point, not only the final nonce displayed after the transaction.
The source distinguishes the outer sender’s nonce increment from authorization-list processing. If the sender is also an authority, order matters. The worked example avoids that complication by making S the outer sender and A a different authorizing account. A real record with both roles combined needs an explicit step-by-step nonce reconstruction.
A hypothetical failed application with persistent delegation
Assume that before H0, A has empty code, authorization nonce 7 and a balance of 4 ETH. Sponsor S is a different account. A valid authorization for this enabled network points to implementation D and carries nonce 7. All prerequisites for the outer transaction are stipulated to hold.
The outer transaction sends no value and contains that authorization. During processing, the valid tuple writes the delegation indicator for D and advances A’s nonce to 8. Application execution then attempts a 0.5 ETH transfer from A but reverts before committing its effects. S pays the transaction fee in this example; no fee amount is assumed.
| Stage | A nonce | A code state | A balance | Application outcome |
|---|---|---|---|---|
| Before H0 | 7 | Empty | 4 ETH | No action yet |
| Authorization processed | 8 | Indicator pointing to D | 4 ETH | Execution not completed |
| H0 final state after execution failure | 8 | Indicator pointing to D | 4 ETH | Proposed 0.5 ETH transfer reverted |
| H1 with no intervening change to A | 8 | Indicator pointing to D | 4 ETH | Prior failure does not clear it |
| H2 after a separately valid clearing authorization | 9 | Empty code | 4 ETH | Separate transaction evidence required |
The balance arithmetic is deliberately simple: the proposed transfer does not become a committed debit, so A remains at 4 rather than 3.5 ETH under these assumptions. The authorization change follows a different rollback boundary and remains recorded at H0. A receipt indicating failed application execution cannot justify resetting the code-state column to empty.
For an ordinary delegation target, the indicator contains the three-byte prefix 0xef0100 and a twenty-byte address, totaling 23 bytes. Inspect that structure and extract the target rather than equating any nonempty code with a conventionally deployed wallet contract.
Verify the historical target as well as the pointer
A pointer to D identifies the address supplying delegated code; it is not a security assessment of that code. Preserve the code or code identity relevant to the observation and any verified deployment relationship needed to interpret it.
Distinguish the authorizing account’s state from the target address’s state. The EIP’s delegation execution rules use code from the target in the authority’s context. Reading only D’s own storage would not necessarily establish the settings used while acting for A.
Connect any claimed asset movement to committed execution evidence. Authorization to run code does not itself transfer the account’s four ether. Conversely, no immediate transfer does not establish harmless authority: the persistent code relationship may matter for later actions and arriving assets.
Clearing is another observed transition
In the example, a later valid authorization uses A’s then-current nonce 8 and the zero target to clear the code, advancing the nonce to 9. Verify the resulting account code at H2. An unsigned intention to disconnect, a website status or an omitted authorization list in a later transaction is not equivalent evidence.
Clearing this indicator does not establish that every other authorization is gone. Token allowances, application permissions and contract-specific storage are separate objects. Requery the relevant state if a memo claims broad revocation; do not extrapolate from an empty code result.
Keep the H0 and H2 observations together. A current empty-code account can have had delegation during the interval. Applying today’s classification to past activity would erase the exposure the state history is intended to document.
Different failure: the tuple was never processed successfully
Suppose a separate transaction supplies a stale authorization nonce 6 when A’s relevant nonce is 7. Under the specified processing rules, that tuple fails its check and is skipped. This is different from a successfully processed nonce-7 authorization followed by application failure.
In another hypothetical list, a valid nonce-7 tuple points to D1 and advances the nonce to 8. A later nonce-7 tuple for the same authority cannot simply replace it because it is now stale. A later valid nonce-8 tuple can have another result. Evaluate order and validity before adopting the last target printed in the raw list.
The EIP describes the last valid occurrence as decisive when multiple tuples for one authority are present. Last listed and last valid are not synonyms. Save a per-tuple decision table so that a reviewer can reproduce the resulting pointer.
Chain scope and transaction validity are boundaries
The chain field can name the current chain or use the permitted zero domain. A chain-specific signature should not be assumed to apply everywhere, while a zero-domain signature needs careful scope labeling. The existence of one processed authorization on one chain does not enumerate every unused signed authorization elsewhere.
Also distinguish application failure from a transaction that fails the outer validity requirements. The table assumes an included, validly processed transaction with unsuccessful execution. It does not claim that malformed or consensus-invalid transactions can update chain state. Preserve rejection evidence separately from an included failure receipt.
Save pre-block and post-block code, and seek finer execution ordering when several transactions affect A within one block. A set, replacement and clearing can all occur before an empty end-of-block snapshot. Without transaction-level transitions, limit the conclusion to the observed end state and mark the intra-block history unresolved. Later ordering evidence can complete the record without changing what the earlier snapshot actually showed.
A state-history checklist
| Check | Evidence to retain | Misinterpretation prevented |
|---|---|---|
| Rules apply | Network and activation reference | Retrofitting a new rule into older blocks |
| Roles are identified | Outer sender and recovered authorities | Using the sponsor’s nonce or identity for A |
| Tuples are evaluated in order | Domains, nonces and processing decisions | Treating the last raw tuple as effective |
| Indicator is observed | Historical code and extracted target | Assuming application failure cleared code |
| Execution is reconciled | Receipt, committed state and value changes | Calling authorization itself a transfer |
| Later clearing is established | New authorization and resulting code | Treating an interface disconnect as revocation |
Reopen the record after a target change, a clearing event, a corrected nonce reconstruction or a newly discovered historical code snapshot. Publish the last verified authority state at each cutoff, together with unresolved tuple or implementation evidence. That supports an account-control review without converting a transaction label into a claim about people, safety or future behavior.
FAQ
Does a failed application receipt prove the authorization had no effect?
No. Under the assumed enabled rules, successfully processed delegation indicators persist despite execution failure. Check the resulting code state.
Does an account with empty code today have no delegation history?
No. A later clearing transition can leave empty code after an earlier period of delegation. Historical claims need historical state.