EIP-7702 meets hardware wallets: stories from the browser extension wallet frontlines

EthCC[9] · 1 Apr 2026 · 17:22

Kaloyan Kosev recounts shipping EIP-7702 in a browser-extension wallet. The presentation examines hardware-wallet friction, whitelisting decisions and coordination difficulties across the surrounding ecosystem.

Speakers

Topics

From EthCC[9], hosted by Ethereum France.

Transcript

Hey, hello everyone. Microphone check. All clear? Good. My name is Karol. I'm here to tell you a couple of stories about EAP-7702 and uh how it met hardware wallets. So, it's um as you all know, it's already been an year uh since we had the Pectra upgrade on the Ethereum mainnet. And um at Ambire, uh I am very proud that we are one of the teams that are pioneering EAP-7702. Uh s- from day one when it when the Pectra upgrade uh was live on the Ethereum mainnet, we were among the first wallets, maybe probably the first who um had in production all the cool stuff

that 7702 could bring. And uh we wrote out full support for hot accounts. Why for hot accounts? Well, because you know, 7702 has these two additional types of authorization and type for transaction that have to be implemented or on a firmware level on the hardware wallets. So, what we did with the team is we just put a label coming soon for all the accounts that are imported with hardware wallets on our end, hoping that uh this will land some sometime soon or uh in a couple of weeks. Just we had uh we prepared everything, we prepared the branches, and we were just waiting for

the hardware wallets to release their exciting updates. Um and just to tell you uh the full uh context of the story, um even before the Pectra upgrade in last year, in the beginning of last year, uh our CEO started communicating with hardware wallets for supporting 7702, a new type of transactions. This is an issue he opened against the ledger uh Ethereum app and then sometime around the beginning of the year against the Trezor GitHub project as well.

The result was the community got excited but the hardware hardware wallets I think were not keeping up on this tempo. And what what happened is also with our colleagues we are trying to go to all the major Ethereum conferences around the world and everywhere where we met hardware wallet teams we were speaking with them and trying to explain the importance of 7702 because in our opinion this is the biggest Ethereum upgrade in terms of user experience.

And here is a picture of me and my colleague with the ledger guys discussing as early as in the beginning of last year how important it is for to to bring this support life. But uh to have the absolute full context I would I would like to rant a little bit about why EIP 7702 actually matters. Well, it first unlocks smart account powers for EOAs. This is the core value proposition. It enables it also enables future migration part towards quantum safe signing for EOAs without so without changing your address your account you can migrate to

quantum safe signing in the future and then it helps Ethereum feel like one chain. It helps unify signing, batching, gas payment and also dramatically improves interoperability. And just to recap everything it empowers flexible and a future proof way for gradual adoption of smart accounts. At the time of our first we thought the direction is directly transfer funds to smart accounts and start using smart accounts. But since the last year, I think it's pretty clear that everyone needs a flexible solution, something that can upgrade the current accounts and this would bring the biggest

adoption, I think. And I've brought some examples on how uh how can a full 7702 implementation look look like. This is the transaction builder of of our wallet. So, you you see this popular use case when you grant approval and then fire a second transaction for a swap and bridge and bridge. Uh and uh this is how it looks when the both get batched. With batching, you can unlock even more powerful things like, for example, here on the next slide, you see how I'm sending one ETH.

I'm first swapping USDC to ETH and I'm sending the future ETH that I'm about to receive from this swap transaction to another address. So, with batching, imagine a hardware wallet. Imagine doing this manually. Uh if you use a hardware wallet, you may click up to three four times for every single transaction and trigger three separate transactions on the app and wait for the swap to complete and then send this. This the 7702 brings this possible and I encourage you all if you haven't tried batching, give it a shot because it is really uh it really empowers these kinds of transaction and it limits the chance of

doing something wrong because if one of these things goes wrong, the whole thing will revert and nothing will happen. And then I prepared another example with revoke approvals. So, after using DeFi, you see some hanging approvals instead of revoking them one by one. Here is how with batching you can just batch revoke all the approvals with one signature. And then another example with my colleague Bobby, we implemented different tokens as payable for a gas fee. And in this example, JPYC token, here I have an account with only JPYC token and you see I'm able to pay the fee to pay the fee with JPYC token and

then batch send three separate transactions without even having ETH on this account. So, I think 7702 has already great examples that you can achieve with hot wallets and with hardware wallets, it just I think a matter of time before they unroll this, but let's rant a little bit more. Why one year after all these goodies, why one year after the that EIP-777 adoption got stuck? Well, first of all, it's important hardware wallet support is very, very important because I assume everyone

of you knows that the people with most funds and the companies manage most funds on cold storage still. So, if hardware wallets don't hop on the 7702 board, it will be very hard for 7702 to succeed because all the power users use use hardware wallets. And one year after Pectra, many teams still believe delegating to a contract means giving up control. And moreover, a lot of teams still believe that dapps will be able to some kind of get new superpowers with 7702 and move the funds without having to

do a follow-up transaction. I had this question here at ECC if after delegating to smart contract, then is it needed a follow-up transaction in order to drain that account? And with for my talk, if there are two things that I want you to remember, this is the first thing. Myth one, dApps will drain your account. No, they will not. No wallet wants to support allowing dApps to trigger authorizations. Authorizations are something that is meant for the wallets to use and dApps are meant to communicate to the wallets with existing EIPs like 5792, 7715. So, dApps talk to wallets through capability

APIs, not through authorizations. And then, dApp tells the wallet what they request and wallet decides how to deal with this request. So, this is very very important nuance. To recap, wallets stay in control with 7702 and dApps don't get new powers or cannot move your funds without you confirming. And the second thing that I want you to remember is EIP 7702 isn't cold storage. This is a myth.

Even even some hardware wallets still believe that many see contract delegation is not compatible with cold storage, but in reality, what I want you to remember is that all accounts have logic, even UAs, just their logic is hidden inside the protocol. And changing that with EIP 7702, it simply moved the logic away from the application level towards the delegator, to the smart contract level. And EIP 7702, as I said, doesn't break cold storage security.

Exposes the same logic that EOS already relay on. It's just It's just like move to from the application from the application level. And all of this brings the question why hardware wallets got stuck in the com- communications gap. I think all of us have some fault, es- especially the Ethereum Foundation for not communicated this truly with all the participants in the in the ecosystem. And just to illustrate you how complex the situation is right now, I prepared um two more stories for for the for the support battles that we had. So, first with Ledger, Ledger

they're our friends, but but still they they ca- came up with this whitelisting approach to balance between openness and their security assumptions. Whitelists, they come from uh good uh intentions, uh but uh turn out to be uh something that we fight on for around a year now. They first whitelisted us and MetaMask uh as uh our delegators and accepted the PRs that we we made uh uh for whitelisting us. Then, after months of silence, they just put whitelisting on hold and uh there is not not much news on their end except uh that they will bring 7702 support, but they uh

right now are not allowing anyone to effectively use it. And um no wallet can integrate it uh right now. This is uh the the the messy picture. Uh and uh yeah, whitelisting it comes from good intentions, but as of now it slows adoption and it creates these centralized gatekeepers, which at the first place Ethereum aimed to uh not have. Um if anyone from Ledger is here in this room, I encourage you to take a look at my PR that enables all the Ethereum Foundation recognized delegators. Please accept it and let's move on with 7702.

And next, uh, the Trezor. Uh, in the last year, we had many conversations with Trezor, but unfortunately, uh, the moral of the story is, uh, their focus is elsewhere. Uh, well, they thought, uh, in 2025, last year, they said, "Not on our road map." Up up until recently, uh, we spoke with them and we, uh, we understood that they still believe in some of the myths that we discussed in the previous slides. And then, they promised full EIP 7702 support in May release. So, we will, uh, closely follow follow up on this, uh, on these promises now.

And then, once again, Ethereum can't win if hardware wallets don't keep up. If they walk, the whole the whole UX for the for the end users walk. But, not all of them are, uh, are in this loop. Uh, there is one hardware wallet that actually implemented 7702 with us, and it's GridPlus. This is the third type of hardware wallet that Amber supports. With GridPlus support, they, uh, it's already live on production with us. Uh, we met with Justin, their CEO, and he said they were waiting for a partner on this one, and none of the wallets reached out. So, we were the first one to reach out, and they just built the thing. It's working. And I think, uh,

the moral of the story is that real collaboration, it really beats rumors and white lists every time. And hardware wallets, uh, today, they act as centralized gatekeepers uh, to the new standards. And, uh, our permissioned 7702, I think, kills the spirit that Ethereum uh, win at the first place. In order for 7702 to succeed, the whole stack needs to move. And if hardware wallets doesn't want to move, they are right now the bottleneck and they should be careful because we might have figured a way how to bypass them with your phone. So, can your phone replace hardware wallets? Yesterday my colleague

had a great talk. Spoiler alert, maybe it can. And if you want to learn more, please stay tuned for updates by following me on Twitter and seeing that the content that I share on this topic because it's something that at Ambit we are fully focused and we'll push forward in the next weeks. Thanks so much. All right. I left some time for questions. If anyone wants to ask ask me anything, now is the best time.

I have a question. So, the EIP sounds really promising and everything. Yet, I'm seeing and hearing hearing stories a lot on X for drainers being the biggest use of EIP 7702 and people having wallets drained through 7702 and this creates kind of an image of being something of EIP 7702 being something scary. If it's so good, how does it happen with drainers? Why why do they use it? And can drainer use 7702 to drain your wallet?

This is excellent question. And it is another myth that we are trying to bust at Ambit. Well, currently all these use cases are for private keys that are compromised. There is no other way. So, for the compromised private keys, yes, they delegated to a malicious contract. But, yeah, it's it's only this is the use case. Even with a ledger and treasure, like I said, they blocked authorizations, and no wallet can effectively do that. And with the other wallets, the same. They don't have an API where a DApp can request authorization. Therefore, this this is this is impossible. So, only compromised private keys have delegated to a

malicious contract. Anyone else? Yeah. I think you might have just implicitly answered my question, but it's particularly the delegation transaction that they don't want to support. That the hard What is the detail that the hardware wallet doesn't want to support? Cuz generally, they just sign hashes, right? But Yeah. Well, they are particularly cautious about the delegation request, yes. But, they need to support also a type four transaction. This is in the 777, yeah. So, I think they are more cautious about implementing the authorization. For example, with Trezor, they implemented almost instantly the type four transaction, but for the authorization,

we had a long ongoing loop for this. And yeah, the the core thing is that uh uh they need to be fully sure that this will not allow anyone to trigger transaction without user confirming it on the device, which is the case. Well, I'll throw out a conspiracy theory, and that's that account abstraction doesn't really work well with the business model, does it? True. Very true. All right. I didn't see any more question. Thank you. Thank you very much. See you around.

>> Woo!