Build smarter with Account Abstraction on Arbitrum

#blockchain #web3 #javascript

If you've built on Ethereum or an Ethereum rollup, you may be familiar with an Externally Owned Account (EOA), which is a basic wallet: a private key controls the account, allowing it to send transactions but not run arbitrary code. On the other hand, smart contract accounts can embed logic, verify signatures, perform batching, sponsor gas, and much more. Account abstraction aims to erase this distinction.

Over the years, several approaches have tried to deliver that vision. But fragmentation, complexity, and UX challenges remain. EIP-7702 lets an EOA set a delegation indicator that points to smart contract code. That setting persists until it is replaced or cleared by another authorization, so no migration or new account is needed.

What's more, Arbitrum has introduced support for EIP-7702 through the ArbOS 40 upgrade.

This opens up a powerful new layer for account abstraction directly onchain. In this post, we'll walk through how EIP-7702 works, how it compares to existing options, how Arbitrum supports it, and how you, as a developer, can start using it today.

What is EIP-7702?

At its core, EIP-7702 introduces a new transaction type (type 0x04) that lets an EOA set its account code to a delegation indicator pointing at smart-contract logic, via an authorizationList included in the transaction. The delegation remains in effect until changed or cleared.

The transaction fields payload includes the usual fields like nonce, chain, gas fees, calldata, etc., plus:

authorizationList – an array of [chainId, address, nonce, yParity, r, s] tuples authorizing which code address the EOA should delegate to. Applying an authorization writes a delegation indicator to the EOA’s code.
signature fields – the transaction’s own signature proving the EOA owner authorized the overall operation.

When the transaction executes, the EOA’s code is set to a delegation indicator that points to the designated contract. That setting persists across transactions. To remove it, you must submit another 7702 authorization that clears the code.

The EOA gains smart-account capabilities through the delegated logic, and those remain active until the delegation is changed or cleared.

How EIP-7702 Fits into Account Abstraction

Account abstraction has been an active area of design. To understand where EIP-7702 really lends a role here, it helps to understand other models:

ERC-4337 (UserOps / EntryPoint / Paymaster): This is currently the dominant pattern for smart contract wallets. It introduces a user operation layer, bundles, paymasters, and other components. It offers rich features, including gas sponsorship, custom validation logic, and batching. However, it also introduces additional infrastructure (bundlers, entry points) and can lead to fragmentation in wallet user experience. EIP-7702 complements ERC-4337 by bringing account-abstraction features directly into the protocol layer, while ERC-4337 continues to operate through UserOps, EntryPoints, and Paymasters.
EIP-3074 (AUTH / AUTHCALL Opcodes): EIP-3074 proposed two new opcodes to authorize and execute on behalf of EOAs. It faced resistance due to various security risks and EVM-level compatibility concerns. EIP-7702 achieves similar goals via a transaction type instead of new opcodes.

EIP-7702 isn’t free; it introduces a small gas overhead for handling authorization logic and signature verification. Wallets and applications must also validate which contracts an account can delegate to, since unsafe or malicious authorizations could be exploited. Each authorization entry includes both a chainId and a nonce, ensuring that signed delegations can’t be replayed across chains or reused multiple times.

Once a delegation is applied, it stays in place across future transactions until you explicitly clear or replace it. If a 7702 transaction fails, any delegation changes that already occurred are not reverted.

Despite these costs, EIP-7702 represents a pragmatic and incremental step toward true account abstraction. It gives EOAs temporary smart-account capabilities without migrations, new infrastructure, or breaking existing wallet compatibility.

Arbitrum and EIP-7702

Arbitrum's ArbOS 40 brings EIP-7702 into the Arbitrum environment.

That means EOAs on Arbitrum can now opt in to delegate execution logic in the same way as on the Ethereum mainnet, which activated EIP-7702 as part of the Pectra upgrade. This unlocks new flexibility for builders on Arbitrum. It is now possible to batch transactions in a single atomic call, such as ERC20 approve and a transfer, or multiple calls into a single 7702 transaction. Furthermore, because EOAs can adopt custom logic through persistent delegation, you can create sponsorship flows where a dApp covers gas without requiring the user to hold native tokens.

It is specifically on Arbitrum where you can truly experiment with the possibilities of EIP-7702. In the low gas environment of Arbitrum One with composability across contracts, the possibilities are almost endless for what you can build.

Thinking about some possibilities? The seamless interoperability between the EVM and the Stylus VM in Arbitrum unlocks opportunities using EIP-7702 that are only possible on Arbitrum.

For example, you could have an EOA delegate to a smart contract wallet that batches multiple onchain actions atomically. If you only want this behavior for a limited period, submit a follow-up 7702 authorization to clear or update the delegation.

EIP-7702 marks a meaningful evolution in account abstraction. By allowing EOAs to delegate their behavior to smart-contract logic that persists until cleared, it reduces friction without requiring protocol-level migrations or infrastructure changes. With Arbitrum adopting it through ArbOS 40, developers now have a fast, low-cost environment to experiment with smart wallet logic, sponsored transactions, and composable execution flows, all natively supported onchain.

If you’ve been waiting for a practical bridge between EOAs and smart accounts, this is the moment to explore what’s possible.

How to Start Using EIP-7702

You can already start experimenting with EIP-7702 on Arbitrum using existing tooling and SDKs. Most modern Ethereum libraries have added early support for the Type 0x04 transaction, making it easy to build and test delegated logic today.

Viem includes helper functions like signAuthorization() and sendTransaction() with built-in authorizationList support.
Foundry supports constructing and simulating EIP-7702 transactions for local testing.
QuickNode offers an implementation guide and RPC endpoints for EIP-7702 compatibility.

For example, you can accomplish the full EIP-7702 flow using Viem in just a few lines of code:

import { createWalletClient, http } from "viem";
import { arbitrum } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";

const eoa = privateKeyToAccount("0xYOUR_KEY");

const client = createWalletClient({
  account: eoa,
  chain: arbitrum,
  transport: http(),
});

const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress,
  executor: "self",
});

await client.sendTransaction({
  authorizationList: [authorization],
  to: eoa.address
});

That's the complete EIP-7702 cycle of signing, authorizing and executing all on Arbitrum.

You can start testing EIP-7702 transactions on Arbitrum One today. Its low gas costs make it ideal for iterating on delegated-logic wallets, just remember to always validate the contracts you delegate to.