New Security Challenges with EIP‑4337 & EIP‑7702

Transcript

Hello. Can you hear me well? So, not a common first slide, right? So, I had three ideas when choosing this first slide. The first one was to get your focus, of course. Uh the second one is uh maybe there is real money inside this private key. And the third one was to make you wonder about um what if there is another way um rather than using non-really secure private keys, but um maybe using account abstraction, which is maybe the topic of this talk. So, hello everyone. I'm Lilian. I'm a security engineer from my verification research at Sakura. Uh today I'm going to talk about uh account abstraction, so

EIP-4337 and 7702. The question we're going to try to answer today is how to trust delegators, or to be sure that funds are safe when delegating to 7702, and flows are secure uh when using 4337. So, for those who don't know about 4337 or 7702, um let me give you a brief introduction before diving in. Uh 4337 introduce an alt mempool for user operation, a bundlers who package transaction, and an entry point singleton contract. No hard fork required, works today on any EVM chains.

7702 on the other side uh don't probably converts a user signing account into a smart contract wallet for a duration of a transaction >> [snorts] >> uh by introducing a new type of transaction, which is 0x0f. And it required the Pictoral fork. The main idea is to uh is to enhance the user experience and security without permanently altering the account structure. So, same address, but now programmable. And both of them expand the attack surfaces. Yeah. I forgot about that.

Um let's deep dive into the 433 architecture because it directly explains the attack surface. So, first we have a user creating a user operation. This absolute transaction containing up to 15 fields uh like user, sender, calldata, gas parameters, paymaster if used, uh signature, of course. Uh this user ops goes into a user op mempool. These are different from the Ethereum pool we all know, and uh it's optional. Uh it's more and more used, but it's still optional. Um and then we have the bundler, which are off-chain actor that collects a user operation, and as you may have guessed, uh creates a bundler transaction uh with a valid transaction with a valid user ops.

Then we have the entry points. The entry points orchestrate the uh simulation and execution in two phases. So, first validation loops check signature, check user paymaster funds if used, and then [snorts] the execution loops, which actually um uh runs the operation. >> [snorts] >> Finally, we have the post op, which is also optional, um and this is where, if used, the bundler gets compensated by either the user or the paymaster. Um about the entry points, uh keep in mind that it's a single point of failure by itself. That's why it had multiple audits and has an active bug bounty on Immunefi.

Uh about 7702, the architecture is simpler, but the implications are more profound. You have your EOA, you sign an authorization tuple containing two an ID address nonce signature >> [snorts] >> and then the EVM will write a special code to your EOA, uh which is 0x0100 plus the delegate address. And then when your EOA is triggered, the code will run in your EOA context using your storage, your balance. Two things to remind about 7702 for now. The first thing is that the delegation is revocable. You can delegate to address zero to clear the code. And uh you can still sign raw transaction for now. Uh I mean by that that even when delegated to a malicious the private key can still sign raw transaction.

So, let me crystallize the key differences here. In terms of layer, uh 4337 is application layer, no fork required. Um 7702 is protocol layer. It required the Pictoral hard fork in May 2025. In terms of account model, uh 4337 introduce new smart account address, so migration required. 7702 on the other side preserves the existing EOA address, so no migration required, uh which is huge for UX. In terms of infrastructure, 4337 introduce bundlers, a mempool, entry points, so external actors are required. And on the other side, 7702 use native transaction, so no extra actor required except delegator, but usually you either trust a delegator or you develop it yourself.

And finally, in terms of private key, in 4337 it's even optional. You can have fully smart accounts. And 7702, as I said, always retain pseudo access. You can't remove the weak control for now. And in practice, they are complementary. I mean by that you will see EOA delegating via 7702 to 433 compatible wallets code uh by using paymaster for gas sponsorships. >> [snorts] >> This is the likely prediction pattern. So, let's see some exploit, and then the idea is to map the attack surface. Um when we're talking about uh account abstraction 4337, usually it means Alice will pay gas for Bob's. And two questions here that can come to mind. The first one is what if

Bob has a possibility to not refund Alice? And what more than that, what if Bob has a possibility to drain Alice's Then uh one thing to know about the 4337 architecture is that um the entry point will charge a 10% penalty on the unused gas exceeding 40K. >> [snorts] >> And this penalty is deduced either from the user or the paymaster. So, let's see a paymaster gas drain exploit. This is a simple uh griefing attack. So, we have an attacker that creates a malicious user ops. We will see why malicious later, but uh let's say the call gas limit set by the user is 500.

Then the paymaster agrees to sponsor it because why not? The entry point execute, and the actual gas used is only 50K. So, the entry point will say, "Okay, you asked for 500, I used 50K." It means that the penalty will be on 450K minus the 40K buffer, which is equal to 41K gas of penalty. And here, two problems. The first one is what if the paymaster forgot to to account for the excess penalty gas cost? It means a user can create a malicious user ops um by setting the call gas limit a lot higher, but if the paymaster forgot to include the potential penalty gas cost, the paymaster will pay for the excess.

And second problem, which is worse, you can design a malicious bundler that can that can be created to always trigger the penalty gas cost, and the paymaster will gently give to the bundler, to you, the penalties applied by you. It like it's like applying taxes on a project your client are forced to buy. It may it might remind you someone. Uh and the fix is easy here. Uh you just have to um account for the potential penalty gas cost. So, let's see um um something similar in 7702. It's a more severe scenario. It's well known, but um it's common example. So, we have Alice Alice that wants to use a 7702, and uh

wants to delegate to delegator A. Delegator A layout is simple. You have nonce in slot zero, uint256, and you have balance in slot one. And let's say after some couple of transaction, Alice slot are six. Uh Alice slot zero nonces are set to six, six and Alice was smart and sold her BTC at 120K like everybody in this room, right? And she has uh 10 million USDC in slot one. Then Alice wants more fine-tuning, and she wants to delegate to delegator B.

Delegator B layout is totally different. We have an array of uint256 item in slot zero, and we have a mapping of data in slot one. And then when the when Alice EOA is triggered, um delegator B will read the leftover states from from delegator A, and will set the item at slot to six, uh which basically will break the account. So, the logic is correct because we have an unpredictable behavior, and it's pretty hard to fix because the storage layout is now unknown.

So, um simple takeaway here, remind that the EOA storage persists across re-delegation. So, let's see um another 4337 example. One thing to know about the 4337 type of paymaster that there are basically two kind of paymasters. The first one are the validation paymasters that are used mostly for uh gas sponsorships. So, they are doing a lot of verification validation to decide if uh user transaction is eligible for gas sponsorships. And there are the ERC-20 paymasters, the one we will focus on for this story.

The ERC-20 paymaster enable user transaction inclusion in exchange for ERC-20's token equivalence. This kind of paymaster either charge the user before the execution, so before the entry point, or after the execution, after the post op. So, please raise your hand if you think that the paymaster should take the fund before. Okay. And raise your hand if you think that the paymaster should take the fund after. Okay, so a lot of uh I know.

Um So, let's see an example where the paymaster takes the fund after. And here, what do you think will happen if the user execute and revoke their approval as part of the execution phase. So, it's easy. The entire the post-op will fail and the entire transaction will fail, which means that everything will fail, of course, but the paymaster still has to pay for funds. So here the good answer um what is to take the fund before because we always follow the protocol, but there are couple of problem we have to face.

So, first one is that we must estimate the gas up front based on gas limit. We will end up overcharging the user because you can predict the exact exact exact cost. You have to account for the 10% penalty and you have to not be a victim of all the Oracle conversion risk that could happen. I mean by side DOS, decimal issues, and conversion price. >> [snorts] >> So, if you take the fund before, you will end up overcharging, which is the way to go, but if you take the fund after, there is a risk of undercharging the user or not charging it at all because the user can revoke the approval during the execution.

Um So, yeah. Golden rule, still collect pre-collect the maximum fund as possible before and if there is excess, you refund the user. It's easy. Um about that, there are and there is an ERC that tries to mitigate the simulation execution gap we have in in a 4337. This is the ERC 7562. >> [snorts] >> This ERC basically do two things. The first one is that it ban up codes that anything that could change between simulation and execution are banned. So, timestamp block as base fee, coinbase are banned, and um it does one more thing. It restricts the external storage access full. So,

basically, you can only read mappings where the sender is the key. So, [snorts] the takeaway for ERC 7562 is that it reduces attack surface, but doesn't eliminate the fundamental doctor problem we have in 4337. And another edge case um on 4337 is that during simulation, the the storage is still maintained cold, which could represent a differences between execution between simulation and execution in terms of gas cost. So, one things to do about that is to have the entry point performing a view call before validation to kind of warm the storage slots.

So, this helps reduce the discrepancy problem we have here, but keep in mind that if your validation success depend on um simulation gas cost versus I mean cold versus warm gas cost, you can still grieve the paymaster. So, we have seen some attack. We have seen some differences. Let's try to map the 4337 pitfalls we are fundamentally >> [snorts] >> um The first one is about the signature. This is where most implementation bugs live. So, when [snorts] you are discussing about signature for 4337, you have to do two things. The first one is you have to include chain ID, entry point address plus the fees and gas parameter in the hash. This is really important. If you miss any of this, you

enable replay attack. And second things, there are the valid until and validator field that exist, so please use them. You really have to treat the signature as a library decision and you have to bind the signature to use the user up plus the hash for a user. This is really important. Second things, you have to not revert on the bundler for invalid signature. Your bundler is an off-chain actor. So, if you let someone spam your your bundler, you enable DOS attack for it. So, you have to let the entry point under the revert scenario. So, your bundler must return the signature validation fail, never revert on the bundler side. Number three, this one is funny, but the original 4337 miss it. You have to verify that the

message sender is the entry point on your paymaster, otherwise, it's open door. And finally, you have to account for the 10% penalty as we discussed. There are a lot more. It would be too long to discuss all of them, but you have to maintain your your validated user up as stateful as possible. You have to never rely on post-op for current variants and keep the post-op as minimal as possible, too. We can discuss this later if you want. Let's do the same for 7702. Um Here four well-known critical attack surfaces. First one is the chain ID. If you set the chain ID to zero, it makes the authorization valid on all EVM chains, so you don't want to do that for

two reason because it's obvious and the second one is because the same contract address on different chain may have completely different different code. So, please [snorts] always specify explicit chain ID on initialization tuple. Second one is initialization front running. Remind that the 7702 has no init code, so constructor don't run in your EOA context. So, if you want to set role permission owner, you have to do it atomically. I mean delegation and installation in the same transaction never delegate to proxies or upgradeable contracts, but only delegate to immutable on object contracts because >> [snorts] >> your EOA if your EOA is upgradeable, it's it's a logic, but the the guy that controls the upgradeability

controls your EOA. >> [snorts] >> And remind that the same is true for 4337. The attacker can extract the init code from my user up and front run the deployments. Number three, access control and delegation. This is where the 0xEF0100 belongs. So, first, it's well-known, but it has caused more than 3.2 million in losses, so I had to talk about it, but never no longer rely on tx.origin. And if you want to detect delegation in your smart contracts, you can use msg.sender.code.

>> [snorts] >> Number four, we have talked about this. Storage persists when you redelegate to a new contract. So, again, that we have two layers of defenses. The first one is to use 7201 name space storage to derive the storage slot in a unique way. You can follow ERC-779, which is still a draft, I think, but it provides a way delegation standard for safe migration. And finally, it's not really handy, but you can clear the storage explicitly before any redelegation. I mean by that, you can do it by hand with Solidity or assembly code in your delegated contracts.

So, what's next for account abstraction security? There are two EIPs worth knowing. Both are from Vitalik. You may know him. The first one is EIP 8141, which is called an omnibus frame transaction. The idea is to move 4337 from application layer to protocol layer, so no more off-chain bundler, no more entry point middleman. And the idea is to do that by introducing a new type of transaction, 0x06. About 7702, there is this new IP also, which is 7851, which aim to deactivate the private key override on delegated EOA. So, the idea is to provide a new precompile to deactivate the private key and once

disabled, the private key can only be only be re-enabled via the delegator itself or multi-sig. So, and about that, there is a follow-up EIP 82151 for easy recover because here the idea is to make easy recover um aware of deactivated private key, otherwise, the the bypass is easy. And [snorts] two more things worth knowing. The first one is ERC-7739 already used by OpenZeppelin contracts and RIP-7560, which aim to patch native roll-up account abstraction by using two-dimensional nodes.

The key takeaway from this slide is that account abstraction is not a finished feature and has an evolving surface attack. So, what we discussed today may not be true in six or 12 months. Thank you very much. Account abstraction is a deep technical topic so So, if you need any help, design review, manual auditing, formal verification, or even web2 auditing service, please come to see us. I still believe that account abstraction is the really only way to onboard the next wave of user. So, if you want to deep more, please follow me or the Saturn account on X.

Thank you. >> [applause] >> Uh If there is question, we have 2 minutes. Thank you. Hello. Yeah. There There is a part I did not quite understand is you say that you should never delegate to an upgradeable contract. But my understanding is upgradeable contract, there are two part. There is a proxy and the implementation. Actually, delegating to the implementation feels like what we should do because they are designed to be updated. They use name space storage. And if you were to

upgrade to a proxy, what the proxy does is it just redelegate to another address that is in no storage, which in our case would be the storage of the EOA. So, it would just basically not work. So, what exactly is the the danger here? That's right. You describe the right case. I wanted to keep things as simple as possible, but you're right. If you if you know what you are doing, I would say you can you can do this kind of thing. That's right. I of the two new EIPs from a security perspective, which do you prefer?

Both are targeting different things, but I think that moving account abstraction 4337 from application layer to protocol layer is a really good things to do because we have modules in 4337. We have module where a lot of things that can be fine-tuned, and this is where usually error are found. Thank you.