Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

EIP-7702

Stable supports EIP-7702, which allows an EOA to set its account code to an existing smart contract. EOAs keep their original address and private key while executing the delegate's logic.

Transaction format

EIP-7702 uses transaction type 0x04 with an authorizationList field. Each authorization designates a delegate contract whose code the EOA executes for that transaction.

{
  type: 4,
  to: eoa.address,
  data: delegateCallData,
  authorizationList: [signedAuthorization],
  maxPriorityFeePerGas: 0n, // always 0 on Stable
  // ... standard EIP-1559 fields
}

The authorization carries:

  • chainId: must match the target chain.
  • address: the delegate contract address.
  • nonce: the authorizing account's nonce. If that account also sends the transaction, use its current nonce plus one, because the transaction increments the nonce before authorizations are processed.

Wallets and libraries that support EIP-7702 handle the authorization format automatically.

Tooling

  • ethers.js (v6.14+): wallet.authorize({ chainId, address, nonce }) produces the signed authorization for inclusion in the authorizationList.
  • viem: use signAuthorization with a walletClient, then pass the result to sendTransaction. Pass executor: "self" when the same account sends the transaction, and viem sets the nonce for you.
  • Alchemy Wallet APIs: delegate to an audited smart account and manage session keys without building the authorization yourself. See Session keys with EIP-7702.
  • Hardhat / Foundry: standard EIP-7702 transaction format works when your toolchain version supports the Pectra hardfork.

Next recommended