Patrick AlphaC effectively demonstrates how ERC-7730 and ERC-8213 solve the multi-billion dollar problem of blind signing by making transactions human-readable. These standards are the necessary bridge from blind trust to true verification in Web3 security.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
You can SEE what you sign now?? | ERC-7730, 8213, and Clear SigningAdded:
I mean, honestly, look at this.
We'll make sure every single one of these characters is correct. We'll get this to show up on your hardware wallet without any clue what it does, and you'll sign it anyways. And [music] you'll sign it anyways.
For the past few years, the number one problem in this industry has been blind signing. More important than smart contract security reviews, one-of-one DVN setups, more important than re-entrancy, and today we finally have a solution. Your hardware wallet is your gateway to crypto. And if you don't understand how to walk through that gateway, you are signing yourself up for a world of pain.
I have had the hot take that only developers and security researchers should interact with DeFi because they're the only ones who can actually understand what's on their hardware wallets. I explained this problem in very funny, very good depth a full year ago. If you want to watch that video to understand this problem of blind signing more, link in the description. And yes, blind signing is part of the cause of some of the largest hacks we have ever seen in this industry. The Bybit hack, 1.4 billion dollars. Drift Protocol, a little less than 200 million. Radiant Capital, 50 million. The list goes on and on. And today, we finally have a solution. And it's a two-parter. We have a solution for both technical and non-technical people, and then we have a technical people only solution. Let me explain. So, the first and most important one is introducing ERC-7730.
Originally proposed by the Ledger team, this ERC introduces a registry that is basically a list of conversions of huge blocks of call data to human-readable descriptors right on your hardware wallet. This way, instead of looking at 18 pages of this random hex data, approve that, buddy, you get something that looks like this. This is incredibly important because now you can actually check, am I signing what I want to sign?
And this means that if you see a bunch of garbled hex on your device and you do not know how to translate that to English, don't sign it.
Sign it.
Go on.
And now you can be non-technical and interact with DeFi. I now give you my blessing. If you can read this English and understand it, you can now interact with DeFi. The flow works like this.
Protocol deploys on chain, they make a pull request to this registry describing how to translate their garble of hex to English or some other language. A group of independent third-party descriptor auditors, like Cypherium, review to make sure that it is actually correct.
Wallets can then download this data to show this translation from [music] call data to human readable text. So we can finally go from this to this.
This is a massive UX improvement and a massive round of applause should be given to the Ethereum trillion-dollar security initiative, the Ledger team for originally proposing this, and then the full working group of Trezor, MetaMask, WalletConnect, KeepKey, ZenGo, Blockade, Fireblocks, Dharma, Source Hat, Argent, and then finally Cypherium. So we did it. Clear signing is finally solved. But of course, this is a security and tech channel. So I'm also going to explain to you some of the limitations this ERC has and why we actually put forward an additional ERC to cover the scenarios that this ERC does not cover. The two biggest limitations to this ERC are number one, if your project is not in the registry, you cannot have clear signing and it can be slow to get your project included.
And number two, for air-gapped hardware wallets, downloading all this data in this registry can be difficult. So I just said it's solved, but in fact, we're cooked. Not quite. So for the first issue, we're obviously going to see how it unfolds, how quickly projects can be included in this registry. But many projects will not be able to get included at the speed that they would like. This is why Cypherium authored ERC 8213.
And with this ERC, you take this 18 pages of call data, you hash it into what's called the call data digest and you display that to the user on hardware wallet. This way, instead of having to verify 18 pages of call data, you just have to verify a single hash. So, you locally compute what your expected hash should be and you compare that to what you see on your hardware wallet. This drastically cuts down the amount of tedious work it takes to verify your call data. And this is actually quite similar to what you already do with EIP-712 signatures. You get the EIP-712 digest and you compare that to what you expect. Now, non-technical people, you're still kind of screwed because if you do not know how to do this translation, you can't work with it. So, yes, this is a solution specifically for technical people and security researchers who want to interact with these protocols that are not included in the registry. But, for me, as somebody who can do this, I can now verify anything I sign almost instantly. And that makes me very happy.
To explain more about this ERC, we made this website, which also shows a list of wallets that have implemented this and oh my goodness, there is a wallet on the market that already implements this ERC.
So, if you are a nerd like me and you use this wallet, you can easily verify your call data in a single hash instead of 18 pages. An absolute round of applause to the Keycard Shell for being the first ones to implement ERC-8213.
[cheering] And here's how it works. So, normally, the Keycard Shell does a great job of actually including both the ABI and then also the data hash or as defined in the ERC, the call data digest. And now, instead of 18 pages, this is all you need to verify. To then locally compute your call data digest, you could use our ClearSig tool and calculate the call data and pop that into ClearSig call data digest and paste in the call data to get the resulting digest or the resulting hash and compare that to what you see on your hardware wallet. even further, we built a number of tools throughout the years to help with clear signing, help users validate what they're signing. And just this week, the Cipher team combined all these tools into a single CLI tool called Clear Sig, which allows you to validate any type of clear signing you would need on a hardware wallet. And if you're using MetaMask, we have the Wise Signer Snap, which we're going to update with ERC-8213 support very soon. So, we've solved the issues of 7730 for technical people.
Unfortunately, for non-technical people, you're kind of still screwed. Now, the second biggest issue with 7730 is that it does in introduce this extra difficult dependency for air-gapped hardware wallets. Air-gapped hardware wallets are phenomenal. They do this on purpose for extra security. You do not want random firmware being accidentally downloaded into your hardware wallet.
And that's why air-gapping them is so fantastic. This registry is a lot of data that lives online. So, you would need to download that into your hardware wallet very often because this registry will get updated very often. This creates a challenge. How do you connect it to the registry? Can the hardware wallet support or hold all that data and do the compute needed cuz they're intentionally storage and compute restricted as well for security? But don't worry, 7730 is working on a solution for this too called the Wire Protocol. It is not live yet, but it is coming soon so that air-gapped wallets can support this in the future. So, question you might ask is, "Okay, how does a wallet like Ledger support 7730?" Because Ledger is also air-gapped, right? 7730 will work with your Ledger wallet going through the Ledger wallet application. So, there's still a transport layer there, but I expect as time progresses, this transport will get easier and easier of the registry. And to be quite frank with you, if your hardware wallets don't implement these types of features to enable clear signing for you, you should consider switching. Now, before I go, I want to leave you with a couple more questions because again, we're nerds here. The first one is, "Why not just trust the ABI?" Wallets like the keycard shell, Keystone, and Grid Lattice Plus have all historically used ABIs. ABIs are a great tool for very simple transactions, but when transactions get more complicated, it kind of falls apart. For example, if you're doing a Uniswap swap, here is what the call data decoded using the ABI looks like. It's basically still unreadable. In the 7730 spec, you could easily just make this Oh, you're swapping asset A for asset B.
Boom. That is much more readable than using the ABI. There's also some argument of you can't trust the ABI, but that's a whole other conversation. The next thing for you to think about is what happens in the future when transactions get so complex that instead of 18 pages of call data, we get 18 pages of English, which turns into this bizarre terms of service. Do people again start blind signing because they don't want to read the 18 pages?
I don't know. We'll cross that bridge when we come to it. And I want to just emphasize that this took a lot of coordination from a lot of teams to get this to where it is. The registry is an incredibly neutral third party is in the Ethereum orgs repo. We have independent third-party auditors like Saffron who We don't have a hardware wallet. We have no horse in this race, which feels phenomenal. We have these third-party independent auditors who are going to be going through these descriptors, and we finally have some coordination on how to convert your call data into human-readable text so that you can sign things and actually know what you're signing. Here are your action items.
Number one, if you are non-technical, you should no longer sign transactions without a human-readable addition of what you're signing. Because again, you are one compromised website away from losing all your funds. Number two, for technical people, if your hardware wallet does not support 8213, you should consider switching.
Because as a technical person, there will probably be a lot of transactions that you have to sign that are not in the registry, and you need a way to validate the call data that you are signing is what you intend to sign. And now, Web3 community, please do not blind sign. Remember to stay froggy.
Related Videos
Are our DeFi tools becoming too easy to exploit?
saidotfun
228 views•2026-05-30
Solana Unchained ($UCHN) Explained: Solana’s Next Big Utility Project?
CryptoVlogOfficial
339 views•2026-05-30
🚨 Access Network App FREE Withdrawal to MetaMask?! Only 25M Supply 🔥
Airdrop26Alpha
459 views•2026-05-28
Free TON in 2026? How I Tested This Reddit TON Tool
SirenHead-z9y
2K views•2026-05-28
⚠️ALGO Has a Very Bright Future! ✅ One #Crypto Everyone Should Own!
MetaShackle
184 views•2026-05-30
BingX EventX: Trade Sports, Crypto & Global Events With One Click
AidenCryptox
311 views•2026-05-31
XRP IS GOING TO VANISH! A SUPPLY SHOCK IS INEVITABLE! (THIS IS THE PROOF!)
NCash
2K views•2026-05-31
AI Predicts What XRP Looks Like If Ripple Gets A Fed Master Account
CryptoBlazon
422 views•2026-05-30











