Account abstraction

Account abstraction gives an EVM wallet a programmable execution layer. Aomi packages an approved batch into one operation and requests network-gas sponsorship before submitting it through an account-abstraction provider. The wallet owner remains the source of signing authority. Aomi checks the wallet’s current policy before every commit. Use this page to compare EIP-4337 with EIP-7702 and understand which address executes a transaction. The execution sequence also shows how a sponsored operation moves from simulation to confirmation. Both standards follow Aomi’s transaction pipeline: build, simulate, sign, and broadcast.

​

What account abstraction changes

A standard wallet signs and submits an ordinary transaction from its externally owned account. Account abstraction turns the same intent into a programmable operation that can contain several ordered calls. It can also separate the wallet that authorizes the operation from the account that executes it. Manual wallets remain on the standard path. Aomi currently uses its sponsored account-abstraction broadcaster with delegated signing, not with a manual wallet prompt. If an App requires sponsored account abstraction and that path is unavailable, Aomi stops instead of silently submitting an unsponsored transaction.

​

Roles in account abstraction

Account abstraction introduces three roles that may refer to different addresses or services. The owner controls the wallet and grants signing authority. The signer produces the operation signature under the wallet’s active policy. The executor is the onchain account whose balance and state the calls use. The owner and executor usually have different addresses with EIP-4337. The owner’s EOA is also the executor with EIP-7702, where it runs delegated smart-account code for the operation. This distinction affects where assets must be held and which address a protocol sees as the caller.

​

Execution lifecycle

Aomi prepares account-abstraction execution only after the complete batch has passed simulation. At commit time, it resolves the wallet’s account-abstraction mode and rechecks signing authority. It then asks the provider to prepare a sponsored operation. Submission remains blocked until Aomi verifies the expected owner signature. The signer in this sequence is a supported wallet provider acting under a live, revocable grant. It is not an Aomi-held private key. A manual or client-held key follows the standard wallet route, where the wallet or client signs and submits the transaction itself.

​

EIP-4337 smart accounts

EIP-4337 uses a dedicated smart account whose owner is your linked wallet. The smart account is the executor, so it holds the assets and allowances used by the batch. Your owner wallet authorizes the prepared UserOperation. A bundler then submits it for execution. Several calls can be encoded in one UserOperation. This is useful for flows such as approval followed by swap, because the order that passed simulation is preserved through signing and execution. Aomi verifies that the signature matches the configured owner before the operation can be submitted.

​

EIP-7702 delegated accounts

EIP-7702 lets an existing EOA use smart-account behavior without moving assets to a separate account. The same address remains the owner and executor. Delegated code provides batching and account-abstraction execution, so protocols continue to see the user’s existing address as the caller. The first operation on a compatible account may require an additional authorization that establishes the delegation. Later operations can use the delegated account behavior while the authorization remains valid. Aomi still prepares, simulates, and verifies the complete operation before broadcast.

​

Gas sponsorship

For its account-abstraction broadcast path, Aomi requests sponsorship while the provider prepares the operation. Sponsorship covers the network gas required to execute the operation. It does not pay the value being transferred, a protocol’s trading fee, an App’s tool fee, or an outcome fee. Sponsorship is part of the prepared operation rather than a rebate applied after broadcast. If the provider cannot produce a valid sponsored operation, Aomi returns an error before signing or submission. This keeps the displayed terms aligned with the operation that reaches the chain.

​

Signing authority

Account abstraction changes transaction packaging, not wallet ownership. Aomi evaluates the selected wallet’s signing policy at commit time and requires the matching signing capability. A delegated grant must cover that exact wallet, and a returned signature must recover to the expected owner. Revoking a delegated grant removes the signing capability for the next operation. Changing the wallet policy to Manual or Locked also blocks delegated execution. See the permission model for the checks that apply before any signing request is released.

​

Batches and outcome fees

Account abstraction preserves the exact order of the simulated batch. An approval, swap, bridge, and supported outcome-fee transfer can be included in one prepared operation, provided every call succeeds during simulation. Aomi does not add, remove, or reorder calls after the operation has been signed. An outcome fee settles with the onchain action and is different from an x402 tool fee. Aomi adds the supported fee call before account-abstraction preparation, which allows the complete economic result to be simulated and authorized together. Read Fees for the full distinction.

​

Confirmation and failures

After submission, Aomi tracks the operation until the provider reports a terminal result. A confirmed operation includes its onchain receipt and transaction hash. A rejected signature, failed sponsorship request, reverted operation, or expired authorization produces a failure without retrying through a weaker execution path. The portal, widget, and custom clients receive the same final status from Aomi. These surfaces display the result without reconstructing or modifying the sponsored operation. Preparation and authorization therefore stay attached to the same record through confirmation.

​

Current support

Use account abstraction only for EVM networks, wallet providers, and Apps that Aomi currently marks as compatible. The sponsored path requires a configured AA account, a supported signing provider, a live delegated grant, and available sponsorship. A missing requirement stops the operation before broadcast. Apps that do not require account abstraction can continue to use standard wallet execution. That path remains appropriate when you want to review every transaction in a self-custody wallet or submit from your own key-holding client. The EVM page lists the networks available to the current client.

​

Related concepts