Protocol
Authenticators & locks
Authenticators are permissionless contracts at deterministic addresses, so 8130 works on every EVM chain and supports recovery flows in the EVM. Account locks exist for one reason: granting trusted accounts higher rate in the mempool.
Why authenticator contracts
An authenticator takes authenticate(hash, data) and returns an actorId. The protocol never carries algorithm-specific logic: a new signature scheme is just a new contract behind the same interface.
- Permissionless deployment: anyone can deploy an
IAuthenticatorand register it on an actor. That is what enables wallet-defined recovery methods and other custom flows. - Usable in the EVM: non-canonical authenticators still work through ordinary EVM execution (e.g. a recovery authenticator invoked via a config-change call). They just cannot authenticate directly on the native 8130 hot path.
- Works on every EVM chain: the Account Configuration contract and the canonical authenticators are CREATE2 deployments at deterministic addresses, so the same account and authenticators exist at the same addresses across chains.
Canonical on the hot path
For block-level authentication the node accepts only the canonical set (k1, P-256, passkey, delegate; grown via a companion ERC). A shared baseline means a wallet using canonical authenticators knows any compliant node will accept its transactions, avoiding a fragmented network where each node allows a different mix of algorithms. Non-canonical authenticators remain fully usable inside the EVM; only the native path is restricted. How that growth path works for post-quantum schemes is covered in Post-quantum & scheme agility.
Why account locks
The mempool bounds how many pending transactions one account can have by the invalidation surfaces those transactions depend on. A lock freezes the actor set, which makes the signer surface stable: a config change can no longer invalidate a validated transaction, so that surface can no longer flip. With the signature blast radius driven to zero, nodes can safely raise the per-account signature rate.
Higher payer rate: trusted bytecode
A locked account running trusted bytecode can also earn a higher payer rate. The account code guarantees that while locked, the account will not move ETH by any path other than gas payments. If ETH can only leave through gas, then the reserved sum Σ max_cost is a true upper bound on the only drain, so a node can admit sponsored transactions while reserved ≤ balance instead of applying a blunt payment count.
| Concept | Meaning |
|---|---|
| Locked (any code) | Signer surface frozen → signature blast is zero → higher sender rate. |
| Locked + trusted bytecode | ETH only moves via gas → balance-bounded payer accounting → higher payer rate. |
Higher-throughput accounts
Put together, lock turns an account into a higher-throughput actor on whichever side it operates:
- High-throughput senders: a locked account with a frozen actor set can keep many transactions in flight without config churn invalidating them.
- High-throughput payers: a locked, trusted-bytecode sponsor is bounded only by its balance, so it can underwrite many concurrent sponsored transactions.
The exact counters and the balance-book accounting live in Mempool design · account limits, and the invalidation semantics in Invalidation & revalidation.