# Sebastian Banescu - Security Risk Implications of the Pectra Upgrade

- Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup)
- Date: 2025-11-09
- Duration: 27:40
- Watch: https://streameth.org/watch/yt-yrs3FToBXK4
- YouTube: https://www.youtube.com/watch?v=yrs3FToBXK4

## Description

The Pectra upgrade, which went live on May 7, 2025, introduces significant improvements to the Ethereum network, enhancing its scalability, security, and usability. However, this upgrade is also facing significant security risks as it is being widely exploited by hackers, with over 80% of EIP-7702 delegations being linked to malicious contracts. In this talk we will unpack both pros and cons of the Pectra upgrade and discuss security countermeasures to keep you safe on Ethereum.

## Transcript

So today we're going to talk about security implications of the Pectra upgrade. I'm not sure how many of you already know about about the Pectra upgrade. Can I see a raise of hands? Awesome. Pretty much everyone. Uh the agenda is uh you know for you and for me. I I need to know and everyone needs to know where we are. We're going to start with um you know an overview of the Pectra upgrade. We're going to dive deeper into EIP7702 and finally we're going to talk about some counter measures to mitigate the risks that Perra introduces. So going off of the the first part um how many of you know how many you know legitimate you know planned upgrades uh Ethereum has had up to date over the years? Any guesses? No guesses. So, it's uh around 10 10 planned upgrades if you don't count the um hard fork that was caused by the DAO hack. And it's about one per year except for 2021 uh where there were two upgrades. And uh starting with the merge, you can see the image there. the consensus client and the execution client have been upgraded uh in parallel like at the same time whenever there's a hard fork and they have these funny names where they combine the name of the consensus client on this um column with the name of the execution client which is uh using the names of all the devcon uh cities. All right, the Pectre upgrade is one of the biggest upgrades so far. Initially, I think it it planned to have around 20 EIPs, which is absolutely crazy. And they boiled it down to 11 and they were discussing which EIPs to include and which to exclude up to the last 24 hours. Um, I'm not going to go over all of them, but I just wanted to give you an overview of what each upgrade does. I'm not sure if it's visible in the back of the room. Um, we're going to dive deeper into number 10 here on the list, which is uh 7702. But before we do that and we look at all of those security issues that were introduced there, let's look at, you know, the core objectives that PCRA had. So it basically intends to enhance three pillars. One is the validator efficiency. There's a bunch of EIPs that have to do with improving how validators operate and and what they can do. The second one is to boost uh layer 2 scalability because there are as we know dozens of layer 2 solutions now on Ethereum and uh things were getting a bit crowded. um also on the network side. And the third one is to improve the user experience vastly. So I'm going to go over a few pros. Um the first one is for staking and validator enhancements. the the uh EIP7251 is basically meant to, you know, the this was one of the most um awaited EIPs because not only does it do does it allow you to add more ETH to your validator from 32 ETH to48 ETH, but it also introduces these compounding um rewards. So before PectRA uh what validators needed to do was to get their rewards separately, wait for that reward to accumulate and then create a new validator such that they can earn rewards on their rewards. Now this is done automatically. So if you have a validator which has under 248 ETH and it earns rewards, those rewards immediately compound and you start earning uh more rewards on them. Uh, EIP702 allows validators to exit without needing to coordinate with their um, infrastructure providers. So, you have a lot of custodians that allow you to do staking through another validator and there was a lot of communication needed between the custodian and the node operator. This no longer is the case when you want to exit. But there's a catch. If the validators get slashed, they get put into a queue and you as a custodian cannot exit until the 48 days are up. And finally, 6,110 allows for faster deposits. This doesn't mean that the validators start earning from days, you know, like before it used to take days to process this deposit. Now it takes minutes, but you still get put into the queue and you might need to wait a few days depending on how big the queue is. The second pillar which was the L2 scalability enhancements is also a big pro where before you used to have this um this image here where there was a lot of clutter, a lot of people misusing certain uh pieces of of uh the infrastructure like the call data to to put uh data blobs and so on. you now have increased blob capacity that allows uh validators to put more data at a cheaper price um on on the L1 and you have this EIP that introduces some pre-ompiled um cryptographic libraries like BLS to um significantly reduce the gas costs when you need to process you know like the the the the cryptography primitives in ZK K. Um, rollups. And finally, I think there's a lag with my remote. Yeah. Finally, uh, you have EIP 29, uh, 35 that stores the the recent block hashes that allows, you know, like um, this to be accessible directly on in the state. So you you can do the verification of proofs on chain and you don't need to rely on an off-chain service to do that. All right, cool. Now we get to part two, which is a bit more tricky. EIP7702. There's a dilemma here because it introduces a lot of p a lot of you know like cool features when it comes to UX but it also creates a lot of pitfalls for uh unsuspecting end users. And I want to see another raise of hands as to how many people here have had to do an approve and then a confirm when you needed to do anything like swap tokens or deposit tokens. Yeah, pretty much everyone. This was really annoying because both the approval has some gas costs as well as the actual thing you want to do. And another problem that we had here was that when you were approving, you needed to either specify unlimited um access to your particular token like die in this case or you needed to specify an exact amount that you wanted to swap or deposit. And that became annoying if you if you were really like security conscience and and you wanted to limit the spend, you needed to pay these approval costs, the transaction fees every time. And this was very annoying. This is just one example of um where I think most users had to do with, you know, multiple transactions insteading being able to batch transactions. What EIP7702 does is that it grants superpowers, you know, to to these EOAs to the to the wallets. And it does that by introducing a new transaction type. uh transaction uh has this this code for and it allows to you know um it allows every EOA to attach the code of a smart contract to it uh for a temporary amount of time. I I I noticed now that there's a single transaction is written there. It's not necessarily 100% accurate. It actually stays bound to the code until you tell it it shouldn't be bound anymore. Um and the problem that it solves is that you know now um you know you you don't need to do those approval and then confirms. You can do all of that in one transaction. Um and it basically doesn't force you to migrate to a smart wallet. You don't need to migrate your funds from your MetaMask to some smart wallet that can do that for you. You can just do it from your own wallet, whatever wallet you have. Um but yeah and and that is a tremendous user experience improvement because you can do like we just talked about transaction batching but you can do more than that. You can do sponsored transactions where you don't need to pay for gas as the end user. You can do social recovery in case you lose your keys and you have like some trusted people in your circle. You they can help you recover your keys and you know many more pass key signers and so on. And this all of this is done by attaching a logic module to your uh wallet. However, this is where we get to the meaty interesting spicy part. There are plenty of new attack surfaces here. And um you know the core vulnerability, if you want to call it vulnerability, uh is on the social engineering side. So, it's not a bug in the protocol itself or anything like that. It's it's purely creating more opportunities for social engineers to trick users into signing a specially crafted author authorization method and uh stealing their funds. And this is done using um a simple signature. It's not even a transaction, but it's just a signature of your of your wallet where you sign on which chains you want which contract address uh to be associated with your wallet and you provide a nons. So basically you can even use zero as the chain ID to specify that you want this on all chains which is very dangerous. So don't do that. Um the signature is um it basically grants this contract address mentioned there temporary control over your wallet and it keeps that control until you you specify okay it shouldn't do that like you want to associate it either to a different contract or you want to dissociate it completely. And this basically creates this kind of deception when it comes to users because to a user it might seem like a harmless message that they're, you know, signing. They might think it's an airdrop. There were a lot of scams after EIP after Pctor was deployed where people were thinking that they're signing just a simple airdrop uh you know message and they ended up delegating control to their e of their wallet to you know uh malicious actors and they got drained. So as I mentioned uh this is not a protocol failure. This is as intended. It's not a bug. It's a feature. So, you know, we we need to step up our game when it comes to wallet security. Um, there are a bunch of, you know, threats, new threats when it comes to the wallet level. Like, you know, when you get this thing to sign, it's just a 32 byt hash. And if it's not decoded by your wallet, you have no idea what you're delegating your, you know, um, wallet to. And this basically needs to to happen on the wallet provider side. They need to decode this. They need to figure out they need to indicate to the end user what are they doing exactly. And um attackers can easily hide a malicious uh call like set approval for all within a long sequence of seemingly you know benign operations. And finally there's a lot of transaction offiscation going on where you know attackers try to over complicate what is going on in in a certain approval such that users say oh I don't want to check all of this. It's like one of those um you know like uh terms and agreements thing where I don't want to read through all of this. I don't understand this. I'll just uh sign it. And this is where you know users get tricked into delegating their wallet to a malicious contract. And um yeah part three the final one um with the uh with regard to the attack surface is that we have a lot of legacy systems like legacy wallets which you know um are not yet prepared for 7702. So um I'm going to get to that in the third part. What wallet designers need to do in order to prevent uh attacks. But one which is really interesting is this init function. Typically uh in Ethereum contracts you might have a constructor that sets up and creates the contract and then you have an init function that creates you know set some parameters. You would typically write that as separate functions in your smart contract. But the problem is that now with EIP7702, this init call which is done after the constructor could be frontr run by a malicious smart contract. So an attacker could you know uh call the init before your you know intended uh caller and they might get access to the to the entire thing. And then there's another one which has to do with developers where uh typically you know historically everyone was using TX origin which is the EOA that initiated the call to distinguish from the message sender which is the contract that intermediates a call. And by by checking that these two are different you can make sure that you know uh you're talking to uh a contract or not. And now this no longer applies because any wallet can be an actual smart contract. All right. And now we get to the last part which is also um you know I think the takeaway. The the the wallet providers need to step up their security game. So, it's their responsibility in my eyes to implement a clear human readable description of what you're delegating your wallet to. They should um explain this in words, human readable words and not just hex strings. They they need to do transaction simulations such that when you're doing a transaction, before you sign it, they should show you what the net flows are going to be at the end. And um ideally they would integrate some proactive threat intelligence where they blacklist uh certain uh contracts that are known to be malicious and also detect suspicious logic in the contracts that you're trying to de delegate to. On the user side, what you can do is to make sure that if you're if you don't understand what you're delegating to, you're not 100% sure, it seems fishy, just reject it, you know. And um one one thing which is not that convenient but I think it's it's the way I'm going to be doing things you know u after pectra um is that you have a hot wallet that doesn't have all your funds in it and you have a let's say colder wallet maybe a hardware wallet maybe a wallet uh that you don't use very often and um let's say your cold wallet contains most of your funds And whenever you want to interact or delegate, you send a part of your funds that you want to do something with to that new wallet and then you delegate from that new wallet such that if the funds are compromised, it's only a small part of the funds and not the entire amount you have in your cold wallet. Another counter measure which is you know less popular um in terms of like user adoption or or mass adoption is to use something like an MPC wallet where the the keys are basically split over multiple um entities and the the problem that you're trying to solve here is that the the private key the one that you're signing with the delegation is the one that is the single point of failure. So if one user gets social engineered into clicking something by mistake, then you're screwed. So what you want to do is to have multiple parties that have different parts of the key and then a social engineer would need to trick all of those parties, maybe three, maybe even more to um to social engineer them and trick them into signing the same delegation. Um, one key benefit for off-chain policy enforcement is, you know, in institutional MPC solutions that basically have very complex uh security policies when when these kind of transactions happen. So u those are not publicly visible necessarily and um I think like for institutions this is a a less less of a problem as for like the mass uh end user um that end users that use something like a meta mask. The third and final counter measure is to don't trust anything, right? Just try to validate as a as a developer. You know, you should audit your dependencies and you check, you know, if if any of of those might be vulnerable to front running or storage collision. Um, you also assume that all EOAs could be a smart contract. You can't you can't use TX origin to dis discriminate between um a smart contract and an EOA anymore. And you can't use the code hash to check if you know the code size is zero um then you don't have uh an EO you have an EOA. So those those tricks don't work anymore. And finally, there are a few there are a couple of standards that help you with um you know interfaces for requesting permissions. Um and this this is basically meant to improve the user experience when it comes to this 7702 adoption. Uh in conclusion, we're in an arms race as as usual. Pectra brings a lot of power um to you know the user experience to staking to L2s but it comes at a cost of shifting the security burden from the you know immutable protocol uh the reliable and secure blockchain to the wallet layer the DAPs and the users which are more vulnerable and the path forward of course is you know to use these kind of robust key management to use NPC solutions, uh to have like multiple wallets, not all the funds in the same wallet, and you have to have security conscious developers. And that's it for me. Thanks a lot. >> Thank you, Alan. Give it up. >> Perfect timing. Right on schedule. So, we have three questions came in for you >> and I hope everybody's listening. So, first one up here on top. How can I check if EOA has a contract attracted approved or is that not possible? Actually, >> so sorry. >> Oh, yeah. Oh, yeah. Um, so if if is it the Oh, it's this top >> is the top. >> Yeah. Yeah. Okay. Okay. So, I actually don't know the answer to that question. Um, but I do expect there's a there's a there's a call that you can check where whether some uh wallet has something attached to it, but I don't know what the what the call is. >> I heard about it. But the best thing is, you know, next in just like 10 minutes, we have a panel with five guys of you with high security within the blockchain. >> I bet one of you will know. So, we can always bring it up at that point after that one. >> Definitely. So the second one is there a curated list of trustworthiness of smart contracts? >> Um I think every wallet provider has such a list. Um I know there are multiple solution providers uh that integrate with meta meta mask like chain patrol. They have whitel lists of dozens hundreds thousands of contracts that are both whitelisted and yeah they basically use a white list. If something is not on the white list, they basically consider it as malicious, which can be annoying if you deploy a new contract and they haven't included it yet. >> Yeah. Because you create a new code, something new, and it's nothing is there, and they're like, n risk. >> Yeah. Damn it. >> Y. >> So, you always need to keep in touch with these providers and tell them like, "This is me. This is me. Please add it because my users are telling me that there's a scam on my website." One of my colleagues of friends, he just created his own new contract because they had a malicious contract from the market maker and that was malicious but it didn't trigger and they created a new one. So it has on token sniffer it has a 20 out of 100 because of that >> because it's new. Yeah, >> because it's new. >> Yeah. >> But they got up to 100 after a few minutes but still >> so the next one we have here. Do you think the Ethereum community underestimates the risk of the EIP/7702 going live? So quickly after Pekra. >> Well, I mean the EIP was part of PETRA. Um there I think this is a needed risk that we need to take in order to foster mass adoption because now with this EIP you can basically have users that don't even know that they're using a you know crypto onboarding into crypto by sponsored transactions and so on. So it's very convenient for end users and that was a one of the you know big blockers to to mass adoption up to now. So I think you know it it I think the community probably underestimates the risk but it's something a risk that that was needed. Yeah. >> Well think about it. Every OG that came into the SPE took a risk on every single transaction they made in the wallet. we still do every day because you never know maybe. >> Yeah. Yeah. >> Well, do we have any questions? Oh, we have down here. >> Hey, >> so um what happens when we change between delegate delegation contracts and storage slots collide? >> What happens when we change between delegation contracts? So let's say I first delegate to contract 0x1, right? And it uses slot zero for whatever, but it puts some value in there, right? And then I change the implement the contract I delegate to to 0x2, which uses the the same storage slot for something else. What happens then? >> Well, I think the the code itself uh is the one that is is being executed. I I don't think it would fail the transaction if if it uses the same storage slot because the assignment is on the contract code. It's not necessarily looking at which storage slot that contract is going to touch. >> Okay. Thank you. >> So, we're going to have one final question before we go on to the moderator board afterwards. Um maybe you or maybe somebody from the audience, what wallet would you say does describe the risk uh of delegating and using the 7702 in like the best way? Like what wallet does the best job in describing the risk and um using this feature? >> That's a that's a good question. I am I I I can't say that I've used all the wallets out there. One thing that I know is wallets like MetaMask, they have just one wallet that is hardcoded into the extension itself and it only allows you to delegate to that contract such that you don't make the mistake of delegating to some malicious contract. I think that's a good approach. It does limit the the way in which you can use this feature. uh it it sort of like sandbox or like boxes you into whatever you know consensus wants to put into into that contract. But um I think you know contracts still are working on that. I do you have any any contracts that you think like any wallets that you think are good at describing this right now? I haven't seen one myself that I would say like this yeah this is the right thing to do. But if anyone in the room knows a contra a wallet. >> Well, the thing I dislike about the thing that I dislike the most about MetaMask is that it exposes their entire API structure and all of their variables to JavaScript which allows people to overwrite the internals of MetaMask using the JavaScript on the page that you're visiting. Whereas systems like Trust Wallet um and whatever Solano's wallet and I think a couple others they use a proxy architecture where they're funneling the request to secure memory that the web page can't touch. And so I would advise against MetaMask because it although it's hardcoded it can be rewritten using JavaScript >> and that's how people were just like browsing Facebook and had all their money stolen out of Metam Mask. Yeah, you shouldn't do a lot of uh social media browsing with the wallet with the browser where you have the wallet. Yeah, try to keep uh the the browser with the wallet only for crypto um actions and social media. Do it do it on another machine ideally >> like just a hardcoded machine just for the wallet. Yeah. Yeah.