After introducing the technical dive on EIP7702 and the V1 smart account, we're now ready to introduce the new account. The Openfort delegator account effectively enables EOAs to function like smart contract accounts, unlocking features such as batch calls, transaction sponsorship by third parties (like sequencers or wallet servers), the use of arbitrary signing keys (e.g., WebAuthn, P256), and the implementation of session or scoped keys with specific lifespans and permissions.
Core Features of Openfort's EIP-7702 Account
Openfort's implementation highlight several key advancements and features, primarily centered around modularity, advanced session key management, and compatibility with existing account abstraction standards.
Delegation Contracts
Check the Openfort delegator contract
Openfort’s EIP-7702 solution features a modular delegator contract. This design allows developers to attach various features to an EOA, upgrading it to a smart account. The base delegator account includes functionalities such as access control, initialization, signature verification, and options for both single and batch transaction executions. Developers can add modules for features like session keys and integration with the ERC-4337 account abstraction infrastructure, supporting guardians and account recoverability.
The purpose of this delegation contract was to enable the EOA to authorize WebAuthn public keys for call delegation, allowing a third party (like a sequencer) to execute calls on behalf of the account using a WebAuthn signature.
- Secure Initialization: The account initialization function is executable only once, verifies the initiator, and clears specific storage slots to prevent collisions if the EOA had prior state.
- Unique Storage Allocation: The contract uses a unique storage layout to prevent overwriting pre-existing storage on the EOA.
Session Key Management with WebAuthn
Openfort supports EOA-based session keys and WebAuthn-based session keys. WebAuthn keys allow users to authenticate or sign messages using biometrics, passkeys, or hardware keys, utilizing the P256 elliptic curve. The user's public key (derived from the WebAuthn credential) is registered as a session key, and transactions can then be executed using this passkey without needing the primary private key for each action.
Openfort categorizes session keys into:
- Master Keys: WebAuthn or EOA-based, with broad permissions, acting like a primary or secondary owner.
- Limited Session Keys: WebAuthn or EOA-based, operating under strict, predefined policies including active status, validity period, whitelisted contracts, allowed function selectors, and spending limits for ETH and tokens.
An interesting flow you can unlock is the ability to create an WOA controlled by a WebAuthn key (e.g., Passkey), with signatures verified using the RIP-7212 P256 Precompile. The process involved generating an EOA, prompting the user for a WebAuthn key, signing an EIP-7702 authorization to designate the Delegation contract, and then sending an EIP-7702 transaction to authorize the WebAuthn public key on the account. Notably, in this flow, the EOA's original private key was disposed of after the initial authorization.
Some of the security considerations are:
- Access Control: Only the owner, a registered session key, or the ERC-4337 entry point can execute transactions.
- Session Key Security: For WebAuthn session keys, a
useChallengesmapping acts as a nonce to prevent replay attacks. The system validates policies for limited session keys. - Re-entrancy Guard: Protects against re-entrancy attacks.
Transaction Batching with EIP-7702 Accounts
One of the most compelling advantages EIP-7702 brings to Externally Owned Accounts (EOAs) is the ability to perform transaction batching. By delegating its functionality to a smart contract, an EOA can execute multiple operations atomically within a single transaction. This not only streamlines user experience by, for example, combining an approve action with a subsequent transferFrom or contract interaction, but also enhances efficiency and can offer a more predictable execution environment.
How Transaction Batching Works
At its core, transaction batching allows a user to bundle several distinct actions-each typically defined by a target address, a value (ETH to send), and data (the function call)-into one overarching transaction. When this EIP-7702 transaction is processed, the authorized delegate contract executes these bundled calls sequentially. If any one of the batched operations fails, the entire set of operations can be reverted (depending on the batch execution logic), ensuring atomicity.
Implementing Batching: The Role of the Delegate
The design of the EIP-7702 delegate contract is crucial for enabling batching.
- Direct Implementation: The most secure and straightforward approach is for the batching logic to be implemented directly within the delegate contract itself. This gives the EOA, through its delegate, full control over how multiple calls are processed, ensuring that
msg.senderremains consistent as the EOA's address for each internal call. This approach avoids the complexities and potential security risks associated with using external helper contracts viaDELEGATECALLfor batching, such as those historically seen with genericMultiSendcontracts, which could inadvertently grant unintended permissions if not carefully managed. - Standardized Interfaces: To promote interoperability and ease of integration for dapps, delegate contracts can implement standardized batching interfaces.
- ERC-7821 (Simple Batch Calls): This standard offers a straightforward way to define batch calls, focusing on an array of destinations, values, and calldata. Its design intentionally omits support for
DELEGATECALLwithin batched operations, which simplifies validation and enhances security, making it a robust option for common batching needs. An EIP-7702 delegate can easily expose an ERC-7821 compliant execution function.
- ERC-7821 (Simple Batch Calls): This standard offers a straightforward way to define batch calls, focusing on an array of destinations, values, and calldata. Its design intentionally omits support for
Batching in the ERC-4337 Ecosystem
For EIP-7702 accounts designed to be compatible with ERC-4337 (Account Abstraction), batching is a native concept.
- UserOperations with Multiple Calls: Within the ERC-4337 framework, a
UserOperation(the user's transaction intent) can containcallDatathat instructs the smart account (which the EOA effectively becomes via EIP-7702 delegation) to execute multiple actions. The delegate contract, acting as the smart account logic, would parse thiscallDataand perform the batched executions. This allows EIP-7702 empowered EOAs to leverage the full suite of ERC-4337 features, including its batching capabilities, seamlessly.
Transaction Sponsoring for EIP-7702 Accounts
Transaction sponsoring, or gas abstraction, is another transformative feature that EIP-7702 helps bring to EOAs. By allowing a third party to cover the gas costs of a transaction, it significantly lowers the barrier to entry for new users (who may not hold native tokens) and vastly improves the user experience by making transactions feel "gasless."
Evolution of Sponsorship
- Early Approaches (Meta-Transactions): The concept of transaction sponsorship isn't new. Before widespread account abstraction, "meta-transactions" were a common pattern. Users would sign a message off-chain, and a third-party relayer would submit this message as part of an on-chain transaction, paying the gas. Standards like ERC-2771 emerged to define trusted forwarder contracts, allowing destination contracts to correctly identify the original signer rather than the relayer. An EIP-7702 delegate could be designed to interact with such systems, allowing the EOA to benefit from established meta-transaction infrastructure.
ERC-4337: The Standard for Decentralized Sponsorship
The most robust and standardized way to achieve transaction sponsorship for EIP-7702 accounts today is through compatibility with ERC-4337. Once an EOA delegates its operations via EIP-7702 to become a smart account, it can tap into the ERC-4337 ecosystem:
- Paymasters: The cornerstone of ERC-4337 sponsorship is the Paymaster contract. This is a specialized smart contract that agrees to pay for a user's
UserOperationgas fees, provided certain conditions are met. These conditions can be highly flexible: a dapp might sponsor all transactions for its users, users might pay with ERC-20 tokens, or sponsorship could be offered for specific actions. - Decentralized Flow: The EIP-7702 account (acting as a smart account) crafts a
UserOperation. If a Paymaster is willing to cover the fees, it signs theUserOperation. A Bundler then picks up this UserOperation from an alternative mempool and includes it in a transaction on-chain, with the EntryPoint contract orchestrating the execution and gas payment via the Paymaster. This system offers a decentralized and censorship-resistant pathway for gas sponsorship.
Horizon: The Rise of Intents
Looking ahead, the concept of "Intents" is gaining traction. Intents represent a higher-level abstraction of user desires (e.g., "I want to swap X token for Y token at the best possible rate") rather than specific, low-level transactions.
- ERC-7683 (Cross-Chain Intents): This ERC, for example, explores how intents can be structured, particularly for cross-chain scenarios. Fulfilling an intent often involves multiple steps and potentially complex routing, where sponsorship can be seamlessly integrated by "solvers" who execute the intent on behalf of the user. While still an evolving area, EIP-7702 equipped accounts are well-positioned to leverage intent-based systems as they mature, further simplifying user interactions and abstracting complexities like gas payments.
By leveraging EIP-7702, EOAs can access these sophisticated batching and sponsorship mechanisms, fundamentally upgrading their capabilities and paving the way for a more intuitive and accessible Web3 experience.