EIP-8130 Account Configuration: Actors, Authenticators, Gas Sponsorship, and Replay Risk

What EIP-8130 is trying to change

Ethereum account abstraction is ultimately about letting accounts define richer security and authorization rules than one permanent secp256k1 private key.

A smart account can use a passkey.

It can have several administrators.

It can authorize a low-risk session key.

It can limit that key to one application.

It can separate transaction authorization from gas payment.

It can rotate authentication algorithms without changing the account address.

It can use different nonce channels for independent workflows.

It can authorize the same account configuration across several chains.

Existing account-abstraction systems achieve many of these outcomes at the application or contract layer. EIP-8130 proposes bringing a structured version of them closer to protocol validation.

The proposal's key design choice is to separate three questions that traditional wallets often collapse into one signature check:

This separation lets nodes reason about validation more predictably.

Instead of simulating arbitrary wallet code merely to decide whether a pending transaction is admissible, the transaction identifies the authenticator up front.

Canonical authenticators can be handled under predictable validation rules, while account authority remains explicit in the keystore.

Account configuration is not the same as connecting a wallet

A wallet connection normally exposes an address to a DApp and lets the DApp request signatures or transactions.

EIP-8130 account configuration determines who can authenticate as the account and what protocol-level contexts that actor can use.

That is much more consequential.

A DApp connection can usually be disconnected without changing blockchain authority.

An EIP-8130 actor can remain authorized on-chain until revoked or expired.

A restricted session actor may be deliberately narrow.

An unrestricted actor with scope 0x0000 is an administrator capable of account configuration changes.

Actors and authenticators are separate security concepts

An actor is an identity within the account's authorization system.

An authenticator is the mechanism that proves that identity.

The proposal represents each actor with a 32-byte actorId.

Different authenticators derive actorId differently.

A secp256k1 actor can map to an Ethereum-style address.

A P-256 or passkey authenticator can derive actorId from the relevant public-key coordinates.

A delegation authenticator can represent another account that is allowed to act on behalf of this one.

The important security boundary is that the authenticator returns the actorId rather than receiving an arbitrary actorId from the transaction and simply validating it.

After authentication, the protocol checks that the returned actorId is actually associated with the declared authenticator in the account's keystore.

This prevents an authenticator from claiming another authenticator's actor slot merely by returning a chosen identifier.

The canonical authenticator set

The current draft defines a small canonical baseline intended to be accepted by compliant chains.

The proposal is designed to be crypto-agile.

An account does not need a new address merely because it later adopts another signature algorithm.

It can authorize another actor tied to another authenticator.

That gives accounts a path toward future authentication systems, including new hardware-backed or post-quantum methods, without redeploying the account itself.

What is stored in actor_config

Each normal actor has a compact configuration containing three security-critical concepts:

ActorConfig
├─ authenticator : address
├─ expiry        : uint48
└─ scope         : uint16

The authenticator tells the protocol how this actor proves identity.

The expiry limits how long that actor remains live.

The scope describes which protocol contexts the actor is permitted to authorize.

If POLICY is enabled, the actor additionally has a policy manager and a policy commitment.

Revoking a normal actor deletes the actor configuration and related policy state from the Keystore.

The actor scope bitmask is the core least-privilege mechanism

Scope is a uint16 grants bitmask.

The design is unusual in one important way: 0x0000 means unrestricted.

It is not "no permissions."

It is the administrative root.

This is a critical implementation and UX detail because many developers naturally associate zero bits with zero authority.

Unknown future scope bits fail closed

The current draft treats future scope bits as pure grants.

An actor that contains only unknown bits does not gain arbitrary authority today.

The bits are stored, but a context is allowed only if the unrestricted admin predicate applies or the specific recognized grant is present.

This makes forward extension safer than interpreting unknown bits permissively.

Scope zero is root account authority

The administrative predicate in EIP-8130 is exactly scope == 0x0000.

That actor can authorize configuration changes such as adding actors and revoking actors.

It can authorize signed account-change batches.

Administrative secp256k1 self-authority is also involved in delegation operations under the current draft.

This means wallet interfaces need to distinguish ordinary operational keys from administrative keys very clearly.

POLICY actors create a protocol gate plus an application-defined policy layer

The POLICY scope is designed for session keys and other restricted actors.

When POLICY is enabled, the actor has a configured manager contract and a commitment.

The protocol enforces one simple rule:

The manager then interprets the policy commitment and decides what the actor is allowed to do.

This is how an actor can be restricted to something more expressive than one generic permission bit.

The manager can implement:

• A daily spending limit.
• A specific token allowlist.
• An application allowlist.
• A subscription amount and interval.
• A maximum order size.
• A restricted set of downstream protocol targets.
• Time-of-day or usage-count rules.
• Application-specific session-key constraints.

The policy manager is a major trust anchor

The protocol does not understand the semantic meaning of the commitment.

It only gates the actor to the manager address.

The manager is responsible for enforcing the actual spend cap, allowlist, subscription, or other policy.

If that manager contains a bug, the restricted actor can become much more powerful than the user expects.

If the manager is malicious, it can abuse whatever authority the account grants through it.

Upgradeable policy managers are especially sensitive

The current EIP security guidance recommends treating the policy manager as a strong trust anchor and prefers non-upgradeable managers for security-sensitive policies.

If a manager is upgradeable, whoever controls the upgrade can rewrite the rules after the actor has already been authorized.

A key that was originally limited to 5 USDC per month could effectively become much broader if the manager logic is replaced.

Using the account itself as policy manager can be dangerous

The draft permits a policy-bearing actor to point its manager at the account itself.

This can be useful when the account's own wallet code understands the policy commitment and enforces it correctly.

It can also be catastrophic if the account blindly trusts self-calls.

Suppose the wallet's executeBatch function assumes that any call where msg.sender == account is fully trusted.

A POLICY actor is protocol-gated to the account address.

The policy actor calls the account.

The account treats the self-call as unrestricted.

The actor has effectively escaped the intended policy restriction.

Wallet code must therefore be policy-aware if it uses itself as the manager.

Actor expiry is powerful but easy to misunderstand

An actor's expiry is a uint48 Unix timestamp in seconds.

Zero means no expiry.

An actor remains live while the block timestamp is less than or equal to the configured expiry.

Once the timestamp passes the expiry, authentication is rejected.

This makes expiry useful for session keys.

A temporary application key can be valid for one hour.

A subscription key can be valid for one month.

A temporary operational signer can be valid for a weekend event.

Initial actors are non-expiring

The current account-creation format does not express expiry for initial actors.

An expiry can be added later through a configuration change.

Administrators should usually remain non-expiring

The specification warns against placing expiry casually on the sole administrative actor.

If every administrative root expires, the account can lose the authority required to make future configuration changes.

This is not the same as a low-risk session key expiring.

An expired session key stops working.

An expired sole admin can make account recovery or cross-chain configuration synchronization much harder or impossible.

Revoking a parent administrator does not automatically revoke child actors

This is one of the most important security properties to understand.

EIP-8130 does not maintain an authorization lineage tree that is walked every time an actor signs.

Once an administrator successfully authorizes another actor, that actor has its own actor_config slot.

Later expiry or revocation of the administrator does not automatically erase the actor it previously installed.

That actor survives until its own expiry or explicit RevokeActor change.

This is deliberate because actor authorization becomes flat account state once installed.

It also means incident response must enumerate every live actor rather than assuming that rotating the root removes all derived permissions.

Explicit RevokeActor is the durable actor revocation mechanism

Revoking a normal actor deletes its actor_config state.

If the actor has POLICY scope, the associated policy manager and commitment are also cleared from Keystore state.

That immediately prevents the actor from authenticating through the normal actor path.

Manager-side data can remain

A policy manager can maintain its own application storage.

Revoking the actor removes protocol-level authority, but the protocol does not automatically erase arbitrary application state inside the manager.

Wallets may need an additional uninstall or cleanup call when retiring a session policy.

Expiry and revocation serve different purposes

Expiry provides an automatic end time for a restricted actor.

Revocation immediately removes authority before that time.

High-risk session actors should generally have both a sensible expiry and an accessible revocation path.

The local epoch cancels outstanding local signatures, not installed actors

EIP-8130 introduces a local epoch combined with a local sequence.

This is designed partly for session-key and just-in-time authorization workflows where many signed configuration changes can exist without strict coordination.

IncrementLocalEpoch is a blunt cancellation operation.

When the local epoch is incremented, every unlanded local signed batch from the previous epoch becomes stale.

This includes sequenced and unsequenced local signatures.

That makes epoch rotation an important incident-response tool if the wallet believes outstanding configuration signatures were leaked.

Epoch bump does not revoke actors already installed

If a malicious actor was authorized by a batch that already landed, changing the epoch does not remove that actor.

The wallet still needs RevokeActor.

Epoch bump does not invalidate the multichain channel

The multichain configuration channel uses its own monotonic counter and does not carry the local epoch.

Wallets must not tell users that "rotate epoch" invalidates every possible configuration authorization everywhere.

Unsequenced JIT configuration changes are intentionally replayable within an epoch

The Local configuration channel supports an unsequenced mode intended for just-in-time authorizations.

It does not consume the normal local sequence.

That makes it flexible.

It also means the signed batch can remain replayable while its local epoch remains current.

The durable retirement action is therefore an epoch bump.

If a wallet distributes a JIT authorization and later decides it should never land, merely waiting is not enough.

IncrementLocalEpoch invalidates it.

The safest reduction workflow can combine the relevant actor change with the epoch increment so outstanding stale local signatures cannot reintroduce the old state.

EIP-8130 authorization surface map

The EIP-8130 account-abstraction transaction

The proposal introduces a new typed transaction under EIP-2718.

The transaction does more than carry calldata.

It expresses the account's identity, replay domain, validity window, fee limits, account configuration changes, execution calls, metadata, gas payer, sender authentication and payer authentication.

AA transaction
├─ chain_id
├─ sender
├─ nonce_key
├─ nonce_sequence
├─ valid_after
├─ valid_before
├─ max_priority_fee_per_gas
├─ max_fee_per_gas
├─ gas_limit
├─ account_changes
├─ calls
├─ metadata
├─ payer
├─ sender_auth
└─ payer_auth

This structure is important for clear signing.

The user is not only signing "call contract X."

They can also be signing actor configuration changes, a specific sponsor relationship, a specific validity period, and a multidimensional nonce channel.

A serious wallet UI must surface those components when they are security-relevant.

What an EIP-8130 wallet should display before signing

A user should not need to understand RLP to know what authority they are creating.

This is where the principles from TokenToolHub's Clear Signing in Crypto become especially important.

Showing "Account Configuration" is not enough.

The user needs to know exactly which authority will exist after the transaction.

Sender signatures bind the transaction's real security context

The sender signature covers the transaction fields through the payer address while excluding the signature blobs themselves.

This binds the sender to the chain, nonce, validity window, gas parameters, account changes, calls, metadata and selected payer.

A malicious relay cannot replace the call list after the user signs.

It cannot silently change the payer field.

It cannot extend valid_before without changing the signed transaction.

It cannot add an actor configuration change that the sender did not authorize.

This is the cryptographic base layer for everything else in the transaction.

Gas sponsorship is separate authority, not merely a UX convenience

One of account abstraction's major user-experience improvements is the ability to separate the account performing an action from the account paying for gas.

EIP-8130 models this explicitly.

The payer field can be empty, meaning the sender pays.

It can name the sender account while a different actor on that account authorizes payment.

Or it can name a completely different payer account acting as a sponsor.

Sender and payer use separate signature domains

The current proposal uses separate type domains for sender authorization and payer authorization.

This prevents a signature intended to authorize spending gas from being repurposed as a transaction-sender signature, or vice versa.

That role separation matters because payer authority and sender authority are fundamentally different.

A sponsorship service might intentionally pay fees for thousands of users.

It should not thereby become able to initiate arbitrary transactions as those users.

Likewise, an ordinary session key should not automatically become a sponsor that can spend the account's ETH on strangers' transactions.

The payer signature is bound to the resolved sender to prevent cross-sender replay

Gas sponsorship creates a specific replay problem.

Imagine two different EOAs produce otherwise identical transaction structures.

If the payer signature did not commit to the actual resolved sender, the second user might reuse sponsorship authorization originally issued for the first user.

EIP-8130 closes this by placing the resolved sender address in the payer signature hash.

For the EOA wire format, where the sender field itself can be empty, the address recovered from sender_auth must be substituted into the payer hash.

This is a critical replay boundary for any gas-sponsorship system.

The sponsor's gas exposure is bounded by signed transaction parameters

A payer needs to know how much gas it can be forced to purchase.

The sender's transaction contains gas limit and fee fields.

The payer authorization signs the same transaction body under a separate payer domain.

The payer can therefore evaluate calls, fees, sender, gas limit and other signed fields before agreeing to sponsor.

The proposal also isolates payer-authentication cost from the sender's execution gas pool.

This prevents a malicious sponsor from choosing an unusually expensive payer authenticator that consumes the sender's gas budget and changes execution behavior.

The sender-side execution budget remains determined by sender-signed fields.

SELF_PAYER can expose the account's ETH balance to gas spending

A restricted actor that cannot move arbitrary assets can still create meaningful loss if it is allowed to pay gas from the account.

Suppose a session key has POLICY | SELF_PAYER.

The policy manager restricts its application actions correctly.

But the actor can submit large numbers of permitted transactions and consume ETH through fees until expiry or revocation.

The current draft explicitly notes that SELF_PAYER authority exposes the account balance to gas spending.

Wallets should therefore distinguish "cannot transfer ETH" from "cannot cause ETH loss."

EIP-8130 uses multidimensional nonce channels

Traditional Ethereum EOAs have one sequential nonce.

That creates contention when multiple independent workflows want to submit transactions simultaneously.

EIP-8130 introduces a nonce_key plus nonce_sequence.

Restricted actors need NONCE scope for sequenced channels

An unrestricted admin can use any nonce channel.

A restricted actor without NONCE scope is limited to the nonce-free mode.

A restricted actor with NONCE scope can use the full sequenced nonce space.

This is another example of least privilege at the protocol layer.

A session key does not automatically gain access to long-lived ordered nonce channels merely because it can initiate a transaction.

Nonce-free mode trades ordering for short-lived replay control

Nonce-free mode deliberately avoids reading or incrementing a nonce slot.

The transaction must have a non-zero valid_before.

Replay protection then relies on a short accepted validity window and a replay identifier stored in bounded consensus state.

This is useful when many independent operations should be usable without fighting over nonce sequence.

It is also more subtle than ordinary sequential nonces.

valid_before is mandatory

A nonce-free transaction cannot be valid forever.

Its replay-state entry must eventually age out safely.

The chain keeps bounded replay state

Live replay identifiers are tracked so the same logical nonce-free transaction cannot be included repeatedly during its accepted window.

Replay capacity is consensus-sensitive

The replay buffer and maximum expiry window need coordinated sizing so live entries cannot be overwritten before they expire.

replay_id identifies the logical nonce-free transaction

A normal transaction hash is not suitable for nonce-free deduplication under this design.

The reason is that fee bumps and freshly generated signature bytes can change the full transaction hash without changing the logical action.

replay_id instead commits to the stable logical transaction fields, including:

• Chain ID.
• Resolved sender.
• valid_after.
• valid_before.
• Account changes.
• Calls.
• Metadata.
• Payer address.

It deliberately excludes fee fields and authorization blobs.

That means a fee bump remains the same logical transaction rather than creating another replay opportunity.

Likewise, generating another valid ECDSA signature over the same body does not create a new logical operation.

Fee bumping should not create another executable transaction

A user can raise priority fee to replace a pending transaction.

The full transaction hash changes.

In nonce-free mode, replay_id does not.

The mempool therefore recognizes the higher-fee version as a replacement candidate for the same logical transaction.

The validity window cannot be silently extended through this mechanism because valid_after and valid_before are included in replay_id.

Changing either creates a different logical transaction.

valid_after and valid_before constrain transaction inclusion

The AA transaction includes both a lower and upper time boundary.

valid_after zero means there is no lower bound.

valid_before zero means no expiry for normal nonce modes.

Nonce-free mode requires a non-zero valid_before.

The current draft accepts values expressed in either seconds or milliseconds and normalizes them according to a fixed threshold.

For users, the security meaning is straightforward:

A transaction can be constructed so it is not valid before a chosen time.

It can also expire automatically after a chosen time.

This does not replace actor expiry.

Actor expiry controls the actor itself.

Transaction validity controls one transaction.

Local and Multichain account changes solve different problems

Actor configuration needs replay protection of its own.

EIP-8130 defines two signed change channels.

The distinction is essential for portable smart accounts.

A user might intentionally authorize a new passkey across every supported chain.

That is different from authorizing an application session key only on Base or Ethereum mainnet.

Wallet UX should make that difference explicit.

Multichain configuration is intentionally replayable across chains in an ordered way

Ordinary replay protection treats cross-chain reuse as a danger.

Multichain account configuration can intentionally need reuse across chains.

The EIP handles this through the Multichain channel and its monotonic sequence.

The user signs one configuration transition that can be applied to corresponding accounts on several compatible chains.

The configuration's portability is a feature.

The security problem becomes ensuring that the user understood the change was multichain rather than local.

Account lock freezes authority changes

EIP-8130 defines an account lock state that freezes actor configuration changes and delegation.

While locked, ordinary authority changes such as authorizing or revoking actors are rejected.

Two special operations remain available:

• Unlock, which begins the timed release process.
• IncrementLocalEpoch, which can still invalidate outstanding local signatures.

The lock is intended partly to make validated actor state more stable and predictable.

It can also have operational security value when a wallet wants to freeze its authority configuration.

Lock does not revoke existing actors

Locking the account freezes changes to the actor set.

Existing valid actors remain existing valid actors according to their scopes and expiries.

This is not an emergency "disable every session key" switch.

Unlock has a delay

The current draft stores an unlock delay in a uint16 field, creating a bounded delay before configuration can be changed again.

This can provide reaction time around authority-state changes while avoiding a permanent self-brick configuration.

The delegate authenticator lets one account act for another

Delegated actor authentication can be useful for subaccounts and account hierarchies.

Account A can authorize Account B as a delegate actor.

A key capable of authenticating as B can then authenticate as A, constrained by whatever scope A assigned to that actor.

This does not mean B automatically receives admin rights.

The granted scope still matters.

Delegation depth is intentionally limited

The current proposal does not allow the delegate authenticator to recursively delegate through another delegate authenticator.

The nested authenticator must be canonical.

This keeps validation work bounded and avoids deep chains of account-to-account authority that would be expensive and difficult to reason about.

Actor delegation and EIP-7702 code delegation are different

EIP-8130 uses the word delegation in more than one context.

The delegate authenticator concerns who can authenticate for an account.

A delegation entry in account_changes concerns EIP-7702-style code delegation for the sender account.

Those are different security surfaces.

Under the current draft, code delegation through the 8130 transaction path requires native secp256k1 self-authentication and administrative authority.

A passkey that happens to represent the same account identity is not automatically allowed to perform the EIP-7702 delegation step.

This restriction is intended to preserve compatibility with the existing EIP-7702 authorization model.

New accounts commit their initial actors into the address

EIP-8130 supports new accounts that have no pre-existing EOA owner.

The account address is derived using CREATE2 and commits to:

• A user-chosen salt.
• The runtime wallet bytecode.
• The initial actor set.
• Each actor's actorId.
• Each actor's authenticator.
• Each actor's scope.
• Policy data where POLICY is enabled.

This helps prevent an attacker from taking a known counterfactual account address and deploying it with a different actor configuration.

The actor set itself contributes to the derived address.

Actor ordering must be deterministic

Initial actors are sorted strictly by actorId.

This ensures one canonical address for one actor set and rejects duplicate actorIds.

Predicted addresses need the same validation as creation

A wallet should not display a counterfactual address that can never actually be created with the proposed actor configuration.

Otherwise the user could fund an address whose intended account configuration is invalid.

Existing smart accounts can import actor configuration

EIP-8130 is not limited to newly created accounts.

Existing smart contracts can import into the Keystore model through an authorized account import process.

The specification also aims for portability to chains that do not support the native 8130 transaction type.

On those chains, the same keystore and authenticator contracts can be used through ordinary EVM paths and systems such as ERC-4337.

This distinction is important.

EIP-8130 account configuration is broader than the new transaction transport.

An account can use the configuration model even where native AA_TX_TYPE support does not exist.

Calls execute directly from the sender account

The protocol dispatches each configured call with the sender account as the caller.

The target sees msg.sender as the sender account.

The protocol-level call entry does not include ETH value.

If ETH needs to move, the wallet's own bytecode performs the value-bearing CALL.

This keeps protocol-level execution simpler while preserving the ability of the smart account to transfer ETH.

Call phases create intentional partial-commit semantics

The calls field is not merely a flat batch.

It is an array of phases, and each phase is itself an ordered group of calls.

Calls inside one phase are atomic.

If one call in the phase fails, all state changes from that phase roll back.

Later phases are skipped.

But earlier completed phases remain committed.

This is a major difference from an all-or-nothing multicall.

Partial execution can be intentional

A sponsor-payment phase can commit before a later user-action phase.

That can be a useful economic design.

Partial execution can surprise users

A wallet that displays "Batch of three actions" without explaining phase boundaries can create false expectations.

If a later action fails, the user may assume earlier state changes were also reverted when they were not.

POLICY gating applies across every call phase

When the sender actor has POLICY scope, the protocol resolves the actor's allowed manager target before call execution.

Every call in every phase is checked against that target.

An earlier call cannot reconfigure the policy manager and then use the new target later in the same calls execution.

The gate is based on the resolved snapshot.

This prevents a transaction from using an early configuration change to widen a restricted actor's target during the same operation.

A policy-target violation consumes the transaction opportunity

If a POLICY actor tries to call a target other than its manager, the protocol does not dispatch the call.

The relevant phase fails.

Later phases are skipped.

Earlier completed phases remain committed according to normal phase semantics.

The transaction is still included and its nonce can be consumed.

This is important for retry logic.

A wallet should not assume it can simply correct the target and resend with the same sequential nonce after inclusion.

Transaction metadata is signed but does not change execution

EIP-8130 includes an opaque metadata field.

It can contain attribution, payment references, application codes, or commitments to off-chain data.

The metadata is covered by sender and payer signature payloads.

That makes it tamper-evident.

But metadata does not itself affect protocol validation or call execution.

Wallets should avoid presenting arbitrary metadata as if it were an enforced policy unless another system actually interprets and enforces it.

Configured actor signatures include the authenticator address

For configured actors, sender_auth starts with the authenticator address followed by authenticator-specific signature data.

This lets the transaction declare which verification mechanism is required.

The protocol then authenticates the signature and receives actorId.

After that it reads account authority from the Keystore.

The security chain is therefore:

Failure at any stage means the actor is not authorized for that context.

Passkeys become one actor type rather than a separate account model

One attractive property of EIP-8130 is that a passkey does not have to replace the entire account architecture.

The passkey can be one actor.

A hardware secp256k1 signer can be another actor.

A P-256 security key can be another.

A restricted application session key can be another.

The account address and asset ownership can remain stable while authentication methods evolve.

This matches Ethereum's wider account-abstraction direction toward flexible authentication and recovery rather than permanent dependence on one seed phrase.

Hardware signing still has an important role

Protocol-level support for several authenticators does not make high-assurance key custody obsolete.

An administrative secp256k1 actor can still be protected by a device such as Ledger.

An air-gapped signing workflow such as Keystone can similarly reduce exposure of a root ECDSA credential.

The critical point is to match credential strength to actor authority.

A scope-zero admin deserves stronger protection than a seven-day application session key.

A sponsor key controlling a large gas treasury deserves stronger protection than a limited self-paying session actor.

A compromised frontend can target account configuration itself

A malicious DApp does not need to steal a private key if it can convince the wallet to install an attacker-controlled actor.

Actor substitution

The page claims it is adding the user's passkey but the configuration change contains an attacker actorId.

Scope escalation

The interface says "session key" but the encoded scope is 0x0000 admin.

Policy removal

The user expects a POLICY actor but receives unrestricted SENDER authority instead.

Expiry removal

The user expects seven-day access, but expiry is zero.

SPONSOR_PAYER escalation

A key intended only to self-pay is granted authority to sponsor third-party transactions.

Multichain escalation

A user expects a local actor change, but signs a Multichain configuration batch.

This is why account-configuration clear signing is at least as important as transaction clear signing.

A realistic session-key authorization sequence

Consider a user who wants a trading application to execute limited actions for seven days without requesting the primary hardware signer every time.

A good wallet would not summarize that sequence as "Enable trading."

It would show the exact authority being installed.

How a session key becomes overbroad

Several small configuration mistakes can turn a reasonable session key into a dangerous one.

Using SENDER instead of POLICY

The actor can originate calls to arbitrary targets rather than one manager.

Using scope zero

The actor becomes an administrator.

Setting expiry to zero

The key becomes non-expiring.

Adding SELF_PAYER unnecessarily

The actor gains the ability to consume ETH through gas expenditure.

Adding SPONSOR_PAYER unnecessarily

The actor may be able to authorize the account to pay gas for other senders.

Using an upgradeable policy manager

Future manager logic can rewrite the practical limits of the session.

Using manager = account with unsafe self-call behavior

The wallet's own code can accidentally turn a policy-restricted actor into something effectively unrestricted.

Actor inventory is part of wallet security

Users need a reliable way to answer a simple question:

Who can currently act for my account?

The Keystore does not require an on-chain array of actors for enumeration.

Actor addition and revocation events can be indexed off-chain to build the actor inventory.

Wallets should surface that inventory prominently.

Configuration signatures have their own replay model

Configuration changes are not secured only by the transaction nonce.

A SignedAccountChanges batch has its own channel and sequence.

That allows the same signed actor change to be transported through the 8130 account_changes transaction field or through an EVM call to applySignedAccountChanges.

Anyone can relay that signed batch.

Authorization comes from the administrative signature, not the relay caller.

This makes account management portable.

It also means leaked signed configuration payloads need proper retirement through sequence or epoch rules rather than assuming the person who received the signature is the only entity capable of applying it.

Account changes are applied in order

One transaction can contain account creation, configuration changes and delegation updates before normal call execution.

Ordering therefore matters.

A later configuration batch is validated against actor state after earlier changes have been applied.

This enables intentional authority rotation in one operation.

It also means wallet simulation must display the final authority state, not merely list independent changes without order.

Account lock can help stabilize a high-risk configuration

A sponsor service or high-value account can choose to freeze its actor configuration.

This narrows the state capable of invalidating pending authenticated transactions.

Operationally, it can also create a security posture where actor changes require a deliberate unlock sequence.

However, lock is not a substitute for revocation.

If a dangerous actor is already installed, locking the account can actually make immediate actor removal unavailable until the account is properly unlocked.

The correct incident action depends on current account state.

Partial execution needs special attention during sponsored workflows

The EIP itself gives a sponsor-plus-user pattern as an example of separate call phases.

Phase 0 can perform sponsor payment.

Phase 1 can perform the user's application actions.

If Phase 0 commits and Phase 1 later fails, the sponsor-related state change can remain.

This may be exactly what the protocol intends.

It may also surprise a user who expected the whole operation to revert.

Wallets and DApps need to make phase boundaries understandable whenever they have material economic effects.

Independent transaction verification remains necessary

EIP-8130 can make authority more structured.

It does not make every transaction safe automatically.

An actor can be legitimately authorized and still sign a malicious transaction.

A policy manager can contain a bug.

A valid sponsored transaction can call a dangerous contract.

A batch can intentionally commit earlier phases before a later failure.

TokenToolHub's Transaction Decoder remains useful for examining actual calls, token transfers, approvals, nested execution, gas behavior and final transaction outcome.

Actor authority and token approvals are independent

Revoking an EIP-8130 actor does not automatically revoke ERC-20 approvals previously created while that actor was active.

Suppose a session key is compromised.

The attacker uses a valid actor transaction to grant a malicious spender unlimited USDC allowance.

The user notices and revokes the actor.

The actor can no longer authenticate.

The ERC-20 allowance remains.

The Crypto Approval Risks guide explains this persistent spender layer.

The Permit2 and Allowances guide covers Permit2-specific reusable authority that also needs separate review.

Incident response for a compromised actor

Worked EIP-8130 account security scenarios

Scenario 1: safe seven-day app session

A wallet authorizes a passkey-derived actor with POLICY scope.

The manager enforces a two-token allowlist and a daily spend cap.

The actor expires after seven days.

It has SELF_PAYER because the user wants frictionless app usage.

It does not have SPONSOR_PAYER.

It does not have admin scope.

This is a reasonable least-privilege pattern as long as the policy manager is secure and the user understands gas-spending exposure.

Scenario 2: frontend silently installs an admin

A DApp presents "Enable session."

The account change actually authorizes the actor with scope 0x0000.

The new actor is an account administrator.

It can later modify actor configuration.

The UI wording was completely misleading.

A secure wallet should independently decode the actor scope and show that root authority is being installed.

Scenario 3: revoking the old admin does not remove a malicious child actor

An attacker compromises Admin A.

Before detection, Admin A authorizes Actor M with SENDER authority and no expiry.

The owner recovers the account and revokes Admin A.

Actor M remains in actor_config because installed actors do not depend on live authorizer lineage.

The account is still compromised until Actor M is separately revoked.

Scenario 4: expired session actor

A policy actor has expiry set to midnight.

At 00:01 the actor's authentication is rejected.

The policy manager's own storage may still contain session parameters, but the actor can no longer reach it through account authority.

The wallet can clean manager-side state separately.

Scenario 5: sole admin expires

A wallet mistakenly puts a 30-day expiry on its only administrative actor.

After 30 days the admin can no longer authenticate.

No non-expiring root remains to rotate actors.

This illustrates why the draft recommends keeping administrative ownership non-expiring unless the wallet deliberately has another recovery-grade root.

Scenario 6: SELF_PAYER drains gas balance

A session key cannot transfer arbitrary ETH or tokens due to its policy.

It can self-pay gas.

An attacker obtains the key and repeatedly submits permitted high-cost operations.

The policy remains technically respected while the account's ETH balance declines through gas expenditure.

Gas authority is therefore economically meaningful permission.

Scenario 7: sponsor signature replay attempt

A sponsor signs gas authorization for User A.

User B copies the transaction structure and tries to reuse the payer signature.

The payer digest includes the resolved sender.

User B's sender differs.

The payer signature no longer validates for that transaction.

Scenario 8: fee bump in nonce-free mode

A nonce-free transaction sits pending with a low priority fee.

The wallet resubmits it with a higher fee.

The full transaction hash changes.

The replay_id remains the same because fee fields are excluded.

The network treats it as replacement of the same logical operation rather than a second independently executable transaction.

Scenario 9: re-signing ECDSA does not create a fresh logical nonce-free transaction

The same transaction body is signed again, producing different ECDSA signature bytes.

The transaction hash changes.

replay_id still identifies the same logical transaction.

The alternate signature cannot bypass deduplication.

Scenario 10: JIT authorization remains replayable

A wallet signs an unsequenced local actor authorization but never broadcasts it.

Weeks later the user decides the authorization should never land.

Merely assuming it is forgotten is unsafe.

The wallet increments local_epoch.

The old signature becomes stale and cannot land under the new epoch.

Scenario 11: epoch bump after actor already landed

A malicious JIT batch already authorized Actor X.

The user increments the local epoch.

The old JIT signature is invalidated for future replay.

Actor X remains live because it already exists in actor_config.

The user must also revoke Actor X.

Scenario 12: policy manager upgrade breaks least privilege

A session actor is restricted through POLICY to Manager P.

At authorization time, P allows only 20 USDC per day.

P is upgradeable.

The manager administrator later upgrades it to permit arbitrary account calls.

The actor did not change.

The practical authority behind its policy did.

Scenario 13: manager equals account and self-call bypasses policy

A wallet configures manager = account.

The account's execute function trusts any self-call.

The policy actor calls the account because that is its permitted target.

The account forwards arbitrary operations without checking the policy commitment.

The supposedly restricted actor becomes effectively unrestricted.

Scenario 14: later phase fails after sponsor-related phase succeeds

A transaction has sponsor payment logic in Phase 0 and user application actions in Phase 1.

Phase 0 succeeds.

Phase 1 reverts.

Phase 0 remains committed.

The user or protocol must understand that the calls structure provides phase-level atomicity, not whole-transaction all-or-nothing behavior.

Scenario 15: multichain passkey authorization

A user wants one new passkey to control the same account configuration on several EVM chains.

The wallet signs a Multichain change batch.

The batch can be relayed on compatible chains in sequence.

This is intentional cross-chain replay rather than a vulnerability, provided the user understood the multichain scope.

Scenario 16: local session accidentally signed as multichain

A DApp session is intended only for one network.

A malicious interface asks the admin to sign a Multichain account change.

If relayed elsewhere, the actor can become authorized on additional chains.

Wallets should never hide whether a configuration signature is Local or Multichain.

Scenario 17: approval survives session-key revocation

A compromised session actor grants unlimited token approval while it is still valid.

The user revokes the actor.

The token contract still records the malicious spender allowance.

The user must revoke that allowance separately.

Scenario 18: account lock misunderstood as emergency shutdown

A dangerous session actor already exists.

The user locks the account believing this disables all actors.

The lock freezes configuration changes but does not automatically invalidate the existing actor.

The compromised actor can remain usable according to its existing scope.

Emergency UX must explain the difference between freezing configuration and revoking authority.

Scenario 19: restricted actor uses wrong nonce channel

An actor has SENDER but no NONCE grant.

It attempts to use a normal sequenced nonce_key.

Validation rejects the transaction.

The actor must use nonce-free mode or be granted NONCE authority.

Scenario 20: payer account is changed after sender signs

A relay attempts to replace the sponsor address with a different payer.

The sender signature includes the payer field.

Changing payer changes the signed transaction and invalidates sender authorization.

EIP-8130 security risk matrix

User checklist before approving an account-configuration change

Wallet-builder checklist

Gas-sponsor operator checklist

Post-transaction verification workflow

Account abstraction improves authorization flexibility.

It does not eliminate the need to verify blockchain effects.

EIP-8130 belongs inside a layered wallet-security model

An actor model can reduce the need to expose root credentials to routine application activity.

It can provide limited session keys.

It can separate gas sponsorship from user authority.

It can support passkeys.

It can make recovery-grade administrators distinct from everyday actors.

But each layer still has failure modes.

The authenticator can be compromised.

The actor scope can be too broad.

The policy manager can be vulnerable.

The gas key can be abused.

The user can sign a malicious call.

A persistent token approval can survive actor revocation.

A multichain configuration signature can reach more networks than intended.

TokenToolHub's Wallet Safety 101 provides a broader framework for keeping root authority, app sessions, approvals and operational wallet activity appropriately separated.

How EIP-8130 fits Ethereum's account-abstraction direction

Ethereum's account-abstraction roadmap increasingly focuses on making smart-account capabilities native rather than forcing them through layers of relayers, bundlers and wrapper transactions.

EIP-7702 already made EOAs capable of delegating to smart-contract code.

ERC-4337 established a widely used account-abstraction system without requiring core protocol changes.

Frame-transaction proposals such as EIP-8141 explore deeper protocol support for smart-account validation.

EIP-8130 takes a different but related approach by making actor configuration, authenticator declaration and transaction authorization more structured and predictable.

Its keystore architecture also attempts to keep the account portable across chains where the native transaction type may not exist.

Crypto agility may become one of the proposal's most important long-term properties

Ethereum accounts currently rely heavily on secp256k1.

Future wallet systems may need different authentication algorithms for usability, hardware support or cryptographic migration.

EIP-8130 does not permanently bind an account address to one authenticator.

Actors reference authenticator contracts through account configuration.

A new authenticator can be added later.

An old actor can be revoked.

Assets do not need to move to a new account address merely because the authentication algorithm changes.

This separation between account identity and authentication method is a useful foundation for long-lived smart accounts.

Common EIP-8130 misconceptions

Scope 0 means no authority

False. In the current proposal, scope 0x0000 means unrestricted authority and is the admin predicate.

SENDER means admin

No. SENDER grants ungated transaction initiation but does not by itself grant account-configuration administration.

POLICY means the protocol understands the spend limit

No. The protocol gates the actor to one manager target. The manager interprets and enforces the policy commitment.

A POLICY actor cannot be dangerous because it can call only one address

False. If that manager is buggy, malicious or upgradeable, it can become a powerful authority path.

Revoking the admin that created a session key revokes the session key

No. Installed actor authority is flat. The session actor remains until its own expiry or explicit revocation.

IncrementLocalEpoch revokes all actors

No. It invalidates outstanding unlanded Local configuration signatures from earlier epochs. Live actors remain installed.

IncrementLocalEpoch invalidates Multichain signatures

No. The Multichain channel is governed by a separate monotonic counter.

Account lock disables every actor

No. Lock primarily freezes actor changes and delegation. Existing actors are not automatically revoked.

Expiry and valid_before are the same thing

No. Actor expiry controls actor authority. valid_before controls one transaction's validity window.

A nonce-free transaction has no replay protection

False. The design uses a required short validity window plus replay_id deduplication in bounded consensus replay state.

The full transaction hash should be used for nonce-free deduplication

No. Fee bumps and alternative authorization bytes can change the transaction hash while representing the same logical transaction.

A gas sponsor can change the transaction after the sender signs

No. Calls, account changes, payer address and fee fields are part of the signed transaction body. Sponsor authorization is an additional independent signature.

A SELF_PAYER actor cannot lose funds because it cannot transfer ETH

False. It can still consume ETH through gas fees.

SPONSOR_PAYER is just a cosmetic gas preference

No. It is explicit authority over paying another sender's transaction gas.

All calls in one 8130 transaction revert together

No. Calls inside a phase are atomic, but completed earlier phases remain committed if a later phase fails.

EIP-8130 replaces ERC-4337 everywhere immediately

No. EIP-8130 is still Draft and explicitly supports portability to non-8130 chains where ERC-4337 or other transport may continue to be used.

Every authenticator is accepted on every chain

No. Canonical authenticators form the universal baseline. Acceptance of additional authenticators depends on chain policy and adoption profile.

A passkey automatically has full account authority

No. The passkey proves an actor identity. The actor's configured scope determines authority.

Revoking an actor reverses transactions it already executed

No. Completed transfers, approvals, loans and other state changes remain on-chain.

A practical EIP-8130 verification framework

The account can be analyzed through eight questions.

Which account?

Verify the sender address and chain.

Which actor?

Identify the actorId being authenticated or installed.

Which authenticator?

Determine whether authority comes from k1, P-256, passkey, delegate or another supported authenticator.

Which scope?

Do not rely on labels. Decode the bitmask.

Which expiry and policy?

Check time limits, policy manager and signed commitment.

Which replay mode?

Determine whether the operation uses standard nonce, parallel 2D nonce, nonce-free replay_id, Local configuration sequence, JIT epoch or Multichain sequence.

Who pays gas?

Identify sender-paid, dedicated self-payer or third-party sponsor mode.

What survives execution?

Understand phase boundaries, resulting approvals, actor state and completed asset movements.

Conclusion: EIP-8130 turns account authority into explicit on-chain configuration

EIP-8130 account configuration attempts to make Ethereum account abstraction more predictable by separating identity authentication from account authorization.

The authenticator answers who is proving control.

The Keystore answers what that actor is allowed to do.

The transaction commits to the actual calls, account changes, payer relationship, fees, timing and replay context.

That separation opens the door to much richer wallet security.

A user can keep a strong administrative root while authorizing a short-lived application actor.

A passkey can coexist with an ECDSA hardware signer.

A sponsor can pay gas without becoming the sender.

A policy manager can enforce spend caps or application allowlists.

Independent nonce channels can support concurrent workflows.

A short-lived nonce-free transaction can avoid sequence coordination while still having replay protection.

Multichain account-change signatures can synchronize actor configuration across compatible chains.

Those benefits depend on extremely precise authority reasoning.

The most important rule is that actor scope must be treated as security-critical configuration.

Scope zero is not empty.

It is administrator authority.

SENDER is operational power.

POLICY creates a gate to a manager that becomes a trust anchor.

NONCE determines access to sequenced transaction channels.

SELF_PAYER creates economic authority over the account's gas balance.

SPONSOR_PAYER creates authority to pay for other accounts' transactions.

Wallets need to present these differences in language that maps to actual consequences.

Expiry also needs to be understood at the correct layer.

A temporary actor can expire automatically.

That does not erase manager-side application data.

A transaction's valid_before does not revoke an actor.

A local epoch increment does not revoke actors that already landed.

Revoking the administrator that created another actor does not recursively revoke that actor.

Each mechanism solves a different lifecycle problem.

This becomes particularly important during incident response.

If an administrative key is compromised, rotating that key is not enough.

The wallet needs to enumerate every actor the attacker may have installed.

Those actors need explicit revocation.

Outstanding Local configuration signatures may require an epoch increment.

Multichain account state needs to be checked separately.

Any ERC-20, Permit2 or NFT approvals created while the attacker controlled a valid actor need independent cleanup.

Any code delegation or policy-manager changes also need review.

Gas sponsorship introduces another authority plane.

The sender chooses and signs the payer address.

The payer signs under a separate domain.

The resolved sender is included in payer authorization so one user's sponsorship approval cannot simply be replayed by another sender.

SELF_PAYER and SPONSOR_PAYER remain independent scope grants.

This makes gas payment explicit rather than an incidental relayer service.

Replay protection is equally layered.

Standard and 2D channels use nonce sequences.

Nonce-free transactions use replay_id plus a short validity window.

Local configuration changes use local epoch and local sequence.

Unsequenced JIT changes remain replayable until the epoch changes.

Multichain configuration uses a separate monotonic counter so the same portable state transition can be applied intentionally across chains.

Using the wrong mental model for any of these replay domains can leave stale authorization alive longer than expected.

Execution semantics deserve the same attention.

An EIP-8130 calls array is divided into phases.

Calls inside a phase are atomic.

The whole transaction is not necessarily globally atomic across every phase.

Earlier successful phases can remain committed if a later phase fails.

That behavior can be useful for sponsorship and settlement design, but wallets must surface it clearly.

TokenToolHub's Transaction Decoder remains relevant because successful authentication does not prove safe economic execution.

The Clear Signing in Crypto guide addresses the user-facing requirement to explain actor changes, payer changes, calls and delegation before the signature is produced.

The Crypto Approval Risks guide and Permit2 and Allowances guide cover persistent spending authority that actor revocation alone does not remove.

And Wallet Safety 101 provides the broader operational framework for separating root keys, routine activity, application sessions and incident-response paths.

EIP-8130 is still a draft.

The exact protocol path can change.

But the security model points toward a useful long-term direction:

That flexibility can make Ethereum wallets substantially safer and easier to use, provided wallet interfaces expose the real authority graph rather than hiding it behind generic labels such as "Connect," "Enable," or "Session."

FAQs

References and further reading

These official Ethereum resources provide the primary technical basis for EIP-8130 account configuration and its wider account-abstraction context.

• EIP-8130: Keystore Accounts
• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-7702: Set Code for EOAs
• ERC-1271: Standard Signature Validation Method for Contracts
• Ethereum Improvement Proposals
• Ethereum.org: A More Secure Ethereum
• Ethereum.org: Account Abstraction

EIP-8130 remains a Draft Core proposal. Transaction format, authenticator acceptance rules, gas schedules, canonical contract addresses, replay parameters, keystore internals and deployment plans can change before finalization or network inclusion. Security also depends on the wallet implementation, authenticator contracts, policy managers, actor configuration and chain-specific adoption profile. This guide is educational security research and is not financial, legal, custody or software-audit advice.