Clear Signing і Blind Signing: як зрозуміти, що ви насправді підписуєте

Апаратний гаманець захищає приватний ключ, але це ще не означає, що на його екрані завжди видно, що саме ви підписуєте. Під час роботи з dApp браузер може показувати зрозумілу дію — переказ, обмін або approve, — а сам пристрій отримує технічні дані транзакції. Якщо він не може їх розшифрувати, на екрані залишаються хеш, сирі дані або загальне попередження. Саме цю проблему має вирішувати Clear Signing.

Наслідки добре видно на прикладі Radiant Capital і Bybit. У Radiant шкідливе ПЗ заразило комп’ютери щонайменше трьох розробників. На екрані вони бачили очікувану операцію, але заражені комп’ютери підміняли дані перед відправленням на апаратні гаманці. У результаті підписанти дали три дійсні підписи на шкідливу транзакцію, після чого з протоколу вивели близько $50 млн.

У випадку Bybit зловмисники скомпрометували середовище, через яке підписанти працювали з мультипідписним гаманцем. Шкідливий JavaScript підмінив транзакцію, яку вони бачили: замість звичайного переказу підписанти авторизували зміну логіки гаманця, після чого з нього вивели близько $1,46 млрд. Технічно це були різні атаки, але проблема однакова: інтерфейс на комп’ютері не можна вважати остаточним джерелом істини. Далі розберемо, що саме перевіряє Clear Signing і що дивитися на екрані пристрою перед підтвердженням.

Що насправді підписує апаратний гаманець

Коли ви працюєте з dApp, транзакцію спочатку готує програма на комп’ютері або телефоні — наприклад, Ledger Wallet, Trezor Suite, MetaMask, Rabby чи інший інтерфейс через WalletConnect. Потім дані надходять на апаратний гаманець, де й створюється підпис приватним ключем.

Сам сайт апаратний гаманець не бачить. Він не знає, що написано на кнопці в браузері й яку адресу ви щойно перевірили на моніторі. Тому на екрані пристрою потрібно перевірити саму операцію, а не просто підтвердити її.

Перед тим як говорити про Clear Signing, варто розібрати кілька речей, які часто плутають:

• Транзакція і підпис повідомлення. Транзакція відправляється в мережу й може одразу змінити баланс або стан контракту. Підпис EIP-712 залишається поза мережею й не потребує комісії під час підписання, але пізніше його можна використати, наприклад, як Permit або дозвіл Permit2.
• approve і transfer. transfer переказує токени. approve дає іншій адресі або контракту право списати їх пізніше. Після підозрілого approve баланс може не змінитися, хоча дозвіл вже виданий.
• Підпис і відправка транзакції. Апаратний гаманець створює підпис, а в мережу транзакцію відправляє програма на комп’ютері або телефоні.
• Небезпечний дозвіл не означає витоку seed-фрази. Якщо ви підтвердили шкідливий approve, приватний ключ залишається у вас, але контракт вже отримав право працювати з токенами. Інші типи підписів можуть одразу переказати активи або змінити налаштування смартгаманця.

Докладніше про ці механізми читайте в нашій статті Approve, Permit, Permit2 і WalletConnect: там ми пояснюємо, як працюють дозволи та чому відключення WalletConnect не скасовує те, що ви вже підписали.

Clear Signing — це коли пристрій розбирає отримані дані й показує зрозумілу дію: наприклад, Approve USDC, суму, адресу, якій надається дозвіл, або адресу отримувача. При Blind Signing такого опису немає — на екрані залишається хеш, сирі дані або загальне попередження. В обох випадках підпис буде криптографічно дійсним. Різниця в тому, чи могли ви перевірити зміст операції до підтвердження.

Radiant і Bybit: коли інтерфейс показував не те, що підписували

16 жовтня 2024 року Radiant Capital втратив близько $50 млн. Атака почалася з компрометації комп’ютерів щонайменше трьох розробників. Під час штатної операції зловмисники перехоплювали підтвердження і передавали апаратним гаманцям шкідливу транзакцію замість тієї, яку люди бачили в Safe — інтерфейсі мультипідписного гаманця — і перевіряли через Tenderly, сервіс для симуляції транзакцій. Метою було зібрати три дійсні підписи на transferOwnership і отримати контроль над критичними контрактами Radiant. Пізніше Mandiant з високою впевненістю пов’язав атаку з UNC4736 — кластером, пов’язаним із КНДР.

21 лютого 2025 року Bybit зіткнувся з іншим варіантом тієї самої проблеми довіри до інтерфейсу. Було скомпрометовано середовище Safe — платформи, через яку підписанти керували мультипідписним гаманцем. Шкідливий JavaScript показував підписантам очікувану операцію, тоді як фактично вони авторизували зміну логіки Ethereum-мультипідписного холодного гаманця. Після цього зловмисник зміг вивести активи приблизно на $1,46 млрд, зокрема понад 400 тисяч ETH.

Мультипідпис у такій ситуації не дає додаткового захисту. Якщо всі підписанти бачать скомпрометований інтерфейс і не можуть перевірити дані на своїх пристроях, вони можуть підтвердити ту саму підмінену операцію.

ERC-7730: як гаманець показує, що ви підписуєте

Щоб на екрані з’явилося щось зрозуміле на кшталт «Approve 100 USDC», гаманець має знати, як прочитати дані конкретного контракту. В EVM для цього, зокрема, використовують ERC-7730 (Structured Data Clear Signing Format).

Для конкретного контракту створюється JSON-опис, який пояснює гаманцю, як показати його транзакції. За цим описом пристрій визначає, де в calldata сума, адреса, токен або тип дії, і показує ці дані на екрані у читабельному вигляді.

Чернетку ERC-7730 створили 7 лютого 2024 року. Станом на вересень 2026 року стандарт досі має статус Draft, але вже використовується в робочих інструментах і реєстрі. У травні 2026 року Ethereum Foundation взяла на себе координацію відкритого реєстру Clear Signing.

Відсутність ERC-7730 ще не означає Blind Signing. Деякі операції гаманець уміє розбирати сам. Хеш або сирі дані з’являються тоді, коли пристрій не знає, як прочитати конкретну транзакцію ні через ERC-7730, ні через власний парсер.

Ще один пов’язаний стандарт — ERC-8176. Він описує атестації, за якими гаманець може перевірити походження ERC-7730-опису та його зв’язок із контрактом. На екрані мають відображатися дані самої транзакції, а не текст, який показує сайт.

Як Clear Signing працює в Ledger і Trezor

Ledger

Ledger використовує Clear Signing з 2023 року. Для ERC-7730 функція працює через Ledger Wallet із WalletConnect, вбудований Web3-браузер, Ledger Wallet Button та сумісні сторонні гаманці. Робота Clear Signing залежить також від того, через який інтерфейс пристрій підключений до dApp.

У застосунку Ethereum є параметр Blind signing. Якщо певний dApp справді його вимагає, режим можна ввімкнути на час операції, а потім вимкнути. Постійно тримати його активним немає сенсу.

Ledger також використовує Transaction Check: перед підписом транзакція проходить симуляцію, а пристрій отримує звіт про можливий ризик. Ця перевірка доповнює дані на екрані гаманця, але не замінює їх. Якщо пристрій показує не ту дію, яку ви очікували, запит краще відхилити.

Trezor

У вересні 2026 року Trezor додав підтримку ERC-7730 Clear Signing. Функція доступна на Trezor Safe 7, Safe 5, Safe 3 і Model T з прошивкою Universal Firmware 2.12.4 або новішою. Окремо нічого вмикати не потрібно: підтримувані транзакції розбираються автоматично через Trezor Suite, WalletConnect і Trezor Connect.

Clear Signing працює з Ethereum, EVM-сумісними L2 і сайдчейнами, але для конкретного dApp потрібен відповідний дескриптор. Серед перших підтриманих протоколів Trezor називав 1inch, Aave, Hyperliquid, Lido, LiFi й OpenCover. Якщо пристрій не може розібрати операцію, ви побачите хеш і попередження про Blind Signing. Model One ERC-7730 Clear Signing не підтримує.

MetaMask і Rabby

MetaMask, Rabby та інші програмні гаманці теж вміють розшифровувати транзакції, запускати симуляцію й попереджати про підозрілі дозволи. Але все це відбувається на тому самому комп’ютері або телефоні, де відкритий dApp. Тому дані на екрані апаратного гаманця все одно потрібно звіряти окремо з тим, що показує браузер.

Bitcoin, Solana та інші мережі

ERC-7730 створений для EVM, тому на Bitcoin, Solana чи Cosmos він не поширюється. У цих мережах свої формати транзакцій і свої парсери.

Наприклад, Ledger для Solana все ще описує Blind Signing для частини складніших взаємодій із dApp. Це стосується не всіх Solana-транзакцій: стандартні операції застосунок може показувати нормально. Усе залежить від конкретної дії та версії застосунку Solana.

Clear Signing не гарантує безпеку транзакції

Clear Signing допомагає прочитати транзакцію, але не оцінює сам контракт. Наприклад, невідомий dApp може попросити необмежений доступ до USDC, а пристрій правильно покаже Approve, spender і ліміт. Якщо ви не очікували такого дозволу, підписувати його не варто — навіть коли пристрій показав усі дані без помилок.

Помилки бувають і в коді, який розбирає транзакцію. У 2026 році Trezor, наприклад, виправив проблему, через яку під час Clear Signing ERC-20 transfer або approve пристрій міг не показати ETH, що відправлявся разом із токен-операцією.

У серпні 2026 року Ledger Donjon опублікував ще три бюлетені про помилки в перевірці даних перед підписом:

• LSB-023. За певних умов пристрій міг показати одні параметри, а підписати інші. Для застосунок Ethereum захист з’явився у версії 1.22.2; базове виправлення SDK — у v26.6.1.
• LSB-024. Під час обробки великого масиву пристрій міг показати лише частину даних, хоча підпис охоплював усю структуру. Виправлення увійшло до застосунку Ethereum 1.22.3.
• LSB-025. Під час обміну очікуваний платіж можна було підмінити на approve із тими самими параметрами. Цю проблему також виправили в застосунку Ethereum 1.22.3.

Ledger не знайшов доказів використання цих трьох вразливостей проти користувачів. Ці помилки не давали доступу до Secure Element чи приватних ключів. Оновлювати потрібно і прошивку пристрою, і встановлені на ньому застосунки мереж.

Що робити, якщо на екрані лише хеш

Іноді пристрій просто не може розібрати операцію: контракт новий, формат нестандартний або потрібної підтримки ще немає в застосунку мережі. У такому випадку залишається Blind Signing. Якщо на екрані тільки хеш, не покладайтеся на браузер — дані потрібно звірити окремо.

Для складних операцій — наприклад, EIP-712-підпису або мультипідпису Safe — можна самостійно порахувати хеш і порівняти його з тим, що показує пристрій. Для Safe використовується safeTxHash; Cyfrin, наприклад, має для цього інструмент safe-hash. Якщо комп’ютер під підозрою, рахувати хеш на ньому ж немає сенсу — візьміть інший пристрій, якому довіряєте.

Якщо хеш збігається, пристрій отримав ті самі дані, які ви порахували окремо. Але збіг нічого не говорить про безпечність самої операції: так само можна порахувати хеш шкідливої транзакції. Такий формат перевірки поступово стандартизує ERC-8213. Trezor 2.12.4 вже вміє показувати digest для calldata, тобто короткий хеш даних транзакції, хоча універсальної підтримки в усіх гаманцях поки немає.

Симуляція в Tenderly або в самому гаманці теж допомагає: вона показує, які зміни очікуються після виконання транзакції. Але покладатися тільки на неї не варто. Radiant Capital використовував Tenderly, і це не врятувало від підміни безпосередньо під час підписання.

Що перевірити перед підписом

Порядок екранів у Ledger і Trezor відрізняється, але перед підписом варто перевірити такі речі:

1. Мережа. Якщо ви працюєте в Arbitrum, а на пристрої бачите Ethereum mainnet, не підтверджуйте транзакцію, доки не з’ясуєте причину.
2. Адреса або контракт. Для значних сум краще звірити адресу повністю з незалежним джерелом. Перших і останніх кількох символів вже недостатньо: шахраї використовують підміну адрес в історії транзакцій (address poisoning) і спеціально підібрані схожі адреси.
3. Дія. Transfer, Approve, Swap, Set delegation — назва має відповідати тому, що ви щойно робили в dApp. Якщо очікували обмін, а бачите approve, запит краще відхилити.
4. Токен і сума. Перевіряйте їх разом. Особливо уважно дивіться на незвичну кількість знаків після коми.
5. Ліміт для approve. Перевірте, чи даєте контракту доступ лише до потрібної суми, чи відкриваєте необмежений ліміт.
6. Адреса отримувача дозволу (spender) і строк дії Permit / Permit2. Подивіться, кому ви даєте право списувати токени, на яку суму і до якої дати.
7. Делегування / EIP-7702. Якщо ви не планували делегувати акаунт контракту, такий запит потрібно відхилити. EIP-7702 може змінити поведінку вашої звичайної адреси. Дослідники USENIX Security ’26 виявили в семи мережах 924 шкідливі контрактні акаунти, пов’язані з EIP-7702; підтверджені втрати перевищили $2,3 млн.
8. Незрозумілий хеш або сирі дані. Якщо ви не можете перевірити їх окремо, відхиліть запит і спочатку з’ясуйте, чому пристрій не показує нормальний опис.

Якщо ви лише обираєте апаратний гаманець, ERC-7730 Clear Signing зараз підтримують Trezor Safe 3, Safe 5, Safe 7 і Model T, але не Model One. У Ledger підтримка залежить від застосунку мережі, способу підключення та конкретного dApp. Для звичайних Bitcoin-транзакцій ERC-7730 не потрібен: там адреса й сума перевіряються через власний формат Bitcoin.

Що робити, якщо ви вже підписали незрозумілий запит

Спочатку з’ясуйте, що саме ви підтвердили. Сам підпис не розкриває seed-фразу або приватний ключ. Далі все залежить від типу запиту: approve або Permit2 можуть залишити активний дозвіл, transfer чи swap — вже перемістити активи, EIP-7702 — встановити делегацію, а транзакція смартгаманця — змінити його налаштування.

Якщо проблема в дозволах на токени, перевірте активні дозволи approve і Permit2 через revoke.cash або блокчейн-експлорер вашої мережі та відкличте все, чого не впізнаєте. Для EIP-7702 окремо перевірте, чи немає активної делегації. Для відкликання ончейн-дозволів потрібна комісія мережі.

Якщо наслідки підпису незрозумілі, а на адресі зберігається велика для вас сума, краще створити новий гаманець на іншому пристрої, якому ви довіряєте, і перевести туди активи після перевірки старої адреси. Якщо є підстави вважати, що seed-фразу могли побачити сторонні, цю резервну копію більше не слід використовувати для зберігання коштів.

Головне

Апаратний гаманець ізолює приватний ключ, але не визначає, чи безпечний запит на підпис. Перед підтвердженням прочитайте те, що показує сам пристрій. Clear Signing спрощує цю перевірку, хоча підтримується не для кожної операції.

Перед підтвердженням звірте мережу, адресу або контракт, дію, токен і суму. Якщо на екрані лише хеш і ви не знаєте, як його перевірити, відхиліть запит і спочатку розберіться, чому транзакція не декодується.