Support Account Abstraction in Foundry

[excaliborr]

Component

Forge

Describe the feature you would like

Adding account abstraction to foundry would allow users to leverage paymasters to submit transactions in their foundry scripts, this also allows developers to make gasless transactions to testnets without needing to find a faucet as paymaster providers can sponsor the testnet gas, and many do already!

Additional context

Hardhat Implementation

We have already built a plugin to add account abstraction scripting to hardhat and want to work on getting it implemented into foundry next, if you want to check out the hardhat plugin to see how it works check it out here.

Who we are?

We are Wonderland, the largest core development group in web3. Our commitment is to a financial future that's open, decentralized, and accessible to all.

Design

The design of how the scripts would work is open-ended and no way a final design, the goal is to discuss the best way to implement this feature.

Example code snippet:

// Single broadcast
vm.sponsoredBroadcast(signer);
testToken.mint(100);

// Start and stop broadcast
vm.startSponsoredBroadcast(signer);
ERC20 testToken = new TestToken();
testToken.mint(100);
vm.stopSponsoredBroadcast();

Important Caveats

• Deployments need to go through a contract factory, in our hardhat plugin we are utilizing CreateXFactory to do this.
• Transactions being mined does not mean the UserOperation was successful
• Paymasters don't have a standardized API call and each have unique implementations
• Payable functions require the smart account to have the funds, not the signer

Open ended questions for discussion:

• Should this be a separate plugin? Or native to foundry?
• How does the foundry community feel about this feature? Any suggestions?

[gakonst]

#1232 related -- thinking about how to make this work for both

[zerosnacks]

Given https://eips.ethereum.org/EIPS/eip-7702 is included in the Prague/Electra network upgrade I think it makes sense to considering having support for account abstraction.

@excaliborr would this specifically be related to supporting ERC-4337, given that one of the design goals of EIP-7702 is not conflicting with it?

I feel a lot of account abstraction proposals are still up in the air.

Feel free to leave thoughts / requirements related to how extensions in Foundry could look on #8266

[evchip]

I'll try to reignite this discussion, as EIP-7702 seems to be gaining traction (h/t Ithica), and take a crack at a proposal.

I've been experimenting with EIP-7702 using the OpenFort CLI and want to contribute to adding support in Forge. Before making a full proposal, I'd like to clarify a few things:

1. @zerosnacks Do you think the immediate goal should be to support basic EIP-7702 delegation (EOAs delegating to contract code), or is ERC-4337 integration a requirement?

2. What do we need to add to allow Forge scripts to work with EIP-7702 transactions? Thinking about:

   • How to construct type 0x04 transactions
   • How to handle authorizations
   • What new cheatcodes or APIs might be needed?
   • Helper functions for creating/signing delegations?
   • Special handling for broadcasting to delegated EOAs?
   • Integration with bundlers/paymasters?

3. Are there any specific use cases or workflows you want to prioritize?

This would help me focus the proposal on the most important aspects. I like the suggestion from @excaliborr on supporting gas sponsorship, however I think there is a lot of groundwork to do before introducing that.

I'm interested in adding support for transaction batching in Forge. There seem to be two potential approaches:

1. Full ERC-4337 integration where batched transactions are sent as UserOperations through a bundler to an EntryPoint contract
2. Direct EIP-7702 support where transactions are batched through delegate contracts that implement their own batching functionality (see BaseOpenfortAccount contract)

Would it be helpful to focus on one of these approaches first? The pure EIP-7702 route might be simpler to start with, though the 4337 integration could offer more features later.

[zerosnacks]

Hey @evchip, thanks for your comment

1. I think the immediate goal of supporting EIP-7702 is sufficient and would already unlock many new use-cases.

2. This is a good question, to my knowledge we currently don't support tagging transactions with non-standard transaction types. The good news is that Alloy does fully support it already so we would need to create some way for users to express this, be it through a decorating cheatcode or a section cheatcode.

In regards to transaction batching I think it is best discussed in #7452.

cc @mds1 / @klkvr / @gakonst

[evchip]

@zerosnacks Thank you for clarifying the scope - focusing on EIP-7702 support first makes sense as a foundation. I've put together a proposal for implementing this in Foundry that aims to be both focused and extensible.

The core goal would be enabling delegation and transaction batching through Forge scripts, with a clean interface like:

function run() external {
    // Set up delegation
    address implementation = address(0x123);
    uint256 nonce = vm.getNonce();
    bytes memory delegation = vm.createDelegation(implementation, nonce);
    vm.signDelegation(delegation);

    // Execute batched transactions via delegation
    vm.startDelegatedBroadcast(implementation);
    // Transactions here will be batched and executed via the implementation
    token.transfer(alice, amount);
    token.transfer(bob, amount);
    vm.stopDelegatedBroadcast();
}

EIP-7702 Support for Foundry

Overview

This proposal outlines adding basic EIP-7702 support to Forge scripts, enabling EOAs to delegate their execution to contract implementations. This foundation will enable transaction batching and future account abstraction features.

I propose implementing the core EIP-7702 functionality in three phases:

Phase 1: Core EIP-7702 Transaction Support

• Add type 0x04 transaction support using Alloy's implementation
• Extend TransactionWithMetadata to track delegation info
• Add serialization/deserialization for EIP-7702 transactions
• Add tests for transaction encoding/decoding

Phase 2: Cheatcode Implementation

1. Add four essential cheatcodes for delegation management:

// Create an EIP-7702 authorization for delegation
function createDelegation(address implementation, uint256 nonce) 
    external returns (bytes memory);

// Sign the authorization as the authority (EOA)
function signDelegation(bytes memory authorization) 
    external returns (SignedAuthorization);

// Start collecting transactions for delegated execution
function startDelegatedBroadcast(address implementation) external;

// Stop collecting delegated transactions
function stopDelegatedBroadcast() external;

2. Implement broadcast handling in same PR:

// In broadcast.rs 
impl ScriptRunner { 
	fn handle_delegated_broadcast(&mut self, implementation: Address, txs: Vec) -> Result { 
		// Bundle transactions into single EIP-7702 tx 
		let delegated_tx = self.create_delegated_tx(implementation, self.current_auth, txs)?; 
		// Add to broadcast queue 
		self.transactions.push(delegated_tx); 
	        Ok(()) 
	} 
} 

3. Testing
   a. Unit tests for each new cheatcode
   b. Integration tests with local EIP-7702 deployments
   c. End-to-end script execution tests
   d. Gas efficiency tests for batched transactions

Phase 3: Documentation & Examples

• Add documentation for new cheatcodes
• Create example scripts showing delegation patterns
• Add integration tests with popular delegation contracts

Future Enhancements

While out of scope for this initial implementation, the following features could be added later:

1. ERC-4337 integration for userOp support
2. Paymaster integration for gas sponsorship
3. Advanced batching optimizations
4. Integration with existing account abstraction solutions

[klkvr]

@evchip given that we don't yet have a common standard/implementation of batcher for 7702 I think it would make sense for now to start with simple support for attaching 7702 authorizations to transactions broadcasted in scripts.

that way we could add createDelegation, signDelegation from your proposal and attachDelegation which would attach signred auth to next broadcasted transaction

[evchip]

@klkvr thanks for the feedback

agreed that starting with basic authorization support makes sense. I'll start working towards that and open a draft PR once I have something of substance.