If you use a hardware wallet alongside Base, you have probably run into a message that stops you cold: a warning telling you to enable blind signing before a transaction will proceed. It sounds like a security downgrade, and in a narrow sense it is, but understanding what the setting actually controls makes it much less mysterious. This guide builds on our hardware wallet setup guide and our EIP-712 explainer, and goes one level deeper into what your device can and cannot show you.
What your device is trying to do
A hardware wallet's screen is small and its processor is simple by design, on purpose, since that simplicity is part of what keeps your private key safe. When your wallet app asks the device to sign a transaction, it hands over the raw data for that transaction. The device's job is to turn that data into something you can actually read before you approve it with a button press.
For a plain transfer, this is easy. The device knows the format: a destination address and an amount. It displays both, you check them, you approve. The problem shows up with smart contract interactions, which make up most of what happens on Base. A swap, a lending deposit, an NFT mint, a permit approval, each of these calls a contract function with its own custom arguments, encoded as a blob of bytes the device has no built in way to interpret. Unless the device has been specifically taught what that function's arguments mean, all it can show you is the raw bytes themselves.
The two modes explained
This is the actual difference between the two settings you will encounter:
Blind signing means the device shows you a hash or a string of hexadecimal data instead of readable fields, and asks you to approve it anyway. You are trusting that your computer or phone screen displayed the transaction accurately, without the device itself being able to confirm it. This is exactly the gap our signature requests guide warns about: the on device confirmation is supposed to be the one thing malware on your computer cannot fake, and blind signing removes that check for the specific action you are approving.
Clear signing means the device recognizes the contract function being called and displays it as actual fields, the token, the amount, the recipient, in a form you can read and verify on the device's own trusted screen. This is the same idea our EIP-712 article covers for message signatures, extended to on chain transactions as well.
The reason clear signing is not the default everywhere comes down to coverage. A device can only display a contract call in readable form if someone has told it how, through a small file called a descriptor that maps a specific contract's functions to plain language fields. Well established protocols on Base, like the major decentralized exchanges and lending markets, tend to have these descriptors already. A brand new or less common contract usually does not, and until one exists, your device falls back to blind signing for anything that touches it.
Why this is improving industry wide
For years, each hardware wallet maker maintained its own list of supported contracts, which meant coverage was patchy and slow to expand. That changed with a standard called ERC-7730, first proposed by Ledger, which defines a common descriptor format any wallet can use, not just one brand. In May 2026, Ledger transferred stewardship of the standard and its public descriptor registry to the Ethereum Foundation, specifically to keep it as an open, brand neutral resource that any team can contribute to or build on. The practical effect over time is that more contracts, including ones running on Base, should get readable descriptors faster, since publishing one no longer depends on a single company's roadmap.
What to actually do when you see a blind signing prompt
Treat it as a signal to slow down, not a reason to panic.
- Confirm you meant to interact with this contract at all. If the prompt appears somewhere you did not expect, on a site you were not deliberately using, stop and close the connection rather than approving.
- Cross check the transaction on your phone or computer screen against what you intended to do, since that is the only description you have before you approve.
- Prefer well established Base apps for anything sizable. They are the ones most likely to already have a clear signing descriptor, which gives you the on device verification back.
- Do not leave blind signing enabled by default as a convenience. Most wallets let you toggle it on only when a specific transaction needs it, and off again afterward. Leaving it permanently on removes a safety check for every future transaction, not just the one in front of you.
- Do not treat clear signing as proof a transaction is safe. As our EIP-712 article points out, a phishing contract can present a perfectly readable, perfectly formatted request for the wrong amount or the wrong recipient. Readable is not the same as legitimate. You still have to check that the fields match what you actually intended.
The underlying goal of your hardware wallet has not changed: it is there to make sure the thing you approve is the thing that actually happens on chain. Blind signing is the gap that exists while that verification catches up to every contract in use, and clear signing, spreading through a shared standard rather than one company's list, is how that gap is meant to close.
This is general information, not financial advice.
Sources: Ledger: Enable Blind Signing, Why, When and How to Stay Safe, Ledger Developer Portal: Clear Signing overview, ERC-7730: Structured Data Clear Signing Format, ethereum.org: Add clear signing to your protocol with ERC-7730