The largest crypto theft in history, a $1.5 billion drain from Bybit's Ethereum cold wallet, wasn't a zero-day exploit or a private key compromise. It was approved by multiple authorized signers holding hardware wallets, who simply didn't know what they were approving. This exact pattern, known as blind signing, also hit Radiant Capital for $50M and Drift Protocol. On May 12, 2026, the Ethereum Foundation and a multi-vendor working group launched Clear Signing, an open standard designed to eliminate this vulnerability. If you're building on Ethereum, writing Solidity, or shipping dApps, this is the most critical security infrastructure change you need to understand this year.
What Does Blind Signing Look Like on a Hardware Wallet?
When you authorize a transaction on a hardware wallet, the device receives raw calldata — a hex string — and asks for confirmation.
Here's a snippet of what a Safe multisig wrapping an Aave v3 supply of 1 USDC looks like on a hardware wallet today:
0x6a76120200000000000000000000000087870bca3f3fd6335c3f4ce8392d69350b4fa4e2
00000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000001400000000000
... (continues for hundreds of bytes)
To interpret this, a user must:
- Parse the four-byte function selector.
- Look up the function name from the contract's ABI.
- Decode each parameter against ABI types.
- Resolve token addresses and ENS names.
- Reason about the call's actual effect given the contract's state.
A skilled engineer can perform these steps with tools, given time, on a workstation. A multisig signer under pressure on a three-line OLED display cannot.
The industry's initial response was to replace hex with more readable phrases like "Send 100 USDC to vitalik.eth". Making that version safe, rather than just user-friendly, is far more complex than it appears.
Why Isn't ABI Decoding Enough to Prevent Blind Signing?
You might believe the ABI solves this. Given the ABI, you can decode bytes into execTransaction(0x87870Bca..., 0, 0x617ba037..., ...) and display each parameter.
This approach remains flawed for two key reasons:
1. Function names can mislead
Solidity allows developers to name functions arbitrarily. A contract could name:
- A withdrawal function
deposit - A malicious upgrade
pause - A fund-extraction routine
claimRewards
If your wallet trusts the function name to infer intent, any contract deployer can define any intent for your wallet to display.
2. Parameters lack semantic context
A uint256 amount is merely a number. Is it:
- Wei?
- Micro-USDC with 6 decimals?
- A timestamp?
- A duration in seconds?
- A basis-point fee?
Without protocol-specific knowledge, "amount: 1000000" is merely less alarming hex. ABIs provide types, not semantics.
ABI decoding offers a more readable version of the hex. It does not provide a truthful version. This distinction is what led to the Bybit and Radiant Capital thefts.
How Does the Clear Signing Stack Actually Work?
Clear Signing is not a monolithic project. It comprises four interconnected infrastructure components:
1. ERC-7730: Human-Readable Descriptors
ERC-7730, originated by Ledger and standardized by a multi-vendor group, defines a JSON descriptor format. This format maps contract functions to human-readable intents and field-rendering instructions.
Here's a descriptor entry for USDC's transfer function:
{
"transfer(address to,uint256 value)": {
"intent": "Send",
"fields": [
{ "path": "to", "label": "To", "format": "addressName" },
{ "path": "value", "label": "Amount", "format": "tokenAmount" }
]
}
}
With this descriptor, a wallet knows that when transfer is called on USDC, it should display "Send {amount} to {recipient}". It also knows to format the amount with 6 decimals and the USDC ticker, and to resolve the recipient to an ENS name if available.
Descriptors are:
- Curated by protocol teams
- Reviewed by third-party auditors
- Collected in a neutral registry hosted by the Ethereum Foundation
- Wallets determine which attestations they trust
2. ERC-8176: Attestation Framework
A descriptor is only valuable if it is correct. ERC-8176 provides an attestation framework built on the Ethereum Attestation Service (EAS).
Independent auditors attest that a descriptor accurately represents the contract it describes. Wallets retrieve descriptors from the registry and decide which attestations to trust. If a security firm like Cyfrin has audited and attested a descriptor, wallets can display that trust signal to users.
3. ERC-8213: Cryptographic Fallback for Everything Else
Descriptors exist only for contracts for which someone has authored one. What about new contracts, custom packed encodings (e.g., Safe MultiSend, Uniswap Universal Router), or zkSync L1↔L2 system messages?
ERC-8213, authored by Cyfrin, defines short, reproducible cryptographic fingerprints of exactly what is about to be signed:
keccak256(uint256(len(calldata)) || calldata)
This is a length-prefixed hash of the exact bytes that will interact with the contract. The primary use case is cross-device verification: before signing on a hardware wallet, the signer computes the same digest on an isolated machine. If the digests match, the bytes are correct. If they differ, something has been substituted between the front-end and the device, which is precisely the attack vector that drained Bybit and Radiant.
ERC-8213 covers:
- Calldata digests
- EIP-712 domain/message/final hashes
- Safe-specific signing hashes
Keycard Shell is the first wallet to implement this, displaying the calldata digest alongside the ABI-decoded view during signing.
4. Developer SDKs and Tooling
The working group has released official SDKs in Rust and TypeScript, along with Cyfrin's open-source clearsig for Python.
You can install it:
uv tool install clearsig
# or
pipx install clearsig
To translate a transaction:
clearsig translate \
0x6a76120200000000000000000000000087870bca3f3fd6335c3f4ce8392d69350b4fa4e2... \
--to 0x41675C099F32341bf84BFc5382aF534df5C7461a \
--chain-id 1 \
--from-address 0x9467919138E36f0252886519f34a0f8016dDb3a3
The output will be:
Intent: sign multisig operation (Safe{Wallet})
Function: execTransaction(address,uint256,bytes,uint8,uint256,uint256,uint256,address,address,bytes)
Operation type: Call
From Safe: 0x41675C099F32341bf84BFc5382aF534df5C7461a
Execution signer: 0x9467919138e36f0252886519f34a0f8016ddb3a3
Transaction: Supply (Aave DAO)
-> supply(address,uint256,address,uint16)
Amount to supply: 1000000
Collateral recipient: 0x9467919138e36f0252886519f34a0f8016ddb3a3
Compare this to the raw hex string shown earlier. This is what WYSIWYS (What You See Is What You Sign) truly means.
Other clearsig CLI commands include:
# What digest will my hardware wallet show?
clearsig calldata-digest <calldata>
# EIP-712 typed data hashes
clearsig eip712 message.json
# Safe transaction hashes (offline)
clearsig safe-hash --chain-id 1 --safe-address 0x... --safe-version 1.4.1
# Bootstrap a starter descriptor from a verified ABI
clearsig generate --chain-id 1 --to 0x... --owner USDC
# Function selector primitives
clearsig sig "approve(address,uint256)" # → 0x095ea7b3
All functions, except the 4byte reverse-lookup, run entirely offline against a local copy of the registry. This is crucial for air-gapped security workflows.
What Does Clear Signing Mean for Developers?
If you write Solidity or deploy contracts
Publish a descriptor for your contracts. Without one, users revert to blind signing. The clearsig generate command can bootstrap a starter descriptor from Sourcify's verified ABIs, automatically traversing proxies to the implementation contract.
clearsig generate --chain-id 1 --to 0xYourContract --owner YourProject
Refine the intents and labels manually, then submit to the ERC-7730 registry.
If you build wallets
Integrate the SDKs available today. The Rust and TypeScript libraries are production-ready. Make blind signing the exception, rather than the default.
If you audit smart contracts
Attest descriptors. An incorrect descriptor can make a malicious transaction appear benign. The auditor workflow is documented, and ERC-8176 attestations are posted on EAS.
If you are a security-conscious signer
Stop signing transactions you cannot read. When stakes are high, verify with a second device. clearsig translate and clearsig calldata-digest are specifically designed for this workflow.
What Are the Remaining Challenges for Clear Signing?
The working group acknowledges two honest limitations:
1. Descriptors are not instant
If a contract is not yet in the registry, human-readable rendering is unavailable, and you are back to ABI decoding or hex. Inclusion requires a PR, an auditor review, and ecosystem consensus. ERC-8213 provides a fallback during this period, but it is not a replacement for comprehensive descriptor coverage.
2. Air-gapped wallets need a transport solution
Air-gapping a hardware wallet offers a strong security posture. However, pulling a large, frequently updated registry onto an air-gapped device is challenging. The working group is developing a Wire Protocol to address this, which is not yet live.
How Does Clear Signing Follow the "Don't Trust, Verify" Philosophy?
Clear Signing embodies a fundamental architectural principle shared with leading security tools: eliminate blind trust.
This philosophy aligns with zero-knowledge password managers like VaultKeepR, where the server never sees plaintext passwords. Encryption occurs on-device using Argon2id + XChaCha20-Poly1305 before any data is transmitted. No account, no email, no trusted server. It's the same "don't trust, verify" ethos that drives security research into vulnerabilities like CVE-2026-26007, where cryptographic assumptions are stress-tested to the breaking point.
The Bybit attackers did not break cryptography. They exploited the discrepancy between what users saw and what machines executed. Closing this gap with ERC-7730 descriptors, attestations, and cryptographic fingerprints is the essence of "What You See Is What You Sign."
The $1.5 billion question is not whether the next exploit will stem from a smart contract bug, but whether the human at the last line of defense can actually read what they are approving.