Onboarding & account creation

Three paths

EOAs work as-is

An existing secp256k1 EOA is already a valid 8130 sender. It signs sender_auth with the same key, and the protocol authenticates it through native ecrecover on the implicit self-actor (actorId == bytes32(bytes20(account)), admin scope 0x00). There is no deployment and no pre-registration.

If the account has no code, the protocol auto-delegates it to DEFAULT_ACCOUNT_ADDRESS on its first AA transaction (a 4,600 gas delegation-indicator deposit), so the EOA gets wallet code without a prior EIP-7702 ritual. An account MAY instead point somewhere else with a delegation entry in account_changes or a standard EIP-7702 transaction. The details of delegation vs 7702 live in Multichain & portability.

Existing smart accounts: importAccount

A contract wallet that is already deployed does not create a new address; it registers itself with a one-time importAccount(account, chainId, initialActors, signature) call on the Account Configuration contract. The initial actor set is the wallet's starting keys and scopes.

• Authorized by the wallet: the signature is validated against the account via ERC-1271 isValidSignature, so the import is approved by the wallet's existing authorization logic, not by a new key.
• One-time bootstrap: rejected unless both the local and multichain change-sequence channels are empty. A wallet that already has 8130 state (including a lock) cannot be re-imported.
• Phishing-resistant digest: the signed ActorInitialization struct hash is bound to the account address and deliberately omits the EIP-712 domain separator, so it will not be produced by a normal wallet signing flow.
• Portable domain: chainId = 0 makes the import valid on every chain; otherwise it MUST equal the current chain, mirroring applySignedActorChanges.

Imported actors carry scope and policyData just like a create entry (and unlike create, a self-referential manager = account is expressible). Their expiry is always 0; expiry is added afterward with a config change.

New accounts: the account config as factory

A brand-new account (no EOA behind it) is created with a create entry (type 0x00) in account_changes. The Account Configuration contract is the deployer: the address is derived with CREATE2 from the initial actors, so the counterfactual address binds each actor's authority before any code exists.

• Deterministic address: initial_actors must be sorted by actorId in strictly ascending order (also rejecting duplicates), so a given actor set always derives the same address.
• Code + init in one tx: on 8130 chains the protocol places the runtime code directly and configures actors; calls in the same transaction handle any further initialization. On non-8130 chains, createAccount() runs the same derivation through CREATE2 init code.
• Freshness: the destination must be empty (code_size == 0 and nonce == 0), matching the conditions CREATE2 would enforce.
• Not expressible at create: expiry and a self-referential manager = account (the address is not known at commitment time). Both are added by a config change entry that MAY accompany the create in the same account_changes array for atomic setup.

Defaults: quantum-safe root

Both createAccount and importAccount set the DEFAULT_EOA_REVOKED flag by default, so a newly created or imported account does not leave a live native secp256k1 owner unless one is explicitly in initial_actors. That is a quantum-safe default: onboarding onto a P-256 or passkey owner does not silently keep a quantum-vulnerable key as a backdoor. An owner who wants to keep the secp256k1 key includes the self-actorId as a K1_AUTHENTICATOR entry in the initial set, which is lossless: still a full owner, now resolved through its inline default-EOA config. The pure EOA path is the exception: it never revokes, precisely because the key is the account.