New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

What You See Is What You Sign | Prasanna Gautam & Viktor Stanchev, Anchorage Digital | ETHTaipei2025

ETHTaipeiThu, Oct 9, 2025, 12:00 AM

What You See Is What You Sign: How Anchorage is scaling Blockchain interactions | Prasanna Gautam & Viktor Stanchev, Anchorage Digital | ETHTaipei 2025

Transcript

[Music] Hey guys, good morning. Um, let me uh start by asking you guys a few questions. Do you have has everyone here signed a smart contract interaction like a transaction to in you know do a trade or do like something a little bit more advanced than just transferring Ethereum on the blockchain? Like hands up if you've already done that. Okay, good.

Good. So you know what we're talking about. Uh any uh have you guys built DAPs like deployed uh web UIs or smart contracts those kinds of things? No. Has have you guys um built wallets like for signing transactions?

Any code that like actually interacts with uh private keys and has to show users like Okay. Awesome. Awesome. This is good. Um cool.

So, this is going to be relevant for you guys. Um I want to start with a little uh a little game here. Like if you guys read this uh this this UI here, does this uh look like something you guys would sign? It says, you know, be kind and respectful to everyone. Like that's good, right?

Um only share things that are nice. Like okay, you guys would hit agree and continue. Yeah. And hands up if you if you agree. Well, oh no, we didn't scroll down.

there was something more. It says that you have no rights and it says that you just sold your soul. Uh so oops. So this is a lot of uh this the kind of thing that happens in crypto all the time, right? Like you see a interface, it says you're about to do something, but uh do you really understand what you're signing up for?

Do you really understand what you're signing with your those private keys? So um we are uh Victor and Persona. Um I am a founding engineer at Anchorage Digital. Uh, Persona is a blockchain researcher and uh, we work at this company uh, which is essentially doing a lot of different things but primarily uh, we store very valuable private keys and allow our clients to interact with the blockchain with those private keys. One signature could be extremely important, could be a million dollars, could be $10 million, could be $100 million.

when you have that kind of responsibility, it's we like really care about uh what our clients are signing. So, we're going to look at the general architecture of the systems that we use every day to sign transactions. And then we're going to look at the usability of the user interfaces that display what we're about to sign. and then we'll talk about how to improve. Um, so first of all, when you guys start signing like doing anything with DeFi, uh, interacting with smart contracts, first thing you pull out your laptop, you have some maybe your desktop, I don't know.

Um, and it's running some sort of operating system. um that could have issues that could have vulnerabilities. It's running some sort of browser um that also could have vulnerabilities. You start adding more things to it to be able to get to those DAPs. You know, you have to trust the DAP front end that it's doing the right thing.

It has a back end. The these DAPs these like sometimes they include JavaScript from other sources from CDNs. Um you're running various browser extensions. This is sort of the attack surface that we're looking at here. If these things get compromised, then you might not be signing what you think you're signing, right?

Like we don't want that to happen. And consider all the supply chains involved here. Like even with this simple example, multiply that by 10, 100, a thousand because in order for someone to ship a DAP, they have to install whatever like random tool chain locally and curl to bash and whatever they need to do. Um, and they all these things are like massive attack vectors and we've known this for a long time and we've done things about it. Um, oh, before we get into that, um, how many guys have you, how many of you have heard of the bybit hack that happened recently?

Uh, hands up. Okay. Yeah. So, long story short, $1.5 billion, biggest hack that's ever happened.

Um, and do you guys think that this required compromising like 10 layers of the operating system and like advanced uh technology and like years of like zero days research and vulnerabilities and uh you know massive resources. Um, actually the massive resources were deployed on the moneyaundering side like the actual hack was a little bit of JavaScript that was injected into the front end. That's that's all it really took because of the way that uh our interfaces work. So we'll we'll see more about that. Um, we already have tools that reduce this attack surface.

So, for example, if you're using something like MetaMask, you don't necessarily trust um what the DAP is doing, right? Uh the DAP proposes a transaction, then MetaMask would show you what you're about to sign and then you sign it. So, that's great. Like that reduces the attack surface. And if you're using a secure signing device, then that attack reduces the attack surface even more.

Um so, now you just trust your secure signing device, its supply chain, and so on. But this is only as secure as what your signing device shows. If your signing device shows some gibberish and you hit agree, your signing device is not really like you haven't really eliminated all those threats that we were looking at. like you're still vulnerable and in the case of bybit we don't know the details of what signing devices they were using or so on but we do know that uh a secure signing device didn't really save them. So let's see why.

Thanks. Thanks Victor. So um so let's um let's look at the usability of the of the signing devices. Um so we have already talked about that the signing device is the is the most important part but there are multiple ways to implement um user interactions. Um, most wallets support some built-in mechanisms uh that I'm putting over here as known transactions like your your wallet just knows how to do a withdrawal uh how to do a transfer of ERC20 tokens or NFTs or whatever you can restrict that input.

However, if you're taking a input from a DAP, you have to you have to really start looking at what what you can actually show. And more often than not, what we actually end up in is what I call fallback here, which is uh just showing the hexadimal for for the user. Um and I'll go into this uh um in uh in further slides, but uh keep this picture in in mind where the every wallet is essentially doing this kind of parsing uh making some visual representation and then uh and then deciding whether it can sign or not. I want to show an example of the Anchorage wallet itself uh where we have integrated transactions like withdraw, staking, vote, etc. which are just built in.

We we just need to know what token you are trying to transfer, how much you are going to transfer. We don't need to trust a any other source. Uh we have eliminated the we have reduced drastically the supply chain risks here. However, uh this is a a fairly early version of what we built for parsing unis swap transactions and unis swap gets very very complex where you you are looking at a transaction bunch of call data that you have to interpret and most most browsers uh most wallets don't really do a great job of of parsing that and we have we have a couple of ideas here. So let's start from the bottom where what do most browsers do?

Um so this is another example once again from from the by bit hack uh from research done by NCC group on on the deep dive. Um I have this hexadimal um string on in red. Does that look kind of familiar to any any anybody here? Like does this does this look like some some string you have seen in the past or when you're signing a transaction? Okay.

Um, yeah. No, for for DAP developers in in particular. Okay. So, this is this is what the users um saw and and if you've stared at enough uh transactions, the the first prefix these four bytes looks like a transfer. Um, but just for just for fun, I I put it into the four byte uh directory which lets you do a reverse lookup.

and that there are already bunch of collisions um even for one of the most common uh commonly used uh methods inside Ethereum. So this is not exactly what got compromised but the idea is that we cannot really rely on our muscle memory or hunch to determine that something is safe just because we have seen this multiple times it's very easy to to to get uh mistaken. Um so we have tried to build standards for this. Um EIP712 is is one of those standards which is getting widely adopted. Um which allows you to define what your inputs are supposed to be and uh and sign um sign a a string message itself in a in a structured way.

And this is from the spec where it's very clear you're trying to interact with a with a mail contract and Alice wants to send Bob a message and it's a nice human friendly readable way. In concept, you know, in theory it it works uh really well. But going back to the the Bybit hack, this is what um if they were using uh MetaMask, this is what they would have seen as an endorsement where we are back to um where we are back to the same uh same string over here that they have to interpret. Um and and it was so hard for us to even know that like what that what those four bytes were. How how hard do you think it would be to to parse that you are actually sending 1.

5 billion um in in ETH or $10 in ETH when it's when it's uh presented to you in a UN 256 um string. So it it becomes really really hard in in practice even though in theory uh EIP712 should work. What is the next alternative? Um there are AIS that stand for application binary um interface and every contract has one. Um and they may usually most popular ones are uh deployed on on etherscan but you may not even know uh whether that is the implementation of that address.

It could be a proxy contract and at that point you don't know what kind of proxy contract it is. Um then once um so here's another example of a of a contract which is a 1 in aggregator. Um and over here like all these fields um have some name to them. So it's called uno swap their source token amount min return. And when I get to over here it's an array of byte 32 and I don't know what this means.

You have to read the source code and when you read the source code it actually says it's a it's a list of call data for unis swap v2. But by just looking at AI, um users don't have a way to know what they are actually signing for. Who actually does know know this? It's the DAP developers. Uh because they're writing this DAP, they have some interaction in mind.

They have a user in mind. Um and we need to find a way for the DAP developers to be able to share this information in a way that wallets can actually interpret. There have been uh newer standards um u proposed um ERC 7730 in particular by by ledger which extends on this on the same idea which is take something like EIP EIP712 which lets you this add the signing message and add some additional context to it. Here's a display format uh that you want to use and they're currently using on on their on their hardware wallet over here. However, this is a very new standard and it doesn't support all interaction types.

Uh, namely metat transactions, user operations which are really crucial for the growth of Ethereum are not supported by this standard yet. It's very new. Not all DAPs have adopted this uh this standard. And also wallets, we only know one wallet that that really ships uh which is ledger. Um, and that that really only leaves you with uh doing per DAP custom parsing, right?

Um, I wanted I could go for a long time for for many different contracts, but I wanted to show a very popular contract with Ethere uh with unis swap universal router where even to parse a basic swap, you have to really understand how the first eight bytes of your command are are laid out and and then you you interpret that and that is like that is custom. Um, and you see that pattern a lot. Um which means each uint 256 needs to be parsed very very differently uh to understand. All right. So we just saw all these different ways to parse inputs.

Um we're basically all implementing this the same kind of stuff in wallets. Uh and this is a general architecture of a wallet, right? uh we have the um parsing of the input turns it into some sort of visual representation to show to the user and sign it. So how do we do better at that little parsing piece that everyone has to do? Well, if you guys are DAP developers, there are things you can do to make your uh your DAP more likely to uh work out like to look better in those screens.

You can start by making sure your AI is uploaded to ether scan, right? Like that's really important because we don't even know what is going on without having an AI. Um, you can improve your AI. You can make it easier for a human to understand your method names uh the inputs to those uh methods. And there are trade-offs there.

I know that you might want to optimize for, you know, low uh gas costs or other things. Um but do consider the risk that if no one can understand what's going on then uh you know that could lead to some bad outcomes. Uh of course using EIP712 very very good idea using uh contributing to the ERC 7730 registry also really helps. So, anything you guys can do to make those DAPs um more likely to be shown by wallets well is is a good idea. Um I I would say like testing some wallets would help um just to get a sense, but there are so many out there so it's a little bit difficult.

That being said, like on the wallet side, we should make sure we implement all those standards. Like these standards are good. They really help. um they're not implemented everywhere equally and every wallet is doing things a little bit differently. So actually we want to encourage wallet developers to start working together a little bit more as well.

Like we want uh like anyone that's working on a wallet to actually get in touch with us. We set up a telegram group for you guys to join uh also talk to us after the talk. Um, and we want to start some collaboration here because I don't want us to be competing for who's going to get hacked more or who's going to get hacked less. We should all have clear interfaces and we should work together to build this up. The security of our wallets is only as good as those UIs.

Even after we've solved all the hard like all the hard security problems, we've fixed all the bugs, we've done all the those things, we don't want to end up in a situation where people are just blind signing and all of that was for nothing. So that's why you guys should talk to us. We'll try to coordinate some things. We have some ideas in mind already that we can't like share publicly yet. We need to refine them.

Uh so it is a little bit of a uh early um but I think it's a great time because of the bybit hack because of all the things that are going on in the industry um we should start that collaboration now so talk to us. Thank you. [Applause] All right we have some time for questions. Hey Sorry. Uh first of all great talk and um so I have a security background.

I used to be a security auditor and I was looking into this like so you know just first of all really really great talk uh really in depth. Uh what I'm thinking I'm finding challenging especially on the bybit hack one because I think it was trying to fake a transfer right and then in one of the arguments was like pointed as one which is being becoming a delegate call and kind of coming back to this actually is that I I'm wondering how you're thinking of showing the meaning of the arguments. I think that's really challenging like the interface we can define and then kind of like agree I I can imagine that's being like achievable like through collaborations of course etc. But the meaning of the arguments like especially the one I just mentioned that's like ah pretty tough and wonder if you guys have thought like any thoughts on that. Yeah.

Um actually do do you are you already familiar with uh ERC 7730? uh 7730. I don't think so. Okay. Yeah, that's the one that uh we mentioned earlier.

So, uh with ERC 7730, we have a way to like there's a way to add additional information about what the arguments mean in addition to just like what their names are, right? So, you can say like this is this type of like address. Maybe this address represents this or that. like you you can add additional information there. So that's that's one aspect.

Um but there's another thing to consider like in addition to all the stuff that the wallets are doing in a sort of verifiable and provable way. Uh there's transaction simulation which can be really helpful. Um, and that's a little bit of a different threat model. Like your hardware wallet by itself can't determine what the expected outcome of a transaction is, but you can run that simulation in, you know, in your back end and then show it to the user uh to add to the like what they can see in a verifiable way as well. Yeah, I totally agree on that because uh when I was experimenting with this, I was doing on the transaction simulation side and then I found out that the transaction simulation because it's too technical for users as well and then there is like work you need to do to make it simpler so that user can like ah some weird things are happening etc.

Yeah. So, so there is like the one one of the things we we think about a lot is that what is happening or or what is going to happen on the on chain like whether you derived it by simulating or by interpreting. The key thing to know is like whether it translates to what a user intends to do, right? So, if the simulation ran and then it shows like your these amounts the token amounts don't match, right? your um th that can be another layer of like showing what is like the most important thing you care about for this transaction.

Um in in this case it was tokens but in some other case it could be a governance vote where you want to vote yes but somebody changes it to no or something like that. And so we really need to figure out um what is the key thing that we actually want to display um and whether it's simulation or through parsing like we we want to uh make that very prominent for the user so that they can make that uh make make that decision uh very clearly like just showing more data doesn't really help if if it's just noise again. Yeah. Thank you. Cool.

Any more questions? Do you want to go back to the slide where with the telegram group? Seems really nice that there's this intimate opportunity that everyone can participate. It's really nice. All right, last questions.

If not then thanks to Persona and Victor. I think saber signing means saber crypto. I love to say it. Thank you. Thank you.

[Music]

Automatic transcript — names and jargon may be misspelled.