EIP-7702: один підпис віддає адресу контракту, а 97% делегувань вели на sweeper

Коротко (TL;DR)

Делегування за EIP-7702 — це запис у полі коду вашої власної адреси, який каже мережі: «виконуй тут код он того контракту». Звичайний гаманець (EOA, externally owned account — адреса, якою керує приватний ключ, а не програма) після такого запису поводиться як смартконтракт, залишаючись під тим самим ключем. Підписується це окремим кортежем усередині транзакції, а не звичним підтвердженням платежу, і в інтерфейсі має вигляд одного рядка.

• Це не дозвіл на суму, а зміна коду адреси. Підпис approve() дозволяє витратити конкретний токен на конкретну суму. Авторизація 7702 робить делегата виконавцем будь-якого виклику від імені адреси. Формулювання Curvegrid влучне: делегування ближче до встановлення програми, ніж до дозволу на платіж.
• Механізм задумували як апгрейд зручності. Специфікація дає три сценарії: пакетні транзакції, оплату газу третьою стороною і тимчасові ключі сесії. Саме через них опцію «розумного акаунта» вбудували MetaMask, Rabby, TokenPocket та інші гаманці.
• Рання статистика вектора виглядала майже комічно. Понад 97% усіх проаналізованих делегувань (замір Wintermute Research, весна 2025 року) вели на контракти з однаковим скопійованим кодом — sweeper, який автоматично вигрібає вхідний ETH.
• Другий підпис зловмиснику не потрібен. Академічна праця відтворила три незалежні способи активувати вже встановлене делегування, зокрема такий, де жертва взагалі нічого не робить.
• Задокументовані втрати рахують мільйонами. Два випадки серпня 2025 року на $1,54 млн і $1,00 млн (дані ScamSniffer) — це $2,54 млн, приблизно 3,0% усіх фішингових втрат року ($83,85 млн за 2025-й у тому самому звіті).
• Перевірка і скидання коштують копійки. Зняття делегування — це 33 500 газу: на 30 серпня 2026 року за газу 0,039182101 Gwei і курсу ETH $2454,68 виходить $0,0032, менше ніж третина цента. Але скидання делегування не скасовує раніше виданих approvals — це окрема операція.

Далі — що саме підписує власник, як один підпис перетворюється на постійний доступ, як подивитися код своєї адреси руками і що після скидання все одно залишиться висіти.

EIP-7702: як звичайна адреса Ethereum дістає код смартконтракту

До апгрейду Pectra (7 травня 2025 року) адреси в Ethereum поділялися на два класи, які не перетиналися. Звичайна адреса (EOA) — це пара ключів: у неї є баланс і nonce, але немає коду, і будь-яка дія потребує підпису. Смартконтракт — навпаки: у нього є код і немає ключа, він виконується лише тоді, коли його хтось викликав.

Цей розбір — урок блоку «Ризики і захист» курсу «DeFi: від першої транзакції до профі-стратегій».

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

EIP-7702 стирає цю межу. Офіційна специфікація вводить транзакцію нового типу (Type 4, 0x04) під назвою «Set Code for EOAs» і дозволяє записати в поле коду звичайної адреси 23 байти: маркер 0xef0100 і далі 20 байтів адреси контракту-делегата. Байт 0xef для звичайного коду заборонений окремим правилом протоколу, тому такий запис однозначно читається як «тут делегування, а не програма». Приватний ключ при цьому нікуди не зникає: власник і далі підписує транзакції сам і будь-коли може переписати або стерти цей запис.

Rug pull і тихий вихід команди: 5 протоколів від піку TVL до нуля

Ризики DeFi за шарами: два зломи дали 44% втрат, і жоден не баг коду

OpenAI зупинила навчання найпотужніших моделей: агент вийшов із пісочниці через DNS

Злом мосту KelpDAO на $293 млн: 1-of-1 DVN, 46 хвилин і борг Aave до $230 млн

Crypto bridge між блокчейнами: три схеми і ціна від $0,063 до $0,19

Практичний сенс конструкції — дати гаманцю функції смарт-акаунта без переїзду на нову адресу. Специфікація і сторінка Ethereum Foundation про Pectra називають три сценарії:

• Пакетні транзакції — approve і swap ідуть одним підписом замість двох.
• Спонсорування газу — комісію платить третя сторона (paymaster), а не власник адреси.
• Ключі сесії — тимчасовий ключ з урізаними правами замість основного на кожну операцію.

Масштаб перестав бути експериментальним дуже швидко. Наприкінці травня 2025 року, за три тижні після Pectra, лічильник показував 12 329 транзакцій EIP-7702 (дані Wintermute, наведені Cointelegraph). Дашборд тієї самої команди на Dune станом на 27 серпня 2026 року віддає 25 307 572 валідні авторизації накопичувальним підсумком — щоправда, з 27 жовтня 2025 року датасет враховує лише адреси з міткою Retail Wallets, тобто це роздрібний зріз, а не весь Ethereum. Різниця між двома замірами — понад три порядки за п’ятнадцять місяців.

Authorization tuple: що саме підписує власник гаманця

Усередині транзакції типу 4 є поле authorization_list — список кортежів. Кожен кортеж складається з шести елементів: [chain_id, address, nonce, y_parity, r, s]. Перший — ідентифікатор мережі, другий — адреса контракту-делегата, третій — nonce акаунта на момент застосування, останні три — компоненти підпису secp256k1. Так цей склад описує специфікація, і так само його формалізує академічна праця arXiv 2512.12174, що розбирала реальні транзакції.

Ключова деталь схована в першому полі. Специфікація припускає chain_id = 0, і тоді авторизація валідна в будь-якій EVM-сумісній мережі. Один підпис — і делегат стає на вашу адресу в Ethereum, Base, Arbitrum, BNB Chain і будь-де ще, де ця адреса існує. Це законна можливість (власнику зручно увімкнути смарт-акаунт одразу всюди), але вона ж робить підпис багаторазовим у чужих руках.

Тепер про порівняння, яке найчастіше підміняють неточною аналогією «це як approve, тільки на все». Різниця не в масштабі, а в природі операції. approve() — звичайний виклик методу контракту токена: він записує в його сховище рядок «адреса X може витратити Y токенів». Authorization tuple нічого не дозволяє — він змінює код самої адреси. Щойно код записано, делегат виконує від вашого імені будь-який виклик, і жодного окремого «дозволу» йому більше не потрібно. Тему «сплячих» токен-дозволів ми розібрали окремо — що таке approvals і як їх відкликати; тут важлива лише технічна відмінність.

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

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

Батчинг, спонсорство газу, ключі сесії: законні сценарії

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

Саме тому гаманці масово дістали опцію «розумного акаунта». MetaMask, наприклад, використовує власний контракт-делегат за адресою 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b — він підписаний як «MetaMask: EIP-7702 Delegator», вихідний код на Etherscan верифіковано з точним збігом, а сам контракт задіяний у п’яти мережах (Ethereum, Polygon, Arbitrum, Base, BNB Chain); станом на 30 серпня 2026 року на його сторінці 88 транзакцій.

Різниця між цим сценарієм і атакою — не в механізмі, а в тому, чия адреса потрапляє в кортеж. Протокол не розрізняє «доброго» і «поганого» делегата: він просто пише 23 байти в код вашого акаунта.

Дрейнери дістають постійний контроль одним підписом: три тригери

Дрейнер (drainer) — готовий набір скриптів і контрактів, який виводить активи з гаманця після того, як жертва щось підписала на фішинговому сайті. Класична схема потребувала підпису на кожен актив або принаймні на кожен токен-контракт. З делегуванням досить одного: після нього код на вашій адресі належить зловмиснику.

Далі починається найменш очевидне. Праця arXiv 2512.12174, що розібрала понад 150 000 подій авторизації та виконання на 26 000+ адресах, показала експериментально: активувати вже встановлене шкідливе делегування може будь-який шлях виклику, а не лише дія жертви. Автори відтворили три:

1. User-driven. Жертва сама надсилає зі своєї адреси будь-яку транзакцію — хоч переказ самій собі. Код делегата відпрацьовує принагідно.
2. Attacker-driven. Зловмисник надсилає виклик на адресу жертви сам. Жертві не потрібно робити взагалі нічого — досить того, що делегування стоїть.
3. Protocol-triggered. Штатний callback стороннього контракту — роутера, маркетплейсу, протоколу — прилітає на адресу жертви в межах звичайної операції і запускає код делегата.

Третій шлях найнебезпечніший саме тому, що він невидимий: власник не робить нічого підозрілого, а його адресу все одно викликано. Практичний висновок для читача один: «я нічого поганого не підписував останнім часом» — не доказ безпеки. Значення має не пам’ять про підписи, а поточний вміст поля коду вашої адреси.

Яким виявився реальний профіль зловживань, показав замір Wintermute Research навесні 2025 року: понад 97% усіх проаналізованих делегувань EIP-7702 вели на контракти з однаковим скопійованим байткодом (дані Wintermute, переказані Cointelegraph). Це sweeper — примітивний контракт, який автоматично переводить будь-який ETH, що надійшов, на адресу зловмисника. Ставлять його на гаманці, чий приватний ключ уже скомпрометовано в інший спосіб: власник поповнює адресу, щоб вивести залишки, і гроші йдуть раніше, ніж він устигає підписати транзакцію. Ту саму знахідку незалежно переказав ChainCatcher, назвавши контракт іменем, під яким його позначили в експлорері, — CrimeEnjoyor.

Іменовані втрати на сьогодні мають такий вигляд:

Два серпневі випадки дають $2,54 млн. На тлі всього року це близько 3,0%: за річним звітом ScamSniffer, за 2025 рік фішинг усіх типів забрав $83,85 млн у 106 106 жертв — на 83% менше у грошах, ніж 2024-го ($494 млн). Тобто вектор не зробив фішинг масовішим; він зробив окремий успішний випадок дорожчим.

Окремо про цифру, яку ви майже напевно зустрінете. Кілька видань переказують, що «63% авторизацій пов’язані зі зловмисними контрактами, підтверджені крадіжки — $2,3 млн», покликаючись на дослідження USENIX Security. Під час перевірки першоджерело не відкривається, а повністю прочитана академічна праця на ту саму тему (та сама arXiv 2512.12174) цих чисел не містить. Ми її не використовуємо — замість неї в тексті стоять 97% Wintermute і $2,54 млн ScamSniffer, у яких є першоджерело, яке відкривається. З тієї ж причини не беремо «80%+ шкідливих делегатів» і «450 000+ скомпрометованих адрес» із третіх переказів: вони не узгоджуються за порядком величини з жодним іншим заміром.

Є і структурний ризик, у якого кількісної оцінки немає ні в кого: chain_id = 0. Академічна праця відтворила встановлення того самого шкідливого делегування у трьох незалежних тестових мережах одним підписом, без жодних додаткових дій жертви і без обміну даними між мережами. Наскільки часто такі авторизації трапляються в дикій природі — не виміряв ніхто, тому відсотка ми не називаємо. Аудитори радять гаманцям за замовчуванням відмовлятися підписувати chain_id = 0.

Логіка цього вектора та сама, що й у решти сучасного полювання на роздрібні гаманці: спустошує не злам, а власний підпис власника. Загальна карта загроз і сервісів перевірки — у розборі безпеки криптогаманця.

Перевірка делегування адреси: eth_getCode і живий приклад 0xef0100

Перевірка триває секунди і не потребує під’єднувати гаманець до сайту. Ідея проста: у звичайного EOA поле коду порожнє, у делегованого — 23 байти, що починаються з 0xef0100.

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

Шлях другий, безпосередньо до ноди. Один запит JSON-RPC, без посередників:

curl -s https://ethereum-rpc.publicnode.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode",
       "params":["0x3fe039C994588575eeFeb861bb82e2cE165F84cB","latest"]}'

Відповідь на блоці 25 866 992 (30 серпня 2026 року) — 0xef010063c0c19a282a1b52b07dd5a65b58948a07dae32b. Розбирається вона так: ef0100 — маркер делегування, решта 20 байтів 63c0c19a282a1b52b07dd5a65b58948a07dae32b — адреса делегата. Це той самий верифікований контракт «MetaMask: EIP-7702 Delegator» із попереднього розділу, тобто перед нами штатно увімкнений смарт-акаунт, а не зараження.

Адреса при цьому жива, а не музейний експонат: на той самий блок eth_getBalance віддає 0,000531651720552358 ETH, а eth_getTransactionCount — nonce 137. Тобто гаманцем користуються, і делегування на ньому стоїть просто зараз.

Що робити з результатом:

1. Коду немає (відповідь 0x) — делегування немає, адреса є звичайним EOA.
2. Код є і починається з ef0100 — делегування є. Відкривайте адресу делегата і дивіться, чи знайомий це контракт.
3. Делегат — офіційний контракт вашого гаманця (як у прикладі вище) — ви самі вмикали смарт-акаунт. Скидання потрібне, лише якщо ця функція вам більше не потрібна.
4. Делегат незнайомий або неверифікований — вважайте адресу скомпрометованою. Спершу виводьте активи на чисту адресу, а вже потім скидайте делегування: саме собою скидання не захищає гроші, якщо ключ витік.
5. Перевіряти доведеться в кожній мережі окремо, де в адреси є активи: код живе у стані конкретної мережі, і в Base його може не бути за наявності в Ethereum.

Окремо про чекери. Сервіси на кшталт revoke.cash та eip7702.app роблять точно те саме автоматично і показують делегування у вкладці Delegations. Але зняти делегування через сторонній сайт не можна: за власною документацією revoke.cash, більшість гаманців не дозволяють зовнішнім dApp вмикати або вимикати делегування — операція мусить іти зсередини застосунку гаманця. Чекати від чекера кнопки «відкликати» не варто, він лише показує.

Як зняти делегування — і чому це не скасовує approvals

Технічно скидання — це та сама авторизація, але з нульовою адресою делегата. Специфікація формулює прямо: адреса повертається до початкового стану, якщо в авторизації вказати нульову адресу. Документація OpenZeppelin уточнює механіку: клієнт не записує новий маркер, а очищає поле коду і повертає хеш коду до порожнього. Тобто делегування фізично стирається, а не «перевказується в нікуди».

В інтерфейсах гаманців це окремі пункти меню:

Скільки це коштує. Транзакція скидання — той самий set-code-tx типу 0x04 з одним кортежем: 21 000 газу базової вартості плюс 12 500 газу за кортеж авторизації для вже наявного акаунта, разом 33 500 газу. Далі звичайна арифметика комісії Ethereum: 33 500 × 0,039182101 Gwei = 0,0000013126 ETH; за курсу $2454,68 за ETH це $0,0032. Обидва вихідні числа зняті 30 серпня 2026 року — газ запитом eth_gasPrice до публічної ноди, курс через API CoinGecko. За газу 10 Gwei (звичайний робочий рівень для завантаженої мережі) та сама операція коштувала б близько $0,82, тобто навіть у дорогий час це менше ніж долар, а не «дорогий ремонт».

Тепер головне попередження, якого не пише майже ніхто. Скидання делегування прибирає тільки маркер 7702. Раніше видані approvals токенів, дозволи Permit і будь-які інші авторизації після цього залишаються активними — прямим текстом це зафіксовано в документації TokenPocket. Власник, який натиснув Reset to EOA і вирішив, що гаманець чистий, помиляється: якщо до делегування він роздав безстрокові approvals фішинговому контракту, той і далі може забрати відповідні токени. Це дві незалежні операції, і другу треба робити окремо — за процедурою з розбору approvals, на який ми покликалися вище.

Порядок дій, якщо делегат виявився чужим, теж важливий. Спершу переказ активів на чисту адресу, потім скидання. Причина в тому, що делегування зазвичай не першопричина, а наслідок: sweeper-сценарій ставлять на адреси з уже витеклим ключем, і після скидання ключ залишиться так само скомпрометованим.

Ризики делегата: гаманець обмежує вибір, а чужий контракт — ні

Сучасні гаманці закривають частину проблеми. MetaMask жорстко прописує адресу власного делегата, тож під час вмикання смарт-акаунта власник не обирає контракт вручну. Rabby виводить делегування в ту саму вкладку Approvals, де видно токен-дозволи, — тобто воно принаймні не є невидимим. Частина гаманців обмежує вибір делегата заздалегідь прошитим списком аудитованих контрактів.

Чого гаманець не робить:

• Не перевіряє довільний контракт, на який просить делегувати сторонній dApp. Якщо підпис запитує не гаманець, а сайт, гарантій немає жодних.
• Не відстежує делегування в інших мережах. Код живе у стані кожної мережі окремо, і адреса з чистим Ethereum може бути делегована в Base.
• Не відкликає approvals під час скидання делегування — див. попередній розділ.
• Не скасовує заднім числом підпис із chain_id = 0. Єдиний захист — відмова підписувати таке, і він працює лише до підпису.

Якщо ви читаєте код делегата самі (загальний порядок — у розборі перевірки смартконтракту перед підписом), аудиторський розбір Zealynx зводить перевірку конкретно делегата до п’яти запитань. Відсутність будь-якого з них перетворює делегата на публічну довіреність:

1. Чи автентифікується виклик проти ключа самого EOA?
2. Чи входить у підпис nonce, що захищає від повтору (replay)?
3. Чи обмежена сума, яку передають?
4. Чи обмежений газ?
5. Чи входять адреса призначення та calldata в те, що підписується?

Межа відповідальності зрештою має такий вигляд: протокол дає механізм і не розрізняє делегатів, гаманець обмежує вибір усередині себе і показує стан, а рішення «чи підписувати цей кортеж на цьому сайті» залишається за власником — і воно незворотне рівно доти, доки делегат не виведе активи.

Першими в цьому матеріалі застаріють числа: курс ETH, ціна газу, лічильники авторизацій на дашборді Wintermute і суми за новими інцидентами перераховуються постійно. Механіка — маркер 0xef0100, склад кортежу, скидання на нульову адресу і вартість у 33 500 газу — задана специфікацією і змінюється лише новим EIP.

FAQ

Чи може делегування EIP-7702 саме собою вкрасти гроші без моєї участі? Встановити делегування без вашого підпису не можна — кортеж підписується вашим ключем. Але після того як воно стоїть, ваша участь більше не потрібна: академічна праця відтворила активацію шкідливого делегата викликом від зловмисника і штатним callback стороннього контракту. Тобто підпис потрібен один раз, а спрацювати код може пізніше і без вас.

Чим делегування 7702 відрізняється від звичайного approve токена? approve() — запис у контракті токена: адреса X може витратити Y конкретних токенів. Авторизація 7702 змінює код самої вашої адреси, після чого делегат виконує будь-який виклик від вашого імені. Радіус ураження різний: в approve — один актив, у делегування — усе, чим керує адреса. І скасовуються вони різними операціями.

Як дізнатися, чи делеговано мою адресу, без встановлення нового гаманця? Досить подивитися код адреси. На Etherscan він видний на сторінці адреси; той самий результат дає один запит eth_getCode до будь-якої публічної ноди. Порожня відповідь 0x означає звичайний EOA, відповідь на кшталт 0xef0100… — активне делегування, де останні 20 байтів і є адресою контракту-делегата. Чекери revoke.cash та eip7702.app роблять саме це автоматично.

Чи знімає скидання делегування раніше видані approvals токенів? Ні. Документація TokenPocket фіксує це прямо: повернення до EOA прибирає лише делегаційний маркер 7702, а approvals токенів, дозволи Permit та інші авторизації залишаються активними. Їх треба відкликати окремою операцією на кожному токені. Гаманець, де натиснули Reset to EOA, чистим автоматично не стає.

Скільки коштує зняти делегування і чи треба робити це в кожній мережі окремо? Скидання — це 33 500 газу: 21 000 базових плюс 12 500 за кортеж авторизації. На 30 серпня 2026 року за газу 0,039182101 Gwei і курсу ETH $2454,68 це $0,0032. Навіть за газу 10 Gwei виходить менше ніж долар. Перевіряти і скидати потрібно в кожній мережі, де в адреси є активи: код зберігається у стані конкретної мережі.

Чи може один підпис скомпрометувати мене одразу в кількох блокчейнах? Так, якщо в кортежі стоїть chain_id = 0. Специфікація прямо дозволяє таке значення, і тоді авторизація валідна в будь-якій EVM-мережі. Академічна праця відтворила встановлення того самого делегування у трьох незалежних тестових мережах одним підписом. Аудитори радять гаманцям за замовчуванням відмовлятися підписувати авторизації з нульовим ідентифікатором мережі.