Over the weekend I explored EIP-7702 by writing a minimal implementation that stripped transaction creation back to its fundamentals. While Viem does a great job abstracting the low-level details, I wanted to understand exactly what was happening under the hood. You can check out the code here.

​

What did I learn?

• Once delegated, the code is fixed at the EOA unless it's explicitly re-delegated (requires re-signing auth list entry).
• Type 4 transactions include an authorizationList, allowing multiple EOAs to delegate in a single transaction.
• In practice, the Type 4 transaction 'to' field can point to something like a Multicall3 contract, and the 'data' can include 'n' calls (where 'n' is the number of entries in the authorizationList) to initialize each delegation. This allows a gas sponsor to batch-initialize multiple EOAs' new contracts in a single transaction.
• Each authorizationList entry includes a chainId and nonce.These are important replay protections that prevent the gas sponsor from reusing an authorization.
• If all entries in the authorizationList are invalid, this is still a valid state transition and the transaction itself doesn't fail. Even though Etherscan will show them as invalid.

• Etherscan has been quick to incorporate EIP-7702 UX:

TODOs

I'm building an integration test suite that demonstrates the full behavior and capabilities of EIP-7702. Reading the EIP is useful, but it's not the same as seeing the behavior in code, so I plan to open-source it.

I also want to use what I’ve learned to build something useful for devs. A few early ideas:

• Hosted gas sponsor for Sepolia. Developers could route transactions through my service to get them included without needing Sepolia ETH. This would solve the “how do I get testnet ETH?” problem.
• EIP-7702 builder UI. A simple interface for constructing and testing 7702 transactions. Could also work as an educational tool.