Go back Blog Home

The Smartest Wallet You Already Own Is on Arbitrum

Ben Greenberg

Ben Greenberg

— 5 min read
Share this article:
The Smartest Wallet You Already Own Is on Arbitrum

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 is a proposal whose promise is elegant: let an EOA temporarily adopt smart contract code for a single transaction by temporarily setting contract logic for the transaction with no migration, no new account, and just optional delegation.

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 allows an EOA to temporarily delegate its execution to smart contract logic through an authorization list included in the transaction.

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

  • authorizationList – an array of authorization tuples, each specifying a chainId, address, nonce, and the signer’s signature components, which together indicate the smart contract logic the EOA temporarily delegates to.
  • signature fields – the transaction’s own signature proving the EOA owner authorized the overall operation.

When the transaction executes, the EOA's code is temporarily set to the contract logic from the delegated address, and all calls to the EOA execute that code just like a smart contract. After the transaction completes, the EOA's code returns to its original "no-code" state, making no permanent changes.

The EOA "borrows" smart account capabilities, but only for that one operation.

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.

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 temporarily, 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 temporarily delegate to a smart contract wallet that batches multiple onchain actions atomically, such as approving a token and staking it into a yield protocol, all within one EIP-7702 transaction.

EIP-7702 marks a meaningful evolution in account abstraction. By allowing EOAs to momentarily “borrow” smart contract behavior, 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.

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.

Learn More

If you want to go deeper into building with EIP-7702 and experimenting with account abstraction on Arbitrum, here are a few good places to start:

Read more