Patrick Collins
2026 May 12

Blind signing is finally getting solved

For the past few years, the number one problem in this industry has been blind signing. More important than smart contract security reviews, more important than re-entrancy. And today, we finally have a solution.

You shouldn't be signing things you can't read

You shouldn't be signing things you can't read

Embedded content

The video version of this post, if you'd rather watch than read. If you'd rather read the formal writeup my team did, we put one on the Cyfrin blog.

The problem

Look at this:

0x6a76120200000000000000000000000087870bca3f3fd6335c3f4ce8392d69350b4fa4e2
0000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000014... (and 18 more pages of this)

When signing a transaction, you need to make sure every character of your calldata is correct.

But you don't. I know you don't. And you have no idea what the calldata does.

And you'll sign it anyways.

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 for a while 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 — link to that one here if you want the background.

And yes, blind signing is part of the cause of some of the largest hacks we've ever seen:

The list goes on and on.

Trezor’s framing of the problem vs. the solution

Trezor’s framing of the problem vs. the solution. Never again approve something you don’t understand.

And today, we finally have a solution. It's a two-parter: one for both technical and non-technical people, and one that's technical-people-only.

Let me explain.

Part 1: ERC-7730 (for everyone)

The first and most important one is ERC-7730.

Originally proposed by the Ledger team, this ERC introduces a registry — basically a list of conversions of huge blocks of calldata into human-readable descriptors right on your hardware wallet.

Instead of looking at 18 pages of random hex with an "approve, buddy?" button at the bottom, you get something that looks like this:

How ERC-7730 solves it

Blind signing on the left, clear signing on the right. Same transaction.

This is incredibly important because now you can actually check: am I signing what I want to sign?

The other side of this: if you see a bunch of garbled hex on your device, and you don't know how to translate that into English — do not sign it.

But now, if you can read the English on your wallet and understand it — you can be non-technical and interact with DeFi. I now give you my blessing.

How the flow works

  1. Protocol deploys on chain
  2. They make a pull request to the registry describing how to translate their garble of hex into English (or some other language)
  3. A group of independent third-party descriptor auditors — like Cyfrin — review to make sure it's actually correct
  4. Wallets download this data to show the translation from calldata to human-readable text

A massive UX improvement, and a massive round of applause to the Ethereum Trillion Dollar Security Initiative, the Ledger team for originally proposing this, and the full working group: Trezor, MetaMask, WalletConnect, Keycard, ZKnox, Blockaid, Fireblocks, Zama, Sourcify, Argot, and Cyfrin.

clearsigning.org

clearsigning.org — the open standard for human-readable transaction signing.

So we did it. Clear signing is solved.

But of course, this is a security and tech channel blog. So I'm also going to explain to you some of the limitations of this ERC, and why we put forward an additional ERC to cover the scenarios that 7730 can't.

The two biggest limitations are:

  1. If your project isn't in the registry, you cannot have clear signing. And it can be slow to get included.
  2. For air-gapped hardware wallets, downloading all this registry data is difficult.

So I just said it's solved, but in fact, we're cooked.

…not quite.

Part 2: ERC-8213 (for technical people)

For the first issue — projects not yet in the registry — we're going to see how it unfolds. Many projects won't be able to get in at the speed they'd like. So Cyfrin authored ERC-8213.

The idea: take those 18 pages of calldata, hash it into what's called the calldata digest, and display that on your hardware wallet.

keccak256(uint256(len(calldata)) || calldata)

Instead of having to verify 18 pages of calldata, you just have to verify a single hash. You locally compute what the digest should be, and you compare that to what you see on your hardware wallet.

This drastically cuts down the tedious work of verifying calldata. It's actually quite similar to what you already do with EIP-712 — get the digest, compare it to what you expect.

Now, non-technical people, on this one you're still kind of screwed — if you don't know how to compute the hash, you can't do this. ERC-8213 is for technical people and security researchers who want to interact with protocols that aren't 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.

The teaching site

To explain more, we built erc8213.eth.limo — which also tracks wallets that have implemented it.

erc8213.eth.limo

erc8213.eth.limo — what your wallet shows you today vs. what ERC-8213 asks for: 32 bytes, independently reproducible.

It also has a live verify tool so you can paste in your typed data or calldata and compute the expected digest right there:

ERC-8213 verify tool

EIP-712 digest verification on the same site. Paste in. Compare against the hardware wallet. Done.

And oh my goodness — there is already a wallet on the market that has it: Keycard Shell.

Keycard

If you are a nerd like me and you use this wallet, you can easily verify your calldata in a single hash instead of 18 pages. An absolute round of applause to the Keycard Shell team for being the first to implement ERC-8213.

The Keycard Shell already did a great job of including both the ABI and the calldata digest. Now you just check the digest.

To compute your own to compare against, use:

clearsig calldata-digest <calldata>

clearsig — all the tools in one place

We've built a number of tools throughout the years to help with clear signing. Just this week, the Cyfrin team combined all of them into a single CLI: clearsig.

clearsig on GitHub

github.com/Cyfrin/clearsig — MIT-licensed, runs offline against a local copy of the registry.

# What does this calldata mean? (ERC-7730 translation)
clearsig translate <calldata> --to <address> --chain-id 1

# What digest will my hardware wallet display? (ERC-8213)
clearsig calldata-digest <calldata>

# EIP-712 typed data — domain, message, and final hash
clearsig eip712 message.json

# Safe transaction hashes (offline) — matches safe-hash-rs byte-for-byte
clearsig safe-hash --chain-id 1 --safe-address 0x... --safe-version 1.4.1 ...

# Hash an ERC-7730 descriptor for ERC-8176 attestations
clearsig descriptor-hash registry/<project>/<descriptor>.json

# Bootstrap a starter descriptor for a new contract from Sourcify
clearsig generate --chain-id 1 --to 0x... --owner USDC

Install with whichever Python tool you prefer:

uv tool install clearsig          # or pipx / pip

Everything runs offline against a local copy of the registry. The hashing is cross-checked byte-for-byte against viem for EIP-712 and safe-hash-rs for Safe hashes, so what clearsig produces is what the rest of the ecosystem agrees on.

And if you're using MetaMask, we have the Wise Signer Snap, which we're going to update with ERC-8213 support very soon.

Wise Signer Snap

The air-gapped problem (and how it gets fixed)

The second issue with 7730 is the extra dependency it introduces 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 accidentally getting downloaded into your hardware wallet. That's why air-gapping them is so fantastic.

But the registry is a lot of data that lives online. And it's going to get updated often. So:

Don't worry — the 7730 group is working on a solution called the Wire Protocol. It is not live yet, but it's coming.

You might ask: OK, how does a wallet like Ledger support 7730? Ledger is also air-gapped, right?

7730 will work with your Ledger going through the Ledger wallet application — so there's still a transport layer there. I expect that as time progresses, this transport gets easier and easier.

To be quite frank with you: if your hardware wallet doesn't implement these types of features to enable clear signing for you, you should consider switching.

"Why not just trust the ABI?"

A couple more questions for the nerds in the room.

Wallets like 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, here's a Uniswap swap decoded purely from the ABI:

Uniswap Universal Router decoded with the ABI alone

Uniswap Universal Router calldata, fully ABI-decoded. Still basically unreadable.

In the 7730 spec, you could easily render this as: "Swap asset A for asset B" — boom, much more readable.

There's also an argument that you can't even trust the ABI — function names are whatever the developer says they are. But that's a whole other conversation.

"What happens when transactions get too complex?"

The next thing for you to think about: what happens in the future when transactions get so complex that instead of 18 pages of calldata, we get 18 pages of English? Some bizarre on-chain terms-of-service.

Do you want to start blind signing again because you don't want to read the 18 pages?

…I don't know. We'll cross that bridge when we come to it.

Why Cyfrin is the right team to be here

I want to emphasize: this took a lot of coordination from a lot of teams.

The registry is hosted in the Ethereum Foundation's org — an incredibly neutral third party. And we have independent third-party descriptor auditors like Cyfrin in the loop.

Cyfrin does not have a hardware wallet. We have no horse in this race, which feels phenomenal. We're a team of independent third-party auditors helping go through these descriptors, and we now have coordination on how to convert calldata into human-readable text so you can actually know what you're signing.

Your action items

Number one — non-technical people:

You should no longer sign transactions without a human-readable edition of what you're signing.

Because again — you are one compromised website away from losing all your funds.

Number two — technical people:

If your hardware wallet does not support ERC-8213, you should consider switching. Because as a technical person, there are going to be a lot of transactions you have to sign that aren't yet in the registry. You need a way to validate that the calldata you're signing is what you intend to sign.

Number three — Web3 community:

Please do not blind sign.

Resources

Remember to stay froggy.

For more amazing blockchain content, follow me on YouTube and X.

And be sure to follow the Cyfrin team!