Accounts, wallets and authorities

Why EIP-7702

EIP-7702 lets an EOA authorize delegated code while retaining the same address. ChatterPay B2B uses that property to expose a stable address before activation, receive funds before a smart-account write, and add programmable validation and execution later.

Stability holds on two axes. Over time, the address a user sees before activation is the one they keep after delegation, rotation, recovery and revocation. Across networks, one wallet has one EVM address: the identity is derived once per logical wallet and stays independent of the chain, so the same user's address on Arbitrum is the address on Base.

Delegation model

User EOA
→ EIP-7702 authorization
→ ChatterPay7702Proxy
→ AccountCoreImplementation
→ enabled modules

The stable proxy minimizes future EIP-7702 redelegations. Account Core holds validators, nonces, modules, recovery and ERC-4337 validation.

First activation

sequenceDiagram
    autonumber
    participant P as Partner / channel
    participant API as B2B API
    participant W as Operation Worker
    participant SG as Partner Signer Gateway
    participant REL as Relayer
    participant CH as EVM chain
    participant EOA as User EOA
    participant PX as ChatterPay7702Proxy
    participant CORE as Account Core

    P->>API: First outgoing operation
    API->>W: Operation accepted
    W->>CH: Check delegation
    CH-->>W: Plain EOA
    W->>SG: Sign EIP-7702 authorization
    SG-->>W: Authorization signature
    W->>SG: Sign bootstrap/root payload
    SG-->>W: Signature
    W->>REL: Type-4 tx + authorization list + init
    REL->>CH: Broadcast
    CH->>EOA: Install delegation designator
    EOA->>PX: Execute delegated code
    PX->>CORE: Initialize roles/modules
    CH-->>W: Receipt

What each step does

1. Partner → API: first outgoing operation. The address exists and holds funds before any of this. What triggers the activation is the first spend the user authorizes.
2. API → worker: the operation is accepted. The activation happens inside the operation that needed it, which is what keeps it out of the provisioning path.
3. Worker → chain: read the account's code. The worker asks whether the delegation is already installed.
4. Chain → worker. The account answers as a plain EOA, which is what tells the worker that this operation carries the activation.
5. Worker → gateway: sign the EIP-7702 authorization. The authorization is bound to the chain id, to the proxy the account delegates to, and to the account's nonce. Binding it to one chain is deliberate: an authorization valid everywhere would install code on every network with one signature.
6. Gateway → worker: authorization signature. It is signed with the key of the EOA, which holds the native EIP-7702 authority: whoever controls it decides what code the account runs.
7. Worker → gateway: sign the bootstrap payload. A second signature initializes the account, bound to the account, the implementation, the root authority, the chain and an expiry.
8. Gateway → worker: signature. The two signatures answer to different authorities — the one that delegates and the one that governs the account — and use different key references and versions, even when both derive from the same master key.
9. Worker → relayer: type-4 transaction. It carries the authorization list and the initialization call. The relayer pays the gas and broadcasts, and its authority ends there.
10. Relayer → chain: broadcast.
11. Chain → EOA: the delegation designator is installed. The account keeps its address and gains a pointer to the code it runs.
12. EOA → proxy: the delegated code runs. The account delegates to a stable proxy, so the implementation behind it can be upgraded under root authority while the user's address stays the same.
13. Proxy → Account Core: roles and modules are initialized. The core separates the operational validator that authorizes everyday operations, the root that administers, and the recovery authority that acts with a delay.
14. Chain → worker: receipt. A receipt with status 1 is weak evidence here: an authorization whose nonce stopped matching is discarded and the transaction mines anyway, so the worker verifies the account's delegation designator afterwards.

The authorization is bound to chain and nonce. Sharing an address across networks leaves delegation and state separate on each one.

EIP-7702 versus Account Abstraction

EIP-7702 and ERC-4337 solve different layers:

An EIP-7702 account can operate through a direct relayer. ERC-4337 is an Account Abstraction execution path over that same account, available once the exact chain, account, EntryPoint, bundler and paymaster combination is capability-approved.

Direct relayer and ERC-4337

ERC-4337 with Paymaster

sequenceDiagram
    autonumber
    participant W as Worker
    participant SG as Signer
    participant B as Bundler
    participant EP as EntryPoint
    participant AC as Account Core
    participant PM as Paymaster
    participant R as Reconciler

    W->>W: Build the UserOperation
    W->>SG: Sign the userOp hash
    SG-->>W: Signature
    W->>B: eth_sendUserOperation
    B->>EP: handleOps
    EP->>AC: validateUserOp
    EP->>PM: validatePaymasterUserOp
    EP->>AC: execute
    R->>EP: Read events / receipt
    R-->>W: Reconcile outcome and gas

What each step does

1. The worker builds the UserOperation. The intent becomes the structure ERC-4337 expects: target, calldata, gas limits, nonce and the paymaster data when gas is sponsored.
2. Worker → signer: sign the userOp hash. The digest travels with the key reference of the account's validator.
3. Signer → worker: signature. The signature is what the Account Core will validate; the private key stays inside the gateway.
4. Worker → bundler: eth_sendUserOperation. The bundler is a separate component from the RPC and the relayer, and one more dependency to keep available and validated.
5. Bundler → EntryPoint: handleOps. The bundler groups user operations into one transaction it pays for and submits.
6. EntryPoint → Account Core: validateUserOp. The account decides whether the signature, the nonce and the policy authorize this operation.
7. EntryPoint → Paymaster: validatePaymasterUserOp. The paymaster decides whether it sponsors the gas for this operation. That decision covers gas alone; moving the user's funds is authorized by the account.
8. EntryPoint → Account Core: execute. The validated call runs inside the account.
9. Reconciler → EntryPoint: events and receipt. The reconciler reads the outcome from the EntryPoint's events rather than from the bundler's answer.
10. Reconciler → worker. The outcome and the gas actually paid — by the account or by the paymaster — are contrasted against what was quoted and recorded.

Authority roles

Root, operational validator, recovery authority, EIP-7702 native authority, relayer and paymaster/treasury have different powers and use separate logical key references, even when the initial custody baseline derives them from one Partner master key.

Rotation and recovery

Account Core separates the operational validator, the root and the recovery authority. Rotating the validator keeps the address. Recovery can schedule a change of root with a delay. These authorities govern the delegated logic, while the native EIP-7702 private key keeps control of the protocol-level delegation and therefore needs protection of its own.

The delay is configurable per account: two days to begin with, one hour at the least and thirty days at the most. The account reads it when the recovery is scheduled and stores the resulting deadline, so shortening it afterwards does not pull a pending recovery forward. That is what makes the delay a protection rather than a setting: whoever reaches the root key cannot shorten the window that exists to stop them.

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

• Account Core and ERC-7201 storage — The contract a delegated account runs. Its variables are stored at slots calculated from a namespace, so a change of implementation can add state without overwriting what is already stored.

• Provisioning and stable address — The wallet address is calculated when the user is created, before anything is written on chain. From that moment it can be shown and can receive funds, and it stays the same after the account is deployed.

• One EVM address per user across every EVM network — The same user has the same address on every enabled EVM network, because the account is the wallet's own EOA: what each network holds separately is the delegation to the account implementation, not the address.

• Validator rotation — The key that authorizes operations can be replaced with a different one. The address, the funds and the account's history stay as they are, so a compromised operational key is replaced instead of migrating the wallet.

• Delayed root recovery — Recovering the highest authority is requested first and only takes effect once a waiting period is over. During that period whoever holds the current authority can cancel it.

• EIP-7702 revocation by API — A delegation can be withdrawn with an API call. The account goes back to being an ordinary account, keeping its address and its funds.

• Durable persistence of authority changes — Every rotation, recovery and revocation is stored with its date and its result. That is what makes it possible to answer, afterwards, which key could authorize an operation at the moment it happened.

• Cryptographic role separation per wallet — Validator, admin and recovery are three different keys, each with its own key reference. Whoever holds the operational key cannot change the account's configuration or recover it.

• EIP-7702 redelegation — An account that is already delegated can be pointed at a new implementation with a new authorization. A deployed account receives corrections without moving the funds to a different address.