Multichain & portability

Account types

Three paths into native AA. All share the same Account Configuration contract and authenticator model; they differ in how the account gets code and its first actors.

CREATE2 uses ACCOUNT_CONFIG_ADDRESS as deployer, so the same salt and actors yield the same counterfactual address on every chain that deploys Account Configuration at that address. Funds can land before the account exists anywhere.

EIP-7819 delegate factory (outlook)

Cross-chain account changes

Config changes are signed state transitions with a chain_id and a sequence counter. Two independent channels live in the packed account-state slot:

One signature, many chains

An admin signs chain_id = 0 once. Relayers (or the wallet) submit the identical payload to each deployment. Each chain checks the signature against its own multichain_sequence, applies authorize/revoke operations, and increments. Nothing bridges or pushes: portability is replayable, not auto-synchronized.

// Same signed digest, two transports:

1. account_changes in an 8130 tx   → protocol applies before calls
2. applySignedActorChanges()       → ordinary EVM call (any chain,
                                     including non-8130 / ERC-4337)

Design choices to know

• No expiry on multichain changes: intentional. A chain_id 0 update stays replayable forever, including on chains that deploy Account Configuration later. Per-chain policies use the local channel (and can expire when applied).
• Lock is local-only: applySignedLockChanges binds local_sequence only. A locked chain silently rejects config changes while unlocked chains accept the same multichain payload.
• Sequences assume lockstep: the digest commits to a specific sequence value. Partial relay leaves lagging chains unable to accept a later update until reconciled.
• Admin only: config changes require scope == 0x00.

Delegation account change vs EIP-7702

EIP-7702 added authorization_list as a separate transaction-level field for pointing an EOA at shared implementation code, with ECDSA authority. 8130 folds that into account_changes:

rlp([
  0x02,    // type: delegation
  target   // address to delegate to, or address(0) to clear
])

• Sets code = 0xef0100 || target (same indicator as 7702). Allowed only on empty accounts or accounts that already hold a delegation designator; never replaces non-delegation bytecode.
• Authority is the native secp256k1 self-actor (EOA path or K1_AUTHENTICATOR) with admin scope. That keeps code delegation portable: the same ECDSA authority works via standard 7702 txs on non-8130 chains.
• First AA tx for a code-less EOA auto-delegates to DEFAULT_ACCOUNT_ADDRESS if no create/delegation entry is present, so EOAs get wallet code without a prior 7702 ritual.
• 8130 chains MUST support the delegation indicator even when standalone 7702 transactions are not enabled.

What this fixes in practice: install (or clear) code delegation in the same 8130 transaction as actor changes and calls: one sender_auth, no parallel authorization_list ceremony. Non-8130 chains keep using standard 7702 for the same indicator until they adopt 8130. With the EIP-7819 delegate factory, factory-created accounts get that delegation entry for every key type.

Standalone EIP-7702 transactions should also be considered for deprecation alongside 8130 adoption: they are ECDSA-only by construction and therefore not quantum-safe. Prefer the 8130 delegation account change (and, once available, authenticator-agnostic factory delegation) so code pointing rides the same scheme-agile auth path as everything else.

8130 vs non-8130 chains