Guide
Mental model
The smallest set of concepts you need before writing code. Builders use this to design wallet flows; protocol readers use it as the map into the spec.
Core concepts
| Concept | Meaning |
|---|---|
| Account | An EOA or a smart account. Both work with 8130: existing EOAs send AA transactions with their secp256k1 key as-is; smart accounts are CREATE2 wallets governed by onchain Account Configuration (and existing contract wallets can import into that config). |
| Actor | A key authorized on the account: { actorId, authenticator }, with scope, optional expiry, and optional policy. |
| Authenticator | Canonical authenticator contract (K1, P-256, passkey, delegate, …) that recovers an actorId from signature data. |
| Scope | Bitfield of grants: SENDER, POLICY, NONCE, SELF_PAYER, SPONSOR_PAYER. 0x00 is unrestricted admin (config / lock / delegation). |
| Account change | A create, config (authorize/revoke actors), or delegation operation applied atomically inside a transaction (or via applySignedActorChanges). |
| Auth blob | sender_auth / payer_auth bytes: bare 65-byte ECDSA for the implicit EOA path, or authenticator(20) || data for a configured actor. |
| Call phase | One atomic executeBatch. A transaction may contain multiple phases (e.g. pay token in phase 0, act in phase 1). |
| Payer | Optional co-signer that pays gas. May be a key you hold or an ERC-8168 payer web service. |
Validation pipeline
Every EIP-8130 transaction runs the same gate before execution. Keep this order in mind when debugging auth failures:
- Resolve: derive the effective authenticator and actorId from the auth blob.
- Authenticate: the authenticator verifies the signature material.
- Authorize: look up
actor_config[account][actorId](or the implicit EOA path), then check scope against the action (SENDER/POLICY, SELF_PAYER/SPONSOR_PAYER, admin, operational). - Execute: apply account changes, then run call phases.
Account shapes you will build
- Plain EOA: cheapest path: the sender is a secp256k1 key; auth is a bare 65-byte signature. Can later install smart-account code via delegation.
- Smart account: CREATE2 wallet with one or more initial actors (multi-key from day one).
- Templates: UpgradeableAccount (default), CanonicalHighRatePayerAccount (immutable / throughput), DefaultAccount (EIP-7702 delegate target), and BackwardsCompatible4337Account (portable).
Native vs portable
On Vibenet, the chain understands AA_TX_TYPE natively. On other chains, the same account address can execute through an ERC-4337 provider using the backwards-compatible implementation. Same salt and actors → same address. Details in Multichain.
What builders usually design next
Keys
Owner keys with broad scope; session keys with policy (spend limits, allowlists); optional payers for gas. Rotations can ride inside a user transaction (just-in-time) or land immediately via a no-op call tx.
Calls
Prefer batched calls in one phase when atomicity matters. Split into phases when sponsorship or ordering requires a clear boundary (pay, then act).
Nonces
Default path uses 2D nonces (key + sequence). High-throughput and fire-and-forget flows can use nonceless transactions with a tight expiry, covered later in Nonces & throughput.