Introducing Simple7702Account and Universal7702Account: EIP-7702 Smart Account Implementations

The Ethereum ecosystem is evolving rapidly, and EIP-7702 represents one of the most significant upgrades to account abstraction. In this post, we’ll explore two production-ready implementations: Simple7702Account and Universal7702Account, designed to bring smart contract functionality to Externally Owned Accounts (EOAs).

Why This Project?

In typical scenarios—such as facilitating simple transfers for custodial wallet users—the existing ERC-4337 paymaster solutions present significant challenges:

• Overly Complex: ERC-4337 requires a full bundler infrastructure, entry point contracts, and complex paymaster logic
• Third-Party Dependencies: Many solutions rely on external services like Pimlico, Alchemy, or other infrastructure providers
• High Integration Cost: Setting up and maintaining the entire 4337 stack is resource-intensive

For many use cases, you don’t need the full power of ERC-4337. What you need is a simple, direct way to sponsor transactions for your users.

This is where Simple7702Account and Universal7702Account come in. They provide:

• Minimal Infrastructure: No bundlers, no entry point contracts—just a simple relayer
• Direct Sponsorship: Sign an action, have it relayed by anyone (or specific whitelisted parties)
• Easy Integration: A few function calls and you’re ready to sponsor transactions

If you’re building a custodial wallet service, a game with sponsored transactions, or any application where you want to pay gas for your users without the complexity of ERC-4337, these implementations are designed for you.

What is EIP-7702?

EIP-7702 introduces a groundbreaking mechanism that allows EOAs to temporarily act as smart contracts during a transaction. When an EOA sets its code to a designated smart account implementation, it gains all the benefits of a smart contract wallet—without the need for a permanent migration.

This enables:

• Sponsored transactions (gasless user experiences)
• Batch operations (multiple actions in a single transaction)
• Advanced authorization logic (custom signing schemes)
• Seamless EOA upgrades (no need to deploy new contracts)

Simple7702Account: Controlled & Secure

The Simple7702Account is designed for scenarios where you need fine-grained control over who can execute actions on behalf of users. It pairs with a Simple7702PolicyRegistry contract that manages whitelists for both sponsors and targets.

Key Features

1. Policy-Based Access Control

1
2

// The registry controls who can relay transactions
ISimple7702PolicyRegistry public immutable registry;

The contract validates actions against the registry:

• Sponsor Whitelist: Only approved addresses can relay transactions
• Target Whitelist: Only approved contracts can be called

2. EIP-712 Typed Signatures

Actions are signed using EIP-712, providing human-readable signing data:

1
2
3

bytes32 constant ACTION_TYPEHASH = keccak256(
    "Action(address target,uint256 value,bytes32 dataHash,uint256 nonce,uint256 deadline,address executor)"
);

3. Bitmap-Based Nonce Management

The implementation uses a bitmap for nonces, allowing parallel execution of independent actions:

1
2
3
4
5
6
7

mapping(uint256 => uint256) private nonceBitmap;

function isNonceUsed(uint256 nonce) public view returns (bool) {
    uint256 word = nonceBitmap[nonce >> 8];
    uint256 mask = uint256(1) << (nonce & 0xff);
    return (word & mask) != 0;
}

4. Batch Execution

Execute multiple actions atomically:

1
2

function executeBatch(Action[] calldata actions, bytes[] calldata signatures) 
    external payable nonReentrant

Use Cases for Simple7702Account

• Enterprise Applications: Where compliance requires controlled relayers
• DeFi Protocols: Limiting interactions to approved contracts
• Gaming Platforms: Managed sponsorship with restricted targets

Universal7702Account: Permissionless & Open

The Universal7702Account takes a different approach—anyone can relay signed actions. This makes it ideal for open, permissionless environments.

Key Features

1. No Registry Required

1
2

// No policy registry - anyone can execute
mapping(address => uint256) public nonces;

The contract is simpler, with no external dependencies for access control.

2. Sequential Nonce Per EOA

Each EOA has its own sequential nonce, making it easier to track and predict:

1
2
3

function getNonce(address eoa) external view returns (uint256) {
    return nonces[eoa];
}

3. Gas Optimized

The contract uses inline assembly for critical operations, saving gas on every transaction:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

function _actionDigestASM(Action calldata action) internal view returns (bytes32 digest) {
    assembly {
        // Optimized EIP-712 digest computation
        let ptr := mload(0x40)
        let dataPtr := add(ptr, 0xe0)
        calldatacopy(dataPtr, actionData.offset, actionData.length)
        let dataHash := keccak256(dataPtr, actionData.length)
        // ... rest of the implementation
    }
}

Use Cases for Universal7702Account

• Public Relayers: Anyone can build a relayer service
• Cross-Chain Operations: Simplified signature verification
• Open Ecosystems: Maximum flexibility for users

Comparison Table

How to Use

Signing an Action

Both contracts use the same Action struct:

1
2
3
4
5
6
7
8

struct Action {
    address target;    // Contract to call
    uint256 value;     // ETH to send
    bytes data;        // Calldata
    uint256 nonce;     // Unique nonce
    uint256 deadline;  // Expiration timestamp
    address executor;  // Who can relay this
}

To sign an action:

1. Compute the data hash: keccak256(action.data)
2. Build the EIP-712 struct: Include all action fields
3. Sign with the EOA’s private key: The signature authorizes the action

Executing an Action

1
2
3
4
5

// Single action
account.execute(action, signature);

// Batch actions
account.executeBatch(actions, signatures);

Security Considerations

Both implementations include:

• Reentrancy Protection: A lock prevents nested calls
• Deadline Enforcement: Actions expire after a timestamp
• Executor Binding: Only the designated executor can relay
• Low-S Signature Validation: Prevents signature malleability
• EIP-712 Domain Separation: Prevents cross-chain replay

1
2
3
4
5

// Low-S validation prevents malleability
bytes32 private constant LOW_S_MAX = 
    0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0;

if (uint256(s) > uint256(LOW_S_MAX)) revert InvalidSignature();

Getting Started

The contracts are built with Foundry and can be deployed using the provided scripts:

1
2
3
4
5

# Deploy Simple7702Account with registry
forge script script/Deploy.s.sol --broadcast

# Deploy Universal7702Account
forge script script/DeployUniversal.s.sol --broadcast

Conclusion

EIP-7702 opens exciting possibilities for Ethereum users. Whether you need the controlled environment of Simple7702Account or the open flexibility of Universal7702Account, these implementations provide production-ready foundations for building the next generation of smart accounts.

The choice between them depends on your specific requirements:

• Choose Simple7702Account when you need compliance, control, and restricted access
• Choose Universal7702Account when you want maximum openness and simplicity

Both contracts are gas optimized, thoroughly tested, and ready for deployment on EIP-7702-compatible networks.

Resources

• EIP-7702 Specification
• Source Code
• Test Suite

Happy building! 🚀