EIP-7702 on Monad

Summary

EIP-7702 is supported on Monad with the same workflow as in Ethereum: users sign a message authorizing the delegation to a specific account, which they or someone else can submit using transaction type 0x04.

When accounts are delegated under EIP-7702, their treatment under Monad's Reserve Balance rules changes slightly. Specifically, there is an exception to the reserve balance policy for the first inflight "emptying" transaction which does not apply to EIP-7702-delegated accounts.

Other than that, EIP-7702-delegated accounts behave normally with respect to both ordinary transactions sent by the EOA, and transactions that treat the EOA as a smart contract.

The rest of this page serves as a primer on EIP-7702 that is not Monad-specific.

Introduction

EIP-7702 allows Externally Owned Accounts (EOAs) to add code to themselves, granting themselves the ability to add new capabilities previously reserved for smart contract accounts, such as transaction batching, gas sponsorship, and alternative authentication.

To do this, the EOA signs an authorization designating a specific address as the source of its code. EIP-7702 introduces a new transaction type (type 0x04). that submits this authorization. The authorization can be submitted by the EOA themselves, or by anyone else.

Background

EIP-7702 was created largely in response to the limitations of EIP-4337, Ethereum's first major step toward account abstraction.

While EIP-4337 introduced smart contract wallets with flexible validation logic, it relied on an alternative "user operation" mempool and a separate bundler infrastructure, making it more complex for wallets, dapps, and infrastructure providers to adopt. This separation meant that EOAs, still the majority of accounts, could not directly benefit from account abstraction features without migrating entirely to new smart accounts, creating friction and fragmentation in the ecosystem.

EIP-7702 addresses these shortcomings by enabling EOAs to function as smart accounts within the existing transaction model, without requiring a parallel mempool or forcing users to switch addresses.

In essence, EIP-7702 makes it possible for today's EOAs to gain smart wallet-like powers such as multisig, session keys, and gas sponsorship without abandoning their current accounts, bridging the gap between the old EOA model and the future of full account abstraction.

Sending an EIP-7702 transaction using viem

import { createWalletClient, http, parseEther } from 'viem'
import { monadTestnet } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

const account = privateKeyToAccount('0x...')

const walletClient = createWalletClient({
  account,
  chain: monadTestnet,
  transport: http(),
})

const authorization = await walletClient.signAuthorization({
  account,
  contractAddress: '0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2'
})

const hash = await walletClient.sendTransaction({
  authorizationList: [authorization],
  data: '0xdeadbeef',
  to: walletClient.account.address,
})

FAQ

What does an EIP-7702 (set code transaction) look like?

An EIP-7702 transaction is an EIP-2718 transaction with TransactionType 0x04.

This transaction type is only used to set code; once the code is set for an EOA, subsequent transactions will most likely use the default transaction type (TransactionType 0x02; EIP-1559) transactions to interact with the EOA.

Here is an example of an EIP-7702 transaction in a block explorer:

Is it necessary for the EIP-7702 type transaction to be initiated by the EOA itself?

No, the EOA can sign an "authorization tuple" which can then be used by the sponsoring entity to send the transaction. This will allow EOAs to behave like smart contracts without any funds for gas!

How can I find out to which address EOA is currently delegating to?

On successful delegation to a smart contract, the following code is deployed at the EOA's address.

0xef0100 (3 bytes) + smart_contract_address (20 bytes)

Example: If 0xabc... (EOA) delegates to 0x493... (smart contract), then code at 0xabc... (EOA) is 0xef0100493...

Thus, you may determine the delegated address by inspecting the code.

What if the EOA is pointing to another EOA which is also pointing to a smart contract?

The chain of delegation is not followed; only the immediate code that the first EOA is pointing to is used.

How do I clear the delegation on an EOA?

Initiate a 0x04 type transaction from the EOA with 0x000... (dead address) as the new delegated account.

Does the delegation expire?

No, the delegation remains valid in perpetuity unless another 0x04 transaction is sent changing the delegation to a different (or null) account.

Is EIP-7702 compatible with ERC-4337?

Yes; after delegating with EIP-7702, any EOA may behave like an EIP-4337 smart account. Simply initiate a transaction of type 0x04 while pointing to an address containing code for the 4337-compatible smart account.

What happens if the EOA is pointing to a precompile address for code?

When CALL, STATICCALL, DELEGATECALL and CALLCODE opcodes are called with enough gas, the opcodes proceed with execution as if the EOA has no code.