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

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

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

• Это не разрешение на сумму, а смена кода адреса. Подпись approve() разрешает потратить конкретный токен на конкретную сумму. Авторизация 7702 делает делегата исполнителем любого вызова от имени адреса. Формулировка Curvegrid точна: делегация ближе к установке программы, чем к разрешению платежа.
• Механизм задумывался как UX-апгрейд. Спецификация даёт три сценария: пакетные транзакции, оплата газа третьей стороной и временные ключи сессии. Именно из-за них опцию «умного аккаунта» встроили 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: от первой транзакции до профи-стратегий».

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

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

Риски DeFi по слоям: два взлома дали 44% потерь, и оба — не баг кода

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

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

Взлом моста KelpDAO на $293 млн: 1-of-1 DVN, 46 минут и долг Aave до $230 млн

Крипто мосты между сетями: три схемы, цена от $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: делегация — это ближе к установке программы, чем к разрешению платежа. Программу вы ставите один раз, а работает она потом сама.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

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

Прежде чем разбирать злоупотребления, стоит понять, зачем механизм вообще внедряют. Документация 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-сети. Академическая работа воспроизвела установку одной и той же делегации на трёх независимых тестовых сетях одной подписью. Аудиторы рекомендуют кошелькам по умолчанию отказываться подписывать авторизации с нулевым идентификатором сети.