Last week, I explored how EIP-7702 enables sponsored transactions, a long-awaited Ethereum feature. This week, I’m continuing that exploration, now from the Foundry side. Foundry recently introduced new cheatcodes that make it much easier to experiment with EIP-7702:

• ​signDelegation - Sign an EIP-7702 authorization for delegation
• attachDelegation - Designate the next call as an EIP-7702 transaction.
• signAndAttachDelegation - Sign an EIP-7702 authorization and designate the next call as an EIP-7702 transaction.

I was able to get their demo working, but when I tried to write my own using an Anvil backend, I ran into an issue (see: Github).

​

Playing around with EIP-7702 has taught me a few things:

1. When using a delegated contract, any function calls will have 'address(this)' set to the EOA’s address. If you don’t implement proper access controls on these functions, anyone could potentially act as the EOA. For example, if there are tokens held in an ERC20 contract at the EOA’s address, and your contract exposes a function that allows arbitrary token transfers, those funds could be easily drained by anyone calling that function.
2. When delegating an EOA to a contract, it's essential to carefully design the contract’s initialization. Delegation targets should rely on initializer functions (not constructors), and these must be protected with strict access controls to prevent unauthorized re-initialization. Improperly secured initializers can allow attackers to hijack the contract or alter critical settings. Ensure the initializer is callable only once and only by the intended party.
3. If you ever want to redelegate to new code at your EOA’s address, it’s much easier if all previous delegations used unstructured, non-conflicting storage layouts. This approach prevents storage collisions and ensures your new contract logic can safely interact with existing data.

​

Once I sort out the Foundry issue, I’ll drop some code on GitHub for you to poke around.