Clear Signing: The Last Line of Defense Ethereum Rebuilds

Key Takeaways

• On May 12, 2026, the Ethereum Foundation officially launched the Clear Signing standard. It is a structural attempt to address the long-standing problem of blind signing.
• The standard consists of three main components: ERC-7730, a JSON format that describes transaction intent in human-readable form; ERC-8176, which allows the accuracy of a Descriptor to be cryptographically verified by external parties; and a neutral registry that anyone can mirror. Because descriptors exist off-chain, the standard can be applied to existing contracts without redeployment, as long as wallets implement it.
• However, the standard itself does not guarantee safety. Coverage depends on voluntary participation by the protocols that write descriptors, and the responsibility for deciding which descriptors to trust is also distributed across wallets. UI-layer attacks such as the Bybit hack can only be blocked when verification is performed on the hardware wallet's own screen, and Clear Signing matters precisely because it provides the foundation for displaying genuinely meaningful information on that screen.

1. Signature: Where the Last Line of Defense Falls

1.1 The Bybit and Radiant Capital Cases

The security measures in place at exchanges and protocols are built up in multiple layers. Multisig, hardware wallets, transaction simulation, whitelists, and geographic distribution all form part of this stack. Yet all of these measures only take effect at the final step of a transaction, when a human presses the sign button. The moment when a user verifies what they are signing is the last line of defense in the security system, and the Clear Signing standard discussed in this article is an attempt to rebuild that step.

On February 21, 2025, approximately 400,000 ETH (worth $1.5 billion at the time) was drained from Bybit's cold wallet in a single transaction. It was the largest crypto theft in history, but the starting point of the attack was not a major code vulnerability or a protocol flaw. It was the routine fund transfer procedure of moving assets from the cold wallet to the hot wallet, a process that exchanges repeat daily.

Even if the hot wallet is compromised, moving funds out of the cold wallet requires the multisig signers to personally review the transaction and sign it on a hardware device. In the Bybit incident, however, this very layer collapsed.

The Lazarus Group compromised the developer machine of Safe, the multisig infrastructure provider, in advance and planted malicious JavaScript on the Safe frontend that would activate only when Bybit's cold wallet signers accessed it. The transaction information the signers saw through the Safe interface appeared to be a normal cold-to-hot wallet transfer, but the message actually delivered to and signed by the hardware wallet was one that replaced the cold wallet's contract logic with code under the attacker's control. There was a gap between what the signers saw on screen and what they actually signed, and the hardware wallet could not bridge that gap.

Source: @pcaversaccio

This kind of attack operates on the structural void created by blind signing. Because the hardware wallet cannot display transaction details in a meaningful form on its own screen, the user has no choice but to trust the information shown on the computer's interface. The moment that computer-side interface is tampered with, the last line of defense is immediately neutralized. Signature legibility alone cannot prevent incidents like the Bybit case, but without it, there is little room for any additional layer of defense to function.

Radiant Capital suffered damage through the same mechanism. The Lazarus-affiliated UNC4736 group used social engineering to plant malware on a Radiant developer's machine, intercepting transaction data at the operating system level. The developers verified the transactions through Tenderly simulation and the Safe interface, and the screens displayed normal transactions. However, the payload actually delivered to the Ledger wallet was a call to transferOwnership() that transferred control of Radiant's pool contracts to the attacker. Because Ledger could not parse Safe's transactions on its own, the developers ended up signing what was, in effect, an unreadable transaction.

These cases share the same root: the user signed without knowing what they were signing. Despite nearly every standard security measure being in place, including multisig, hardware wallets, simulation, whitelists, and geographic distribution, a single gap between the user's screen and the actual signed message was enough to neutralize the final line of defense.

1.2 The Same Problem Affects Individual Users

Source: ScamSniffer

The damage caused by blind signing is not limited to exchanges and protocols. The same mechanism is exposed to ordinary users more often and more persistently. A representative example is phishing attacks based on Permit (EIP-2612).

Permit was originally designed to improve user experience. Where the existing ERC-20 standard requires a separate on-chain transaction to approve token transfer permissions, Permit produces the same delegation effect through an off-chain signature alone. It is a standard created for user convenience, requiring no gas and no additional transaction. From an attacker's perspective, however, this convenience can be exploited. By disguising Permit as a simple login signature, attackers trick users into handing over token withdrawal rights without realizing what they are doing.

The core of the problem is that the Permit signature screen conveys almost no meaning to the user. What the wallet displays is the raw structure of an EIP-712 typed message, and it is difficult for an ordinary user to intuitively read from this structure who they are granting permission to, in what amount, and for which token. The same problem exchange signers faced is also occurring for individual users who use dApps every day.

According to the 2025 report from Scam Sniffer, approximately $83.85 million was drained from 106,106 victims through wallet drainer phishing over the course of 2025. Looking only at the 11 cases involving losses of over $1 million, Permit and Permit2 phishing accounted for 38% of the losses (about $8.72 million), remaining the most prevalent attack type. The single largest phishing incident of 2025, which occurred in September (about $6.5 million, involving stETH/aEthWBTC theft), was also an attack carried out through Permit signatures.

Source: Scam Sniffer 2025 Phishing Report

A new variable in 2025 is the emergence of attacks based on EIP-7702. Introduced through the Pectra upgrade, EIP-7702 is an account abstraction standard that allows an EOA to temporarily behave like a contract. Attackers have begun exploiting this to bundle multiple malicious actions into a single signature. Users who believed they were consenting to a single action with one signature were, in fact, approving several delegations bundled together. In August 2025 alone, approximately $2.54 million was stolen through phishing based on EIP-7702 batch signatures.

1.3 Limitations of Existing Alternatives

Source: Scam Sniffer

The most frequently discussed alternatives to blind signing have been transaction simulation and ABI (Application Binary Interface) decoding. These represented progress in terms of user experience and produced real results, but neither has become a reliable line of defense. Simulation is exposed to transaction simulation spoofing, where the time gap between the moment of simulation and the moment of actual execution becomes a new attack vector. The attacker can arrange for the simulation to display an innocuous result such as "Receive N ETH," and then change the contract state values just before the user presses the sign button, so that the transaction actually executed produces an entirely different outcome. ABI decoding likewise only decodes function signatures and cannot explain what those calls mean for the user. Attackers can also deceive wallets by publishing a manipulated ABI for their own contract.

This is why Clear Signing chose descriptors that describe transaction intent, rather than result simulation, as the standard. To break the repetition of the same flaw and the same structure, the screen shown to the user must be based on stable information that is less susceptible to external manipulation.

2. The Structure of Clear Signing

Clear Signing is a standard that combines three elements to structurally bridge this gap: ERC-7730, a human-readable transaction description format; ERC-8176, which allows the integrity of those descriptions to be verified externally; and a neutral descriptor registry that anyone can mirror.

2.1 ERC-7730: A JSON Format for Describing Transaction Intent

ERC-7730 is an EIP first proposed by Ledger in February 2024, defining a JSON descriptor format for displaying contract calls and EIP-712 messages in human-readable form. A descriptor consists of three sections.

• Context: Defines which contract on which chain the descriptor applies to. When a user sends a transaction, the wallet finds and applies the descriptor corresponding to the relevant contract.
• Metadata: Provides displayable public information such as project name, contract name, deployment date, and official links.
• Display: The section actually visible to the user on the signature screen. It defines intent labels for each function and message, the fields to be displayed, and the formatting rules for each value.

Source: clearsigning.org

When a wallet fetches and applies a descriptor written according to these rules, the user sees a screen like "Swap 1,000 USDC for at least 0.42 WETH on Uniswap V3" instead of low-level calldata. Because descriptors are not embedded in contracts themselves but exist separately on the outside, existing contracts can adopt the standard without redeployment, as long as wallets implement it.

ERC-7730 V2, released in April 2026, added a cross-chain token formatter, decryption contexts for encrypted fields (such as confidential tokens based on homomorphic encryption), InterpolatedIntent for dynamic intent strings, and schema keys based on function signatures. That said, some advanced features of V2 may not be supported on every hardware wallet, so when broad compatibility matters, it is worth verifying support on the target wallet.

2.2 ERC-8176: The Integrity Verification Layer

One problem remains with ERC-7730 alone. Because anyone can write a descriptor and submit it to the registry, there is no way to stop a malicious actor from creating a misleading descriptor for their own contract.

ERC-8176 is an attestation framework designed to address this problem. After a descriptor is registered, auditors or security experts can review its accuracy and issue a cryptographically signed attestation. Wallets check the UID (Unique Identifier) of the attestations attached to each descriptor and decide, through their own policies, which reviews to trust. A descriptor attested by multiple independent auditors can be prioritized over one with a single source of attestation.

As a result, the mere fact that a descriptor has been registered does not mean it will automatically be displayed to the user. The final decision on whether to display it always rests with the wallet.

2.3 A Neutral Registry and Open Tooling

The third component is the public registry that stores and distributes descriptors. Protocol teams write JSON files conforming to the ERC-7730 schema and submit pull requests (PRs) to GitHub. During continuous integration (CI), schema conformance, ABI consistency, and contract deployment verification are checked automatically. After review, a separate auditor can issue an ERC-8176 attestation.

Because the descriptors themselves are published as open data, and because the issuance workflow is also open source, the registry is designed so that even if the current operator disappears, anyone can rebuild the same pipeline with their own key and continue operations.

On the tooling side, Sourcify is developing a TypeScript library and a preview tool for descriptor verification, and the security audit firm Cyfrin has released a related tool called Clearsig. Ledger also supports descriptor authoring and testing through its own developer portal and development kits.

3. From Ledger Standard to the Ethereum Standard

Source: Ledger Blog, Sep 2021

Clear Signing did not suddenly appear with this announcement. The standard is closer to a case of Ledger's internal security project gradually expanding into an ecosystem-wide standard.

Ledger has been working on Clear Signing as an internal security project since 2021. Standardization began in earnest with the formal EIP proposal of ERC-7730 in February 2024. The launch of the Generic Parser in mid-2024 then made it possible for applications to implement Clear Signing on Ledger devices using only an ERC-7730 JSON file, without plugins. In early 2026, Ledger handed over governance to the Ethereum Foundation, which led to the release of ERC-7730 V2 in April 2026. With the May 12 announcement, the Ethereum Foundation's $1 trillion security initiative formally took on the stewardship role for the registry, establishing Clear Signing as a standard across the Ethereum ecosystem.

A standard operated by Ledger would inevitably offer weaker adoption incentives for other wallets. From the perspective of MetaMask, Trezor, or any newly emerging wallet, depending on a directory controlled by a competing hardware vendor for their users' transaction information is a difficult position to accept. With the Ethereum Foundation stepping in as a neutral steward, this structural issue could be resolved, and broad cooperation from wallet vendors was made possible.

Source: clearsigning.org

The current contributors to the Clear Signing scheme are as follows.

• Hardware wallets: Ledger, Trezor, Keycard, ZKnox
• Software wallets: MetaMask, WalletConnect
• Security: Cyfrin
• Infrastructure: Fireblocks, Zama
• Tooling: Sourcify, Argot

Source: clearsigning.org

As of May 7, 2026, 44 protocols have registered descriptors, and a total of 346 descriptors have been issued. The registered protocols include major projects with high user transaction frequency such as Uniswap, Aave, Morpho, Lido, OpenSea, Tether, Circle, Ethena, Hyperliquid, and Safe.

4. Limitations and Open Questions

4.1 Coverage and Adoption Incentives

For the standard to work, two forms of adoption are required.

1. Protocols must write descriptors for their own contracts and register them in the registry.
2. Wallets must implement ERC-7730 and use the registered descriptors according to their trust policies.

If either of the two is missing, users will still see only low-level calldata.

The 44 protocols currently registered are a meaningful starting point, but they account for only a small fraction of the contracts actively used on Ethereum mainnet. Newly deployed protocols can be encouraged to publish descriptors at launch, but securing coverage for the many protocols that have already been deployed remains the greatest challenge for adoption of the standard.

Adoption on the protocol side does not happen automatically just because the standard exists. There are clear costs to writing and maintaining descriptors. Each time a contract is upgraded or a new function is added, the descriptor must be synchronized, and an incorrect descriptor can actually mislead users, so the writing process itself requires care. Ultimately, the motivation to maintain and extend descriptors rests on the protocol's own effort to earn user trust, and on active feedback from users in response.

Wallet-side adoption is a separate matter. In the case of Ledger, since it developed the standard, rapid adoption is expected. Trezor, on the other hand, has stated that transaction decoding based on Clear Signing will begin in early Q2 of 2026, with full Clear Signing implementation scheduled for late Q2. The timelines for software wallets remain uncertain, and how this will be reflected on actual user screens depends on the decisions of each wallet.

4.2 Attacks That Clear Signing Still Cannot Prevent

The Bybit hack is frequently cited as a direct catalyst for the launch of Clear Signing, but whether the standard itself could have prevented the same attack is a separate question. The attack used by the Lazarus Group infected Safe's JavaScript frontend and manipulated the transaction information displayed on the user's screen. The screen the user saw was itself false information.

In situations where the software wallet's screen can be tampered with, even if the ERC-7730 descriptor is written correctly, the user will still sign incorrect information if the wallet renders the descriptor alongside fake data. The key to blocking this attack lies in the hardware wallet's own screen. Because hardware wallets display screens independently of the computer-side software, the information shown on the hardware device does not change even when the JavaScript on the computer is tampered with. In the Bybit incident, if the cold wallet signers had verified the transaction details on the hardware device's screen, and if that screen had stated the intent of "replacing contract logic" through an ERC-7730 descriptor, the attack could have been blocked.

This implies that software wallets such as MetaMask should not use ERC-7730 descriptors alone as the endpoint of trust. Clear Signing implementations on software wallets improve user experience, but they do not, on their own, serve as a line of defense at the same level as a hardware wallet's screen. The value of Clear Signing lies in making the hardware wallet's screen meaningful, and it functions as a substantive line of defense only when combined with the user's habit of clearly verifying transaction intent on that screen.

4.3 The Distribution of Trust

The most striking aspect of the standard's design principles is the sovereignty granted to each wallet. Even if descriptors are issued and attestations are gathered in the registry, the final decision on which descriptor to display to the user always rests with the wallet.

This design, however, creates new complexity from the user's perspective. For the same transaction, the displayed information may differ depending on which wallet is used, and some wallets may choose not to display descriptors that lack sufficient attestation. As long as wallet-side policies remain unstandardized, even adherence to the same standard may result in divergent user experiences across wallets.

It also matters how quickly and broadly the auditor ecosystem that vouches for descriptor accuracy will form. At present, there is no explicit incentive structure for auditors to issue ERC-8176 attestations. The $1 million audit grant program announced separately by the Ethereum Foundation alongside the launch of Clear Signing may partially fill this gap, but that program is designed to support protocol-level security audits and does not directly stimulate descriptor-level attestation. Without a dedicated reward mechanism for issuing ERC-8176 attestations, it may be difficult to keep up with the rapid growth of descriptors through voluntary participation from security firms alone.

5. Closing Thoughts

Providing legibility for signatures is one of the tasks the industry has long deferred. The fact that users sign without knowing what they are agreeing to at the final step of a transaction was an obvious security flaw, but in the absence of a standard, it was unrealistic to expect each wallet and protocol to solve the problem individually. A model in which every wallet creates a separate integration for every contract is not scalable.

The significance of the launch of Clear Signing lies in providing common infrastructure that allows every wallet to display consistent screens for every protocol, paying the design cost of this infrastructure once and for all. The Clear Signing scheme can be applied retroactively to existing contracts, and the structure for distributing trust is also designed through the attestation layer. With the Ethereum Foundation stepping in to establish it as a wallet-neutral standard, the possibility has also opened up for adoption incentives to align even under competitive dynamics among wallets. However, the coverage of Clear Signing depends on voluntary participation across the ecosystem, and it is expected to take additional time for the attestation ecosystem to become self-sustaining.

The reason the Ethereum Foundation selected this standard as part of its $1 trillion security initiative is clear. As institutional capital and individual user assets accumulate on-chain, the cost of the last line of defense falling grows exponentially. The entry of institutions raises the bar for security infrastructure itself, and Clear Signing is the first standardized response to that demand. This problem is closer to a precondition that must be resolved for Ethereum to evolve into infrastructure capable of holding institutional-grade trust. Clear Signing carries greater significance for the trajectory it sets than for its immediate coverage, in that it is the first response to that precondition organized in the form of a standard.