Approve, Permit і WalletConnect: які дозволи можуть вкрасти ваші токени

Approve, Permit і WalletConnect — звичні для DeFi механізми, через які користувач може надати контракту право працювати зі своїми активами. Захист криптовалют зазвичай починають із seed-фрази: її зберігають офлайн, не вводять на сторонніх сайтах і не передають іншим людям. Однак цього недостатньо, якщо власник гаманця сам підтвердить дозвіл або підпис, зміст якого не перевірив.

Approve, Permit, Permit2, WalletConnect і делегації EIP-7702 працюють по-різному, проте в усіх цих сценаріях вирішальним часто стає одне: користувач бачить звичну кнопку Confirm або Sign і підтверджує запит, не розібравшись у його змісті. Приватні ключі при цьому можуть залишатися захищеними, хоча виданий дозвіл уже дає змогу списати токени.

У статті зосередимося на тому, що потрібно знати перед підтвердженням запиту: як працюють approve і Permit, чим ризикований Unlimited approval, чому Disconnect не замінює Revoke, яку роль виконує WalletConnect і що змінив EIP-7702. Окремо розберемо перевірку чинних дозволів і порядок дій після підозрілого підпису.

Approve, Permit і WalletConnect: де виникає ризик

Саме відкриття сайту не дає смарт-контракту права списати ваші ERC-20 токени. Для цього зазвичай потрібен попередньо виданий allowance — дозвіл певній адресі або контракту витратити до визначеної суми через transferFrom.

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

За даними Scam Sniffer, у 2024 році wallet drainers викрали близько $494 млн у 332 тисяч адрес, а серед великих інцидентів помітна частка втрат припадала на шкідливі Permit-підписи. У 2025 році сума таких крадіжок суттєво зменшилася, проте сам спосіб атаки залишився актуальним: отримати від власника потрібний підпис часто простіше, ніж заволодіти його приватним ключем.

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

Як виглядає типова атака через дозвіл

Типова атака виглядає буденно: користувач переходить на фейковий airdrop, mint або копію знайомого DeFi-сервісу, підключає гаманець і отримує запит, який виглядає логічним продовженням дії на сторінці — Claim, Continue, Verify або Sign.

За такою кнопкою може ховатися approve на адресу зловмисника, Permit на велику суму або інший дозвіл. Ризик виникає в момент підтвердження конкретного запиту: після підпису виданим правом можна скористатися без нового підтвердження з вашого боку.

Які підписи ви бачите у гаманці

Кнопка Sign може стосуватися зовсім різних дій: входу на сайт, структурованого Permit або підпису raw hash, зміст якого гаманець майже не пояснює. Через це корисно розрізняти хоча б найпоширеніші формати.

eth_sign: підпис без зрозумілого контексту

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

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

personal_sign: часто використовується для входу

personal_sign часто використовують для авторизації або підтвердження володіння адресою. Такий підпис не є звичайною Ethereum-транзакцією, однак його зміст усе одно потрібно читати: сервіс може використовувати підписане повідомлення як підтвердження певної дії у власному протоколі.

EIP-712: структурований підпис

EIP-712 дає гаманцю змогу показати структуровані поля замість нечитабельного hex-набору — наприклад, spender, суму, deadline, мережу та контракт. Цей формат використовують Permit і багато сценаріїв Permit2.

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

Approve: класичний дозвіл ERC-20

Функція approve(spender, amount) записує в контракті токена, яку суму може витратити вказаний spender. Під час самого approve токени залишаються на вашому балансі; рух коштів починається лише тоді, коли одержувач дозволу викликає transferFrom.

Чому Unlimited approval створює проблему

Щоб не запитувати approve перед кожною операцією, dApp нерідко встановлюють дуже великий або фактично необмежений allowance. Це скорочує кількість підтверджень під час наступних swap, але водночас залишає контракту широке право на списання, яке може діяти роками.

Старий allowance не зникає разом із забутим сервісом: запис залишається в контракті токена, доки його не відкличуть або не змінять. Якщо згодом контракт чи пов’язана з ним інфраструктура буде скомпрометована, зловмиснику може вистачити вже виданого права на списання, і новий підпис власника вже не знадобиться.

Для NFT подібну роль виконує setApprovalForAll, який дає оператору право керувати всіма NFT певної колекції від вашого імені. На фейкових mint і claim-сайтах такий запит можуть подавати як звичайний крок для отримання NFT, хоча обсяг дозволу значно ширший.

Permit: коли дозвіл видається через підпис

Звичайний approve потребує on-chain транзакції та оплати gas. EIP-2612 Permit дозволяє спочатку підписати повідомлення офчейн, після чого сервіс, релеєр або інша сторона передає цей підпис у контракт токена.

Повідомлення містить, зокрема, owner, spender, value, deadline і nonce. Перевіривши підпис, контракт створює allowance без окремої approve-транзакції, тому процес швидший і не вимагає gas від користувача на етапі підписання. Через це Permit легко сприйняти як звичайне повідомлення, хоча наслідком може бути повноцінний дозвіл на списання.

У момент підписання Permit може не залишити жодної транзакції в історії гаманця. Валідний підпис можна подати в мережу пізніше, доки не минув deadline і відповідний nonce ще не використаний.

У березні 2026 року публічно розбирали випадок, у якому після шкідливого Permit-підпису з гаманця вивели приблизно $1,76 млн у USDC. За даними GoPlus, пристрій користувача був скомпрометований, що дало зловмисникам змогу підмінити запит і отримати валідний підпис; вразливості самого Permit у цьому випадку не було.

Відсутність нового allowance у block explorer не виключає ризику: до подання Permit-підпису on-chain звичайний список approvals його не побачить.

Що дає domain separator

Domain separator у EIP-712 прив’язує Permit до конкретної мережі та контракту, зменшуючи ризик повторного використання того самого підпису в іншому контексті. Водночас він не перевіряє, чи правильно ви вибрали spender: підпис, свідомо або помилково виданий небезпечній адресі, залишиться технічно коректним.

Permit2: одна система дозволів для різних токенів

Не всі ERC-20 токени підтримують EIP-2612, тому Uniswap створив Permit2 як окремий універсальний шар дозволів. Користувач спочатку видає контракту Permit2 базовий on-chain approve, а далі може надавати окремим dApp дозволи через підписи.

Під час перевірки Permit2 потрібно дивитися на два рівні: базовий approve токена до контракту Permit2 і дозволи, які через нього отримали окремі застосунки. Скасування одного з таких дозволів не обов’язково прибирає базовий allowance.

Структуровані Permit2-підписи можуть містити чимало технічних полів, через що їх легше підтвердити механічно, не перевіривши одержувача дозволу та його межі. На цьому й ґрунтуються фішингові сценарії, замасковані під знайомий DeFi-інтерфейс.

WalletConnect: підключення без прямого доступу до токенів

WalletConnect інколи помилково сприймають як окремий дозвіл на роботу з активами. Його роль інша: протокол з’єднує гаманець із dApp і передає між ними запити, а підключення через QR-код або deep link саме по собі не створює allowance на токени.

Після встановлення сесії dApp може надіслати approve, Permit, транзакцію або запит на підпис повідомлення. Кожен такий запит гаманець показує окремо, тому вирішальним стає зміст дії, яку користувач погоджується підписати.

Коли про інцидент кажуть «вкрали через WalletConnect», причиною часто виявляється шкідливий запит, переданий через відкриту сесію й підтверджений користувачем; сам протокол WalletConnect при цьому не був скомпрометований.

Чому старі сесії краще закривати

Закриття вкладки браузера не обов’язково завершує WalletConnect-сесію, тому старе підключення може залишатися активним і надалі приймати запити від dApp. Непотрібні та незнайомі сесії варто періодично завершувати, навіть якщо жодних on-chain дозволів вони самі не створюють.

Disconnect завершує WalletConnect-сесію з dApp, тоді як Revoke змінює або скасовує on-chain allowance. Якщо раніше контракт отримав Unlimited approval, відключення WalletConnect-сесії на цей дозвіл не вплине.

Що саме залишається після Disconnect

Після Disconnect dApp зникає зі списку активних сесій, але раніше виданий approve продовжує діяти, оскільки allowance зберігається on-chain у контракті токена. Закриття вкладки, очищення cookies або відключення сайту цей запис не змінюють.

Revoke дозволу також не обов’язково завершує WalletConnect-сесію. Тому після роботи з непотрібним сервісом варто окремо перевірити і активні підключення, і on-chain approvals.

EIP-7702: новий ризик після Pectra

EIP-7702 запрацював у Ethereum разом з оновленням Pectra 7 травня 2025 року. Стандарт дозволяє EOA-адресі делегувати виконання логіки іншому контракту, зберігаючи ту саму адресу, завдяки чому стають можливими batching, оплата gas третьою стороною, обмеження витрат та інші функції smart account.

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

Після Pectra EIP-7702 швидко почали використовувати й дрейнери: у звітах за 2025 рік описані великі втрати після шкідливих batch-підписів, а дослідники також фіксували sweeper-контракти, що застосовували 7702 на адресах із уже скомпрометованими ключами.

Ризик залежить від сценарію. Якщо зловмисник уже має приватний ключ, EIP-7702 може допомогти автоматизувати виведення коштів із скомпрометованої адреси. В іншому випадку ключ залишається у власника, але користувача вводять в оману й отримують підпис під небезпечною делегацією. У першій ситуації кошти потрібно перенести на новий гаманець зі свіжими ключами; у другій потрібно скасувати небажану делегацію та перевірити, чи немає інших ознак компрометації.

Незнайома smart-account або EIP-7702 делегація потребує перевірки: з’ясуйте, якому контракту передано виконання і коли це сталося. Невідома делегація ще не свідчить про витік seed-фрази, однак залишати її без перевірки не варто.

Як перевірити та відкликати дозволи

Для Approve, Permit і WalletConnect немає однієї спільної кнопки перевірки: on-chain approvals переглядають у сервісах керування дозволами або block explorer, а WalletConnect-сесії — безпосередньо в гаманці. Для ERC-20 і NFT зручно скористатися, наприклад, revoke.cash, де видно активні дозволи та контракти, яким вони видані.

• ERC-20 approve. Перегляньте Unlimited і великі allowance, особливо якщо вони видані старим або вже непотрібним контрактам.
• NFT-дозволи. Перевірте setApprovalForAll, якщо користувалися mint-сайтами, маркетплейсами або іншими NFT-dApp.
• Permit2. Перевірте базовий approve до Permit2 та окремі дозволи, видані через нього застосункам.
• WalletConnect. Завершіть старі й непотрібні сесії окремо від перевірки on-chain дозволів.

Відкликання on-chain дозволу — окрема транзакція, яка потребує gas, тому скасовувати кожен approval одразу після використання не завжди доцільно. Натомість варто періодично переглядати список і прибирати дозволи, які більше не потрібні, особливо після експериментів із новими DeFi-сервісами, mint або airdrop.

З Permit ситуація інша: підписане офчейн повідомлення не з’явиться серед on-chain approvals, доки його не використають. Якщо є підстави вважати, що такий підпис отримав зловмисник, не варто чекати появи нового запису в explorer, перш ніж захищати активи.

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

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

Перед Confirm перевірте кілька полів, які визначають реальний обсяг дозволу.

• Перевірте домен. Відкривайте DeFi-сервіси із закладок або офіційних джерел і не покладайтеся на рекламні оголошення чи випадкові посилання.
• Звірте spender і контракт. Якщо адреса вам незнайома, перевірте її за офіційною документацією сервісу або в block explorer.
• Перевірте amount і deadline. Unlimited або непропорційно довгий строк дії для одноразової операції потребують додаткової перевірки.
• Не підписуйте нечитабельні дані. Якщо гаманець показує лише hex-набір без зрозумілого опису дії, перевірити зміст підпису ви фактично не можете.
• Відокремлюйте основні кошти від експериментів. Для нових dApp, mint і airdrop краще використовувати окремий гаманець із невеликою сумою.
• Звіряйте дані на екрані апаратного гаманця. Перед підписом орієнтуйтеся на дані, які показує сам пристрій, і звіряйте їх із дією на сайті.

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

Якщо ви щойно підтвердили підозрілий approve, Permit або EIP-7702 делегацію й не впевнені в її змісті, виходьте з того, що виданий дозвіл уже можуть використати. Спочатку захистіть активи, а деталі інциденту перевіряйте після цього.

1. Перемістіть цінні активи на безпечну адресу. Це особливо актуально для підозрілого офчейн Permit, який уже міг потрапити до зловмисника.
2. Відкличте підозрілі on-chain approvals. Перевірте ERC-20 approve, NFT setApprovalForAll і дозволи Permit2.
3. Перевірте EIP-7702 та smart-account делегації. Незнайому делегацію скасуйте; якщо одночасно є ознаки витоку приватного ключа, перенесіть кошти на новий гаманець зі свіжими ключами.
4. Завершіть WalletConnect-сесії і припиніть будь-яку взаємодію з підозрілим сайтом.

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

Підсумок

Approve, Permit і WalletConnect, а також Permit2 та EIP-7702 виконують різні функції. Approve створює allowance для токена, Permit дозволяє надати такий дозвіл через офчейн-підпис, Permit2 централізує керування дозволами, WalletConnect передає запити між dApp і гаманцем, а EIP-7702 дає EOA змогу делегувати виконання логіки смарт-контракту.

Перед підписом перевіряйте spender, суму, строк дії та контракт, навіть якщо сайт вам знайомий і запит виглядає звично. Основні кошти краще не використовувати для тестування нових dApp, а старі approvals — періодично переглядати й відкликати, коли вони більше не потрібні.

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