EIP-7702 for Hardware Wallet vendors
2025 May 07
See all posts
EIP-7702 for Hardware Wallet vendors
(Pectra dealing with Twixtter FUD)
Introduction
As a minimalistic perspective on my upcoming EthCC[8] presentation, this blog entry describes how Hardware Wallet vendors could quickly benefit from turning their Externally Owned Accounts into smarter account with EIP-7702 available with Pectra today, with as little impact on their infrastructure as possible.
High level overview of EIP-7702
EIP-7702 introduces a new transaction type (v4), adding the concept of authorization lists - each element of the list provides the following crytographically authenticated elements :
- an EOA address
- the address of a delegate, to which the code of the EOA will be set
- validity conditions for the authorization (chain ID and EOA nonce)
After the authorization list is processed, the EOA code execution flow is similar to the delegate's, with its own storage, and it can still originate transactions.
ERC-4337, the reference implementation for standardized and censorship resistant smart accounts architecture has also been updated to support EIP-7702
Choice of the delegate is critical as a malicious or buggy delegate could drain the account - wallets are expected to filter those carefully.
Since the EOA can still originate transactions, some use cases do not make sense if its private key is known - typically you wouldn't delegate to a threshold multi signature contract such as Safe, as the threshold could be bypassed.
Why focus on Hardware Wallet vendors ?
Hardware Wallet vendors are an interesting group because they grew up with EOAs, are very conservative (at least security wise), but still need to provide appealing features to their user base to prevent mass migration and loss of the revenue brought by users staying in their ecosystem (such as swaps). This is especially important as 7702 makes the migration to smart accounts transparent and could enable "vampire attacks" from other wallets.
We'll consider the minimal but still impactful feature set that 7702 could provide considering the following requirements :
- the deployed delegate is audited and immutable
- the security model and attack surface don't get significantly more complex - smart contracts can by design do anything, we'll only consider very basic functionalities (see me at EthCC for more fancy stuff, last ad I promise)
- the security features don't get significantly worse - specifically Hardware Wallets vendors spent resources on "clear signing" (making sure that what you see is what you sign, and that users understand what they're signing) and it'd be great to still be able to use it
- the migration doesn't involve too much extra development for the Hardware Wallet, the wallet and a few selected critical dapps.
Taking this into account, the easiest thing a smart account could provide is transaction batching (atomic multi operations) and optionally gas sponsoring.
Batching makes all dapp interactions easier by getting rid of the approval then action dance, which is good for the user experience, an easy way to remove some MEV signals, and overall improves the security of the interaction by limiting the appeal of infinite approvals.
Gas sponsoring also removes important friction when the user doesn't have native tokens on a given chain.
We'll now compare different strategies to implement that.
Transaction batching implementations
Back to basics - ETH function calls
An arbitrary ETH smart contract function is called using the following parameters of the transaction :
- The
destination, coding the address of the smart contract
- The
value, coding the amount of native asset made accessible to the payable smart contract function
- The
data, coding the function name in the first 4 bytes (called the selector), and the function parameters in the following bytes
Batching is just a matter of defining how an array of those elements can be transferred as parameters of the batching function, then issue a transaction that'll perform the batched calls.
This also means that in the best case scenario, if the Hardware Wallet is able to parse the data field of the transaction when clear signing, it'd require a modification of the parsing logic to iterate over the different elements, and display each one.
Safe case study and most simple batching
Safe is a popular implementation of transaction batching through the third party MultiSend contract
The different transaction elements are simply chained together using abi.encodePacked along with a flag indicating the call type (regular or delegate).
However being a third party contract, MultiSend needs to be called by the account contract using a DELEGATECALL to act as the account (having a similar msg.sender). This also gives access to the account storage and creates an additional security risk that was exploited during the Bybit Lazarus incident by replacing the implementation of the account in place.
This highlights the need to implement the batching mechanism directly in the account contract rather than delegating it as an external feature.
Standardizing simple batching
ERC-7821 provides a standardization of simple batching using abi.encode to encode the destination, value and data parameters.
Compared to ERC-7579 which it reuses it doesn't support delegate calls, making it safer to validate.
Account contracts can offer an ERC-7821 interface either directly or through another execution mechanism, such as EIP-4337.
Batching with more sophisticated actions
Experiments have been made in the Starknet ecosystem to create a batch structure where the data of a previous call can be reused in the next one with the Better Multicall proposal - I don't think there has been a similar proposal in the Ethereum ecosystem but it could be something interesting to investigate for more complex scenario without needing a specific smart account or a smart account plugin to handle them.
Batching with ERC-4337
ERC-4337 doesn't specify a batching or execution mechanism directly, and a compliant smart account only has to implement a method to verify that a transaction intent (UserOperation) is valid.
The batching mechanism will be decided by the contract and implemented in the callData field of the UserOperation - typically the reference ERC-4337 account implementation, BaseAccount implements a simple batching strategy using abi.encode
As the user only signs UserOperation with ERC-4337 and doesn't submit transactions directly to the account (this is done through the EntryPoint by the Bundler), it is important for the Hardware Wallet to be able to parse the callData field of the UserOperation. This is standardized by version 8 of the EntryPoint defining an EIP-712 compliant signature scheme - of course, the Hardware Wallet parsing logic would still have to be modified to support the baching mechanism on top.
Smart accounts supporting a previous version of the EntryPoint could support their own, proprietary mechanism for signing the UserOperation also compatible with EIP-712.
Before ERC-4337
There were already attemps to sponsor transactions before ERC-4337 (such transaction intents were called in a generic way meta transactions), but some parts were proprietary, especially on the backend side.
Proposals such as ERC-2771 attempted to standardize the onchain part, establishing a set of minimal constraints between the different parties.
ERC-4337
ERC-4337 introduces a decentralized and censorship resistant approach for transaction sponsorship, as all the routing is done onchain and can be observed, which comes with some formalism - transaction intents (UserOperations) are sent to Bundlers, creating a secondary mempool. Bundlers execute UserOperations through the Entrypoint contract. UserOperations can include a reference to a paymaster contract that'll be in charge of sponsoring the transaction.
To use ERC-4337, the wallet provider first has to choose a Bundler - considering that the ERC-4337 mempool is not fully decentralized yet, if the wallet provider had some MEV deals with its current architecture provider it's recommended to pick a Bundler recommended by this provider rather than operating its own.
Choosing a paymaster creates less constraints - the Bundler provider could suggest one, or you could pick one freely or run your own (making sure it's audited)
Vibing with Intents
Intents offer a different take on sponsorship and consider higher level transactions (typically, swapping a token for another one on different chains), that can be executed with more offchain or proprietary components compared to ERC-4337.
ERC-7683 provides an overview of how cross-chain intents could be implemented.
Considering the scope of Intents targets a much higher level than just transactions, they'd be an interesting scheme to explore for a new wallet but not really for what we're targeting here.
State of current implementations
Current implementations are mostly targeting embedded wallets, as there are few wallets operating with smart accounts and even fewer dapps using their capabilities.
Standardization of the wallet interface
EIP-5792 provides a standardized mechanism that dapps can use to support transaction batching and sponsoring. This has to be implemented by the wallet, and customized to the batching mechanism used by the smart account.
Standardization of a simple call
ERC-7821 describes a scenario to perform transaction batching by inspecting the interface implemented by the smart account. Compared to EIP-5792, it doesn't specify a mechanism to specifically track the status of those calls. The dapp can watch the status of the transaction calling the smart account and know that all operations in the batch were successful when the transaction is included into a block.
Review of a few delegate candidates
| Alchemy |
SemiModularAccount7702 |
0x69007702764179f14F51cdce752f4f775d74E139 (ETH,Polygon,OP,Arbitrum,Base,Berachain) |
Multiple, might not be up to date with latest version |
v7 |
No (ERC-191) |
abi.encodeCall |
No |
ERC-6900 |
| Ambire |
AmbireAccount7702 |
0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d (ETH,BNB,Gnosis) |
Multiple, might not be up to date with latest version |
v7 |
Yes, EIP-712 on proprietary domain |
abi.encodeCall |
abi.encodeCall |
External signature validation, account recovery |
| MetaMask |
MetaMask EIP7702StatelessDeleGator |
0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B (ETH,BNB,Gnosis,Polygon,OP,Arbitrum,Base,Linea) |
Cyfrin, Diligence |
v7 |
Yes, EIP-712 on proprietary domain |
extended ERC-7821 |
Yes, extended ERC-7821 |
ERC-7710 |
| ERC-4337 |
Simple7702Account |
0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 (ETH,BNB,Avalanche,OP,Arbitrum,Base,Taiko) |
SpearBit |
v8 |
Yes, native EIP-712 |
abi.encodeCall |
abi.encodeCall |
None |
On the complexity side, ERC-4337 account is definitely the most simple as it doesn't implement any extra functionality other than basic management of the account - but it doesn't support a standardized interface for batching calls directly.
MetaMask account is a bit more complex, but the DeleGator functionality could be disabled by deploying it with a different constructor parameter setting the delegation manager to the null address - also it supports a standardized interface for batching calls directly.
Ambire and Alchemy support additional functionalities that cannot be disabled.
Conclusion
Fastest track for batching
A fast track for batching would be to support a smart account with ERC-7821 support (either by using MetaMask EIP7702StatelessDeleGator implementation or adding support to ERC-4337 Simple7702Account implementation), and ask selected dapps to support ERC-7821 natively.
Support for ERC-7821 would be faster to achieve than support for EIP-5792 as there are no changes on the wallet side but it's less standard on the dapp side.
In this scenario, the Hardware Wallet transaction parsing code would need to be updated to support ERC-7821 for clear signing (abi.encode of the destination, value and data parameters)
Transactions are originated by the EOA, and call the delegated execute method on the EOA address.
Fast track for batching
Alternatively, the wallet can add support for EIP-5792 and the batching scenario for the selected smart account implementation, then ask selected dapps to support EIP-5792.
In this scenario, the Hardware Wallet transaction parsing code would need to be updated to support the method used by the smart account implementation for direct batching.
Transactions are originated by the EOA, and call the delegated specific execution method on the EOA address.
When both batching and sponsoring are desired, it's recommended to use ERC-4337.
The wallet would need to add support for EIP-5792, choose a Bundler and a Paymaster, then ask selected dapps to support EIP-5792.
In this scenario, the Hardware Wallet EIP-712 signing code would need to be updated to recognize the callData of the UserOperation structure, parse it and link it back to the transaction parsing code according to the batching mechanism used by the smart account implementation.
Signed UserOperation are sent to the Bundler using an RPC call.
🚀 Let's future-proof Ethereum together!
References
Reach us
🔐 Practical security on the whole chain.
Github | Website | Twitter | Blog | Contact Info
Found typo, or want to improve the note ? Our blog is open to PRs.
EIP-7702 for Hardware Wallet vendors
2025 May 07 See all posts(Pectra dealing with Twixtter FUD)
Introduction
As a minimalistic perspective on my upcoming EthCC[8] presentation, this blog entry describes how Hardware Wallet vendors could quickly benefit from turning their Externally Owned Accounts into smarter account with EIP-7702 available with Pectra today, with as little impact on their infrastructure as possible.
High level overview of EIP-7702
EIP-7702 introduces a new transaction type (v4), adding the concept of authorization lists - each element of the list provides the following crytographically authenticated elements :
After the authorization list is processed, the EOA code execution flow is similar to the delegate's, with its own storage, and it can still originate transactions.
ERC-4337, the reference implementation for standardized and censorship resistant smart accounts architecture has also been updated to support EIP-7702
Choice of the delegate is critical as a malicious or buggy delegate could drain the account - wallets are expected to filter those carefully.
Since the EOA can still originate transactions, some use cases do not make sense if its private key is known - typically you wouldn't delegate to a threshold multi signature contract such as Safe, as the threshold could be bypassed.
Why focus on Hardware Wallet vendors ?
Hardware Wallet vendors are an interesting group because they grew up with EOAs, are very conservative (at least security wise), but still need to provide appealing features to their user base to prevent mass migration and loss of the revenue brought by users staying in their ecosystem (such as swaps). This is especially important as 7702 makes the migration to smart accounts transparent and could enable "vampire attacks" from other wallets.
We'll consider the minimal but still impactful feature set that 7702 could provide considering the following requirements :
Taking this into account, the easiest thing a smart account could provide is transaction batching (atomic multi operations) and optionally gas sponsoring.
Batching makes all dapp interactions easier by getting rid of the approval then action dance, which is good for the user experience, an easy way to remove some MEV signals, and overall improves the security of the interaction by limiting the appeal of infinite approvals.
Gas sponsoring also removes important friction when the user doesn't have native tokens on a given chain.
We'll now compare different strategies to implement that.
Transaction batching implementations
Back to basics - ETH function calls
An arbitrary ETH smart contract function is called using the following parameters of the transaction :
destination, coding the address of the smart contractvalue, coding the amount of native asset made accessible to thepayablesmart contract functiondata, coding the function name in the first 4 bytes (called the selector), and the function parameters in the following bytesBatching is just a matter of defining how an array of those elements can be transferred as parameters of the batching function, then issue a transaction that'll perform the batched calls.
This also means that in the best case scenario, if the Hardware Wallet is able to parse the data field of the transaction when clear signing, it'd require a modification of the parsing logic to iterate over the different elements, and display each one.
Safe case study and most simple batching
Safe is a popular implementation of transaction batching through the third party MultiSend contract
The different transaction elements are simply chained together using
abi.encodePackedalong with a flag indicating the call type (regular or delegate).However being a third party contract, MultiSend needs to be called by the account contract using a
DELEGATECALLto act as the account (having a similarmsg.sender). This also gives access to the account storage and creates an additional security risk that was exploited during the Bybit Lazarus incident by replacing the implementation of the account in place.This highlights the need to implement the batching mechanism directly in the account contract rather than delegating it as an external feature.
Standardizing simple batching
ERC-7821 provides a standardization of simple batching using
abi.encodeto encode the destination, value and data parameters.Compared to ERC-7579 which it reuses it doesn't support delegate calls, making it safer to validate.
Account contracts can offer an ERC-7821 interface either directly or through another execution mechanism, such as EIP-4337.
Batching with more sophisticated actions
Experiments have been made in the Starknet ecosystem to create a batch structure where the data of a previous call can be reused in the next one with the Better Multicall proposal - I don't think there has been a similar proposal in the Ethereum ecosystem but it could be something interesting to investigate for more complex scenario without needing a specific smart account or a smart account plugin to handle them.
Batching with ERC-4337
ERC-4337 doesn't specify a batching or execution mechanism directly, and a compliant smart account only has to implement a method to verify that a transaction intent (
UserOperation) is valid.The batching mechanism will be decided by the contract and implemented in the
callDatafield of theUserOperation- typically the reference ERC-4337 account implementation, BaseAccount implements a simple batching strategy usingabi.encodeAs the user only signs
UserOperationwith ERC-4337 and doesn't submit transactions directly to the account (this is done through theEntryPointby theBundler), it is important for the Hardware Wallet to be able to parse thecallDatafield of theUserOperation. This is standardized by version 8 of theEntryPointdefining an EIP-712 compliant signature scheme - of course, the Hardware Wallet parsing logic would still have to be modified to support the baching mechanism on top.Smart accounts supporting a previous version of the
EntryPointcould support their own, proprietary mechanism for signing theUserOperationalso compatible with EIP-712.Transaction sponsoring implementations
Before ERC-4337
There were already attemps to sponsor transactions before ERC-4337 (such transaction intents were called in a generic way meta transactions), but some parts were proprietary, especially on the backend side.
Proposals such as ERC-2771 attempted to standardize the onchain part, establishing a set of minimal constraints between the different parties.
ERC-4337
ERC-4337 introduces a decentralized and censorship resistant approach for transaction sponsorship, as all the routing is done onchain and can be observed, which comes with some formalism - transaction intents (
UserOperations) are sent toBundlers, creating a secondary mempool.BundlersexecuteUserOperationsthrough theEntrypointcontract.UserOperationscan include a reference to apaymastercontract that'll be in charge of sponsoring the transaction.To use ERC-4337, the wallet provider first has to choose a
Bundler- considering that the ERC-4337 mempool is not fully decentralized yet, if the wallet provider had some MEV deals with its current architecture provider it's recommended to pick aBundlerrecommended by this provider rather than operating its own.Choosing a
paymastercreates less constraints - theBundlerprovider could suggest one, or you could pick one freely or run your own (making sure it's audited)Vibing with Intents
Intents offer a different take on sponsorship and consider higher level transactions (typically, swapping a token for another one on different chains), that can be executed with more offchain or proprietary components compared to ERC-4337.
ERC-7683 provides an overview of how cross-chain intents could be implemented.
Considering the scope of Intents targets a much higher level than just transactions, they'd be an interesting scheme to explore for a new wallet but not really for what we're targeting here.
Using batching and sponsoring in a dapp
State of current implementations
Current implementations are mostly targeting embedded wallets, as there are few wallets operating with smart accounts and even fewer dapps using their capabilities.
Standardization of the wallet interface
EIP-5792 provides a standardized mechanism that dapps can use to support transaction batching and sponsoring. This has to be implemented by the wallet, and customized to the batching mechanism used by the smart account.
Standardization of a simple call
ERC-7821 describes a scenario to perform transaction batching by inspecting the interface implemented by the smart account. Compared to EIP-5792, it doesn't specify a mechanism to specifically track the status of those calls. The dapp can watch the status of the transaction calling the smart account and know that all operations in the batch were successful when the transaction is included into a block.
Review of a few delegate candidates
abi.encodeCallabi.encodeCallabi.encodeCallabi.encodeCallabi.encodeCallOn the complexity side, ERC-4337 account is definitely the most simple as it doesn't implement any extra functionality other than basic management of the account - but it doesn't support a standardized interface for batching calls directly.
MetaMask account is a bit more complex, but the DeleGator functionality could be disabled by deploying it with a different constructor parameter setting the delegation manager to the null address - also it supports a standardized interface for batching calls directly.
Ambire and Alchemy support additional functionalities that cannot be disabled.
Conclusion
Fastest track for batching
A fast track for batching would be to support a smart account with ERC-7821 support (either by using MetaMask EIP7702StatelessDeleGator implementation or adding support to ERC-4337 Simple7702Account implementation), and ask selected dapps to support ERC-7821 natively.
Support for ERC-7821 would be faster to achieve than support for EIP-5792 as there are no changes on the wallet side but it's less standard on the dapp side.
In this scenario, the Hardware Wallet transaction parsing code would need to be updated to support ERC-7821 for clear signing (
abi.encodeof the destination, value and data parameters)Transactions are originated by the EOA, and call the delegated
executemethod on the EOA address.Fast track for batching
Alternatively, the wallet can add support for EIP-5792 and the batching scenario for the selected smart account implementation, then ask selected dapps to support EIP-5792.
In this scenario, the Hardware Wallet transaction parsing code would need to be updated to support the method used by the smart account implementation for direct batching.
Transactions are originated by the EOA, and call the delegated specific execution method on the EOA address.
Batching and sponsoring
When both batching and sponsoring are desired, it's recommended to use ERC-4337.
The wallet would need to add support for EIP-5792, choose a
Bundlerand aPaymaster, then ask selected dapps to support EIP-5792.In this scenario, the Hardware Wallet EIP-712 signing code would need to be updated to recognize the
callDataof theUserOperationstructure, parse it and link it back to the transaction parsing code according to the batching mechanism used by the smart account implementation.Signed
UserOperationare sent to theBundlerusing an RPC call.🚀 Let's future-proof Ethereum together!
References
EIP-712 - Typed structured data hashing and signing
ERC-2771 - Secure Protocol for Native Meta Transactions
ERC-4337 - Account Abstraction Using Alt Mempool
EIP-5792 - Wallet Call API
ERC-7579 - Minimal Modular Smart Accounts
ERC-7683 - Cross Chain Intents
EIP-7702 - Set Code for EOAs
ERC-7821 - Minimal Batch Executor Interface
Reach us
🔐 Practical security on the whole chain.
Github | Website | Twitter | Blog | Contact Info
Found typo, or want to improve the note ? Our blog is open to PRs.