Clear Signing: Cyfrin Flags Hidden Fields in 1inch

At the end of July 2026, the audit firm Cyfrin classified several high severity defects in 1inch clear signing. Thus, certain fields, including the contract receiving the funds committed by the user, do not appear on the wallet screen. As of October 12, these display rules still appear in the public registry. They cover the 1inch V6 router on 13 networks, including Ethereum.

Clear signing, a response to the Bybit hack

In February 2025, the record Bybit hack cost the platform about 1.5 billion dollars, according to the FBI. The FBI also attributes this theft to North Korea. According to CertiK’s analysis, the Safe{Wallet} interface displayed a legitimate transaction. However, the data sent to the Ledger for signing was different. The CEO of Bybit even admitted to not verifying them on the device screen. CertiK calls this blind signing.

Clear signing addresses this problem. It translates transaction data into clear language on the screen of your crypto wallet. Ledger launched it in 2023 and then formalized it in the ERC-7730 standard proposal. Then, on May 12, 2026, the company entrusted its management to the Ethereum Foundation. MetaMask, Trezor, WalletConnect, and Cyfrin participate in the working group.

The system relies on public files called descriptors. Each indicates which transaction fields the wallet should display and under which label. A field marked “never” never appears on the screen.

The contract receiving your funds can remain invisible

1inch is a decentralized exchange aggregator. Cyfrin audited several of its descriptors. The ticket no. 2688 concerns the main descriptor of the V6 router. It indeed has two high severity findings and three medium severity findings, according to the auditor’s classification.

The first finding concerns the clipperExchange parameter, hidden on the screen. Yet it designates the contract receiving the user’s funds. The caller of the function provides this parameter. According to Cyfrin, the wallet thus displays a normal exchange screen without showing the contract receiving the funds.

The second high finding targets the args field, also hidden. In certain order execution modes, it can contain the address receiving the purchased asset. The user may see exact amounts while the asset goes to an unseen address, according to the auditor.

Two medium findings also concern the display. First, an order amount always appears as a “to sell” amount. Yet one router mode treats it as a “to buy” amount. Second, the permitAndCall function masks a spending authorization that may specify the token, the authorized spender’s address, the amount, and expiry. Finally, the last medium finding relates to deployments Sourcify had not yet verified.

1inch clear signing unchanged on 13 networks

A related ticket, no. 2690, concerned the zkSync version of the router. This nine-line descriptor pointed to the same common file as the main version. The maintainers removed it from the registry on September 22. The reason is verification. Sourcify, the code verification tool used by the registry, cannot yet verify the compiled code for zkSync. This removal thus does not fix the display rules.

Yet the main branch of the registry, consulted on October 12, still contains these rules. The common file and main descriptor currently date from April 10, 2026. They apply to the V6 router on 13 networks, including Ethereum, Arbitrum, Base, BNB Chain, and Polygon. The descriptor of the previous version, V5, also masks clipperExchange on six networks.

A third audit, no. 2689, concerns off-chain signed orders in EIP-712 format. The descriptor hides the makerTraits field. It can contain the order’s expiration date and a restriction on the authorized address to execute it. Cyfrin also classifies this finding as high severity.

An attestation does not guarantee displayed meaning

The registry provides a safeguard, the attestation. The ERC-8176 standard proposal defines this mechanism. It allows an auditor to sign a descriptor they have reviewed. On August 17, the registry incorporated attestations from Cyfrin for 181 descriptors.

In the 1inch folder, only older V3 and V4 router versions have one. In contrast, V6 descriptors do not. In audit no. 2689, Cyfrin notes missing code verification on five networks: “the attestation condition is not met” (editor’s translation). ERC-8176 then leaves each wallet the choice of auditors it trusts.

However, even attested, a descriptor can mislead. The ERC-8176 project states this in its section on limitations of the mechanism.

Signature verification does not validate semantic accuracy.

ERC-8176, Descriptor Attestations for ERC-7730, standard proposal

Another limitation relates to upgradeable contracts or proxies. A proxy keeps its address but its code can change. An analysis published in September listed 80 proxy-related descriptors out of 382 as of September 5. The maintainers then chose to keep them and address the issue within the standard itself.

What clear signing displays and what it omits

The registry also fixes defects. On September 25, a patch targeted another 1inch descriptor for Limit Order Protocol v2 limit orders. According to its message, wallets that recognize descriptors by signed type could not apply it. Users thus signed these orders “blindly”.

For the user, a readable screen only shows fields retained by the descriptor. Thus, the absence of a recipient or expiration date is not visible. Cyfrin recommends displaying these fields or removing the description. In the latter case, the wallet falls back to raw signing, giving no impression of clarity. None of the consulted tickets mention user loss related to these descriptors. Our guide on the most secure crypto wallet details other available protections.

As of October 12, the two audited V6 descriptors still in the registry remain unchanged. The third, for zkSync, left the registry without correction. For the makerTraits field, Cyfrin’s proposed fix modifies a single file line to make the field visible. [TO BE COMPLETED: response dated from 1inch, Cyfrin, or registry maintainers, or mention of unanswered requests] Regarding proxies, the proposal no. 1738 is not yet integrated into the standard. Kaan Uzdoğan, ERC-7730 co-author, indicated on GitHub awaiting further reviews before approval.