EIP-7702 delegation в 2026 году: как проверить и отозвать делегацию кошелька

EIP-7702 delegation — это механизм, появившийся в экосистеме Ethereum после Pectra, который позволяет обычному адресу EOA сохранить прежний адрес и приватный ключ, но начать исполнять логику выбранного smart-contract implementation. Для пользователя это может означать удобные batch-операции, sponsorship gas, session permissions и другие функции smart wallet. Для злоумышленника тот же механизм создаёт новый класс фишинга: вместо отдельного approve или одной вредной транзакции жертву можно убедить подписать авторизацию, после которой поведение знакомого адреса определяется делегированным кодом.

Поэтому вопрос «как проверить EIP-7702 delegation» нельзя сводить к просмотру списка подключённых сайтов. Подключение dApp, ERC-20 allowance, Permit, WalletConnect-сессия и EIP-7702 delegation — разные уровни полномочий. Отключение сайта не снимает on-chain делегацию, а отзыв token approval не возвращает delegated EOA в обычное состояние. В этой инструкции разобран именно EIP-7702: как понять, что делегация существует, кому она указывает, в какой сети действует, как оценить delegate contract, как безопасно сбросить делегацию и когда вместо простого revoke нужен новый кошелёк.

Отдельной подтверждённой wide/exact частотности у русскоязычного long-tail «EIP-7702 delegation» в доступной сохранённой выгрузке нет, поэтому цифры для него не моделируются. Числовая родительская семантическая опора — запрос «крипта кошелек»: Bukvarix wide 6 971, exact 548. Внутри статьи естественно используются связанные формулировки: «EIP-7702 фишинг», «делегация кошелька», «как проверить delegation», «как отозвать EIP-7702», «SetCode transaction», «authorization list», «delegate contract», «smart account» и «chain_id 0».

Главное правило: если вы не понимаете, какой contract получает EIP-7702 delegation и зачем он нужен вашей операции, не подтверждайте авторизацию. Если подозрительная делегация уже установлена, сначала зафиксируйте сеть, delegate address и состояние активов, затем используйте штатный механизм кошелька для удаления делегации; при утечке seed/private key одного revoke недостаточно.

Что именно меняет EIP-7702 и почему привычный адрес становится программируемым

Чтобы правильно оценить инцидент, нужно отделить адрес от логики, которую он исполняет. До EIP-7702 пользователь обычно воспринимал EOA как простой аккаунт, управляемый одним приватным ключом. После делегации адрес остаётся тем же, история и балансы не переезжают, но вызовы могут исполнять код другого контракта. Именно это сочетание — знакомый адрес плюс изменившаяся модель выполнения — делает EIP-7702 одновременно полезным и опасным.

EOA до делегации: ключ подписывает, адрес не содержит прикладной логики

Классический externally owned account определяется приватным ключом и nonce. Сам по себе такой адрес не хранит произвольную пользовательскую программу, поэтому большинство сложных сценариев реализуются внешними smart contracts: approve, swap, staking, bridge. Это формирует понятную психологическую модель: если пользователь ничего не подписывает и ключ не украден, обычный EOA не должен внезапно начать исполнять новую политику расходования средств.

После появления EIP-7702 этой модели недостаточно. При расследовании нельзя делать вывод «это мой старый адрес, значит он обычный». Проверяемым объектом становится не только owner key, но и code state аккаунта. Если код содержит delegation indicator, адрес необходимо рассматривать как программируемый account до тех пор, пока делегация не снята и результат не проверен в конкретной сети.

Delegation indicator: указатель на код, а не перенос активов

Спецификация EIP-7702 записывает в code аккаунта короткий delegation indicator с префиксом 0xef0100 и адресом реализации. Балансы ETH и токенов при этом не «переезжают» в delegate contract. Когда выполнение направляется на delegated EOA, клиент следует указателю и исполняет код реализации в контексте аккаунта пользователя. Поэтому визуально активы могут оставаться на том же адресе, хотя фактические правила выполнения уже изменились.

Это различие критично при анализе explorer. Наличие денег на знакомом адресе не доказывает безопасность. Нужно установить, есть ли у адреса code, соответствует ли он формату delegation indicator и на какой implementation указывает. Не отправляйте дополнительные активы на адрес только потому, что баланс и последние входящие переводы выглядят привычно.

Transaction type 4 и authorization list

EIP-7702 вводит новый тип транзакции с authorization list. В каждом authorization tuple фиксируются chain_id, адрес delegate implementation, nonce и компоненты подписи. С точки зрения пользователя важна не криптография полей, а смысл: подпись подтверждает право изменить code state конкретного authority account. Это полномочие потенциально шире обычного разрешения потратить один токен определённому spender.

В интерфейсе кошелька ищите не только сумму и gas. Для EIP-7702 особенно важны слова SetCode, delegation, authorization, smart account upgrade и адрес implementation. Если UI скрывает delegate address или показывает его сокращённо без возможности сверки, такая операция не подходит для основного кошелька. Для существенной суммы используйте приложение, которое явно раскрывает цель делегации.

Почему делегация сохраняется после завершения одного действия

Авторизация EIP-7702 меняет состояние аккаунта в сети, а не создаёт одноразовую браузерную сессию. После выполнения исходной транзакции delegation может продолжить существовать, пока не будет заменена или сброшена. Поэтому закрытие вкладки, удаление dApp из Connected Sites и даже очистка браузера не возвращают account к прежней модели. Пользователь может забыть о делегации, а она останется частью on-chain состояния.

После любой операции, где кошелёк предложил upgrade или smart-account capability, полезно записать chain ID, delegate address и назначение. Если функция была нужна только временно, проверьте, предусмотрен ли штатный downgrade/revoke. Не путайте «сессия закончилась» с «делегация снята» — это разные события.

Приватный ключ не исчезает после превращения EOA в smart account

EIP-7702 не уничтожает исходную ключевую модель: приватный ключ EOA сохраняет фундаментальное право авторизовывать действия. Это означает две вещи. Во-первых, легитимная делегация не делает адрес автоматически multisig — один исходный ключ остаётся критическим. Во-вторых, если seed-фраза или private key украдены, злоумышленник может создавать новые авторизации даже после того, как пользователь снял одну вредную delegation.

При инциденте всегда отвечайте на отдельный вопрос: была скомпрометирована только конкретная подпись delegation или раскрыт сам ключ? В первом случае revoke и аудит permissions могут восстановить приемлемое состояние. Во втором правильной конечной точкой обычно является новый кошелёк с новой seed-фразой, а не бесконечная борьба с авторизациями на старом адресе.

Делегация не равна «переводу кошелька в контракт» навсегда

Пользовательский адрес сохраняет идентичность и может снять delegation. Спецификация предусматривает очистку code state через авторизацию на нулевой адрес. Поэтому сама по себе EIP-7702 delegation не является необратимой миграцией. Но возможность отзыва не делает риск маленьким: вредоносная реализация может успеть переместить активы до того, как владелец поймёт, что подписал.

Оценивайте две временные линии: состояние delegation сейчас и уже произошедшие transfers. Revoke прекращает будущую delegated логику, но не отменяет подтверждённые on-chain переводы. После снятия делегации обязательно исследуйте историю активов отдельно — ETH, ERC-20, NFT, staking positions и approvals.

Почему вредоносная EIP-7702 delegation опаснее обычного фишингового подключения

Главная ошибка в оценке EIP-7702 — применять к нему старый чек-лист «отключить сайт и отозвать approve». Эти действия полезны, но они не отвечают на вопрос, какой код теперь связан с EOA. Делегация меняет доверительную границу самого аккаунта. Поэтому отдельный анализ нужен даже тогда, когда в списке allowances нет ничего подозрительного.

Фишинг под видом «обновления кошелька»

Самый понятный социальный сценарий — предложение «обновить» обычный кошелёк до smart wallet, включить gasless, активировать новый security mode или получить бонус. Пользователь может не видеть денежного перевода и решить, что подписывает безопасную настройку. Но предметом подписи становится authorization на конкретный delegate contract, а не косметическая функция интерфейса.

Проверяйте источник запроса. Настоящая новая функция должна быть объяснена в официальном приложении или документации конкретного wallet provider, а target implementation — однозначно идентифицируем. Не принимайте ссылку из рекламы, личного сообщения, Telegram-чата или письма как достаточное основание для account upgrade.

Один delegate contract может получить гораздо более широкую поверхность действий

Token approval обычно ограничен конкретным token contract, spender и amount. Delegated account code способен определять, как account реагирует на вызовы и какие дополнительные механизмы подписи, batching или execution доступны. Если реализация вредоносна или уязвима, риск затрагивает не один allowance, а архитектуру исполнения всего адреса в этой сети.

Из-за этого анализируйте delegate implementation как критическую часть wallet security. Недостаточно увидеть известное название сайта. Нужны точный адрес, происхождение кода, возможность upgrade, права owner/admin и репутация реализации. Если проверка невозможна, считайте делегацию неприемлемой для кошелька с крупным резервом.

chain_id=0 расширяет область риска за пределы одной сети

Authorization tuple может быть привязан к конкретному chain ID либо использовать ноль. Chain ID 0 означает, что подпись не ограничена одной EVM-сетью. Это особенно опасно для адреса, который пользователь применяет одновременно в Ethereum, Base, Arbitrum, BNB Chain, Polygon и других сетях: одна ошибочная авторизация потенциально создаёт поверхность для повторного применения там, где условия совпадут.

Не делайте вывод «я подписал это в сети X, значит остальные сети не затронуты». При подозрении на chain-agnostic authorization составьте список всех EVM-сетей, где этот адрес когда-либо имел активы, и проверьте code state отдельно. Ревокация и доказательства также должны быть привязаны к каждой фактически затронутой сети.

Proxy и изменяемая логика повышают долгосрочный риск

Если delegate address ведёт на upgradeable proxy, пользователь делегирует не только текущему коду, но и системе управления будущими изменениями implementation. Сегодня логика может выглядеть безопасно, а завтра admin заменит её. Именно поэтому официальные рекомендации Ethereum для EIP-7702 подчёркивают минимальную доверенную поверхность и осторожность с прокси.

Проверяйте, является ли target immutable implementation или proxy. Если proxy используется легитимным продуктом, нужно понимать admin model, timelock, аудит и политику обновлений. Для самостоятельного основного кошелька неизвестный proxy без публичной модели управления — серьёзный stop signal.

Batching скрывает несколько действий за одной понятной кнопкой

Одна из полезных целей smart accounts — объединять approve, swap, transfer и другие действия в пакет. Но та же возможность ухудшает восприятие риска, если интерфейс показывает только итоговую кнопку «Swap» или «Claim». Пользователь должен понимать не бренд функции, а список реально выполняемых calls, recipients и spend permissions.

Перед первой высокорисковой операцией на новом delegated account используйте wallet, который раскрывает batch. Сверяйте target каждого значимого вызова, token amounts и approvals. Если интерфейс показывает «одобрить пакет» без детального preview, проведите операцию тестовым рабочим кошельком, а не резервным адресом.

Delegated code может сработать не в тот момент, когда пользователь ожидает

Исследования EIP-7702 обращают внимание на сценарии, где опасная логика активируется не только непосредственным пользовательским кликом. В зависимости от implementation и интеграции внешние вызовы, relayer или account-abstraction pipeline могут участвовать в исполнении. Это меняет привычную интуицию «если я больше ничего не подпишу, ничего не произойдёт».

После обнаружения неизвестной delegation не откладывайте проверку до следующей операции. Сначала ограничьте активность адреса, зафиксируйте состояние и определите безопасный способ revoke. Не тестируйте подозрительный account случайными входящими переводами: дополнительный баланс может увеличить потенциальный ущерб.

Научная статистика полезна как сигнал, но не заменяет анализ конкретного адреса

Работа USENIX Security 2026 сообщила о сотнях обнаруженных вредоносных contract accounts и существенной доле подозрительных EIP-7702 authorizations в исследованном наборе данных. Такие цифры показывают, что риск не теоретический. Но они зависят от методологии, выбранных сетей, периода наблюдения и критериев классификации, поэтому их нельзя превращать в утверждение, что большинство любой EIP-7702 активности в мире вредоносно.

Для пользователя вывод практический: EIP-7702 требует повышенной проверки, но легитимные implementations существуют. Решение принимается по target contract, источнику wallet feature, chain scope, auditability и фактической истории аккаунта, а не по одному страшному проценту из исследования.

Как проверить, установлена ли EIP-7702 delegation на вашем адресе

Проверка строится от простого к техническому: сначала штатный интерфейс кошелька, затем block explorer и code state, затем история authorization. Не требуется писать собственный контракт или собирать raw transaction. Цель пользователя — получить несколько независимых доказательств одного состояния: адрес действительно delegated либо code пустой.

Начните с официального интерфейса кошелька

Современный wallet или hardware companion может показывать, что account работает как smart account, какой implementation используется и есть ли кнопка удаления delegation. Такой путь предпочтителен, потому что приложение знает собственную модель аккаунта и может отличить штатный upgrade от неизвестного кода. Однако отсутствие заметного бейджа не является абсолютным доказательством отсутствия EIP-7702.

Откройте account details и security/permissions разделы только в официальном приложении. Зафиксируйте адрес, сеть и любые поля Smart Account, Delegation, Upgrade, Implementation. Если интерфейс предлагает Remove/Disable, не нажимайте автоматически: сначала запишите текущий delegate address, чтобы после revoke можно было доказать, что именно было удалено.

Проверьте code state адреса через независимый explorer или RPC

У delegated EOA code больше не пустой. На уровне EIP-7702 специальный indicator содержит префикс 0xef0100 и адрес delegate implementation. Некоторые обозреватели уже распознают этот формат и отображают Delegated to / EIP-7702. Другие показывают просто code. Для экспертной проверки важно сравнить данные из кошелька с независимым explorer или RPC-провайдером.

Не вводите seed-фразу и не подключайте кошелёк ради просмотра публичного code. Адрес — публичные данные. Если используете технический RPC-инструмент, запрос должен быть read-only; никакая подпись для чтения code не требуется. Любой «checker», который требует seed/private key, является красным флагом.

Поймите значение префикса 0xef0100

В спецификации EIP-7702 delegation indicator — короткая конструкция 0xef0100 плюс 20-байтовый адрес. Это не обычный bytecode приложения и не доказательство вредоносности само по себе. Префикс говорит, что выполнение должно следовать к target. Главная аналитическая задача начинается после его обнаружения: извлечь delegate address и идентифицировать реализацию.

Сохраните полный code result и target address в текстовом виде. Не полагайтесь на сокращение 0x1234…abcd из UI. Для сравнения с официальной документацией и explorer нужен полный адрес. Ошибка в одной цифре превращает проверку известной реализации в проверку совершенно другого контракта.

Найдите transaction, которая установила delegation

История account может содержать type-4 transaction или authorization data, через которые code state был установлен. Полезно определить дату, инициатора, chain, nonce и target implementation. Это связывает технический факт с пользовательским событием: например, вы действительно включали smart wallet в конкретном приложении или делегация появилась после посещения подозрительной страницы.

Сохраните transaction hash и временную метку. Если вы не узнаёте событие, не спешите делать вывод о краже private key: authorization могла быть подписана внутри плохо понятного UX. Но уровень риска уже высокий — дальнейшие действия выполняйте как при security incident, пока происхождение не установлено.

Сравните delegate address с официальной реализацией wallet provider

Легитимный wallet должен иметь документируемый или иным способом верифицируемый implementation. Сравнение проводится по полному адресу в конкретной сети. Название контракта в explorer недостаточно: метки могут отсутствовать, быть пользовательскими или относиться к другому deployment. Надёжнее сочетать официальный источник продукта, verified source code и независимый explorer.

Если официальный provider нигде не подтверждает target, запросите поддержку через официальный канал, не через контакт из транзакции или токен-спама. До получения ответа не используйте неизвестную delegation для крупной операции. Отсутствие мгновенного ответа поддержки не делает контракт вредоносным, но не снимает необходимость проверки.

Проверьте каждую сеть, где адрес реально использовался

Одинаковый EVM-адрес может иметь разные balances, nonce и code state в разных chains. Пользователь часто проверяет только Ethereum mainnet, хотя активность была в Base, Arbitrum или BNB Chain. Кроме того, chain_id=0 в authorization расширяет возможную область применения. Поэтому расследование строится по inventory сетей, а не по одной вкладке explorer.

Составьте список сетей из истории кошелька, bridge, биржевых выводов и token balances. На каждой проверьте code state публичного адреса. Если сеть неизвестна или заброшена, не отправляйте туда gas только ради эксперимента; сначала выясните, есть ли там активы или действующая delegation.

Не путайте отсутствие token approvals с отсутствием delegation

Сервисы revoke часто показывают allowance, NFT operators и Permit2, но могут не отображать EIP-7702 code state как обычное разрешение. Пользователь видит «0 approvals» и делает ложный вывод, что кошелёк чист. Это разные механизмы хранения полномочий. Делегация проверяется через account code и authorization history.

Если инцидент начался после подписи неизвестного сообщения или «upgrade», используйте два параллельных чек-листа: EIP-7702 delegation и token approvals/permits. Снятие одного не отменяет другой. На OneMagic отдельная инструкция о подписанной транзакции полезна именно для второго контура: проверка разрешений после подключения кошелька.

Как оценить delegate contract: легитимный smart wallet или опасная реализация

Обнаружить delegation недостаточно: многие нормальные продукты используют EIP-7702 по назначению. Следующий этап — оценка implementation. Для пользователя это похоже на аудит приложения с повышенной критичностью, потому что код фактически расширяет возможности его EOA.

Происхождение implementation должно быть проверяемым

Первый критерий — кто утверждает, что этот адрес принадлежит нужному wallet provider. Надёжная цепочка начинается в официальной документации, репозитории или приложении продукта и заканчивается тем же полным адресом в explorer. Поисковая реклама, Discord-сообщение или метка неизвестного обозревателя не являются первичным источником.

Сделайте независимое сравнение минимум по двум каналам: официальный источник и blockchain explorer. Если адрес сообщила «поддержка» в личном сообщении, считайте его непроверенным до подтверждения на сайте продукта. Не отправляйте ETH для «активации контракта» — проверка публичного implementation не требует платежа.

Verified source облегчает анализ, но не является сертификатом безопасности

Наличие верифицированного исходного кода позволяет сопоставить bytecode и изучить функции. Это полезнее, чем контракт без исходников, но само по себе не доказывает отсутствие backdoor. Важны архитектура ownership, возможности execute, upgrade, signature validation, recovery, modules и ограничения. Даже открытый код может быть сложным или уязвимым.

Для крупного резерва не превращайте самостоятельное чтение Solidity в единственную защиту. Ищите публичные аудиты, зрелость implementation и применение крупным wallet provider. Если контракт новый и малоизвестный, используйте отдельный operational wallet с ограниченным балансом, а не основной адрес.

Immutable implementation предпочтительнее неизвестного proxy

Официальные рекомендации EIP-7702 подчёркивают, что делегирование прокси-контракту увеличивает доверительную поверхность. Proxy может сохранять адрес, но менять underlying logic. Пользователь фактически доверяет не только текущему коду, но и admin key, governance, timelock и процедуре upgrade. Для вредоносного сервиса это удобный способ показать безопасную версию, а затем заменить её.

В explorer проверьте признаки proxy и implementation address. Если продукт легитимно использует upgradeability, выясните, кто администратор и какие есть задержки/ограничения. Не считайте известное имя proxy достаточным подтверждением — критична конечная реализация и модель её обновления.

CREATE2 и одинаковый адрес в разных сетях требуют отдельной проверки

При cross-chain сценариях разработчики могут использовать CREATE2 для предсказуемого адреса implementation. Но одинаковый адрес в нескольких сетях сам по себе не гарантирует одинаковый bytecode. Без корректной модели deployment на другой chain по тому же адресу теоретически может существовать иной код. Поэтому chain-agnostic delegation особенно чувствительна к идентичности реализации по сетям.

Проверяйте code hash или verified code на каждой релевантной сети, если authorization не ограничена одной chain. Не копируйте вывод «адрес безопасен в Ethereum» на BNB Chain или Base без проверки. Для пользователя это дополнительный аргумент избегать chain_id=0, если функция не требует межсетевой авторизации.

Права execute важнее красивого интерфейса

Smart account implementation обычно имеет механизм исполнения вызовов. Без него batching и account abstraction были бы невозможны. Риск определяется тем, кто и при каких условиях может инициировать execute: только исходный owner key, session key с лимитами, EntryPoint по валидной подписи, guardian scheme или иной модуль. Ошибка в authentication способна превратить полезную функцию в drain primitive.

Вместо вопроса «есть ли функция execute?» задавайте вопрос «какая authorization policy окружает execute?». Для непрофессионального пользователя ответ должен исходить из документации и аудита продукта. Если сервис обещает полный smart-wallet функционал, но не объясняет модель подписи и recovery, это слабая основа для делегации основного адреса.

Session permissions должны уменьшать полномочия, а не маскировать полный доступ

Одна из сильных идей account abstraction — ограниченные subkeys: например, разрешение взаимодействовать с одной игрой или тратить небольшой лимит. Но интерфейс может использовать термин «session» даже тогда, когда underlying delegation остаётся широкой. Важно отделить persistent delegate implementation от временных прав внутри него.

Проверьте, где хранится session permission, когда истекает и может ли оно выполнять transfer/approve произвольных токенов. Отзыв session key не обязательно снимает EIP-7702 delegation. Если вы хотите вернуть адрес к обычному EOA, нужен именно revoke/reset delegation, а не только logout dApp.

Публичный аудит должен соответствовать той версии кода, которой вы делегируете

Фраза «контракт прошёл аудит» полезна только при совпадении scope. Аудит старой версии, другого implementation или frontend не покрывает текущий target. Особенно осторожно относитесь к proxy: аудит implementation v1 не говорит о будущем upgrade. Для mature wallet обычно есть версия, commit, deployment address и история изменений.

Сохраните ссылку или название аудита в собственный журнал, если делегация используется для существенных активов. Это не нужно для каждой мелкой операции, но помогает при incident response: вы быстрее понимаете, был ли риск известным, связан ли он с upgrade или с фишинговым target.

Что делать, если вы уже подписали подозрительную EIP-7702 delegation

При подозрительной подписи скорость важна, но хаотичные действия опасны. Нельзя просто «тыкать revoke» на первом найденном сайте: можно попасть на второй фишинг или потерять доказательства. Нужен порядок — зафиксировать состояние, определить область риска, выбрать доверенный инструмент удаления delegation и проверить результат.

Прекратите взаимодействие с исходным сайтом и не подписывайте «исправление»

Если подозрение возникло после сайта, pop-up или чата, не продолжайте сценарий. Мошеннические страницы часто показывают вторую кнопку Restore, Cancel, Verify или Revoke, которая на самом деле создаёт новую подпись. Закрытие страницы не снимает делегацию, но прекращает дополнительный социальный контроль и снижает вероятность серии ошибочных подписей.

Сохраните URL и скриншот без повторного подключения. Затем откройте кошелёк напрямую из установленного приложения. Если сайт просит seed-фразу «для отмены», это отдельный критический признак компрометации. Общий план после подозрительного dApp разобран в статье что делать после подключения кошелька к подозрительному сайту.

Зафиксируйте delegate address, сеть и transaction hash до revoke

После удаления delegation доказать её прежнее состояние сложнее. До изменения account code запишите полный authority address, chain ID, delegate target, transaction hash установки, nonce, время и текущие балансы. Если есть suspicious transfers, сохраните их hashes отдельно. Эти данные полезны для wallet support, forensic analysis и объяснения происхождения действий.

Не публикуйте seed/private key вместе с доказательствами. Публичный адрес и TXID безопасны для технического анализа; секреты — нет. Для документирования можно использовать отдельный файл или офлайн-заметку. OneMagic рекомендует сохранять технические артефакты аналогично обычному криптопереводу: какие TXID, адреса и скриншоты хранить.

Сначала используйте штатный revoke кошелька или известного provider

Наиболее безопасный пользовательский путь — функция Remove delegation / Disable smart account в официальном wallet, который создал делегацию. Такой интерфейс должен сформировать корректную авторизацию на null/zero address и показать, что действие относится к вашему account. Это снижает риск ошибок при ручной работе с новым типом транзакций.

Если официального revoke нет, не переходите к случайному «EIP-7702 revoke tool» из поисковой рекламы. Обратитесь в официальный support provider или используйте хорошо проверенный open-source инструмент, понятный специалисту. Цель одинакова: сбросить delegation, не подписав новую неизвестную implementation.

Механика сброса: делегирование на нулевой адрес

Спецификация EIP-7702 предусматривает очистку delegation indicator, когда authorization указывает на zero address. В результате code hash authority возвращается к empty code. Пользователю не обязательно вручную собирать tuple: хороший wallet делает это сам. Важно понимать смысл, чтобы отличить настоящий revoke от интерфейса, который просто удаляет локальную запись.

После подтверждения revoke дождитесь on-chain включения и проверьте code state заново. Статус Success транзакции — необходимое, но не единственное доказательство. Конечный критерий: delegation indicator отсутствует в этой сети. Если wallet по-прежнему показывает smart account, разберитесь, не установлена ли новая delegation последующим действием.

Не пытайтесь «отозвать» EIP-7702 через обычный token approval checker

Revoke ERC-20 allowance меняет storage токен-контракта. EIP-7702 revoke меняет code state authority account. Это разные транзакции и разные доказательства результата. Approval checker может быть полезен как часть полной зачистки после фишинга, но нулевой allowance не снимает delegate code.

После удаления delegation отдельно просмотрите allowances, Permit2 и NFT operators, если подозрительный сайт запрашивал несколько подписей. Это снижает остаточный риск. Не делайте обратную ошибку: наличие старого harmless allowance не означает, что revoke EIP-7702 не сработал — каждый механизм оценивается отдельно.

Проверьте активы сразу после снятия delegation

Revoke не возвращает уже украденные активы и не отменяет транзакции. Сверьте native coin, основные ERC-20, NFT и позиции DeFi до и после инцидента. Для каждого неизвестного transfer установите hash, recipient и время. Иногда пользователь видит нулевой баланс токена не из-за кражи, а из-за UI или другой сети; решение должно опираться на explorer.

Для USDT и других токенов проверяйте именно on-chain transfer events. Не переводите «оставшиеся средства» на адрес, предложенный неизвестной поддержкой. Если нужно мигрировать активы на новый wallet, адрес назначения должен быть создан вами в доверенной среде и проверен тестовым переводом.

Если есть признаки украденного private key, простой revoke не завершает incident

Когда злоумышленник знает seed-фразу или private key, он способен снова авторизовать изменения и подписывать обычные транзакции. Снятие одной delegation в такой модели лишь временно меняет состояние. Ключ уже нельзя сделать секретным. Безопасная цель — новый независимый wallet с новой seed-фразой и перенос доступных активов по контролируемому плану.

Не импортируйте старую seed-фразу в «новое приложение» и не называйте это миграцией. Это тот же ключевой материал. Создайте новый wallet на чистом устройстве или hardware wallet, проверьте резервную копию и затем переносите активы. Общие правила защиты ключей — в материале как защитить криптокошелёк.

Cross-chain риск: почему одну и ту же EIP-7702 подпись нужно оценивать по нескольким сетям

EVM-адрес визуально одинаков в разных сетях, но состояние account существует отдельно в каждой chain. Это создаёт двойную ловушку: пользователь может недооценить межсетевой риск chain_id=0 и одновременно переоценить действие revoke в одной сети. Правильная модель — отдельная карточка состояния для каждой релевантной chain.

chain_id привязывает authorization к области применения

В authorization tuple chain_id служит доменным разделителем. Конкретный chain ID ограничивает подпись соответствующей сетью, тогда как значение 0 допускает использование для любых chain IDs при выполнении остальных условий. Для UX «работает везде» может звучать удобно, но для безопасности это расширяет последствия ошибки.

Перед легитимной delegation спросите, действительно ли продукту нужна chain-agnostic authorization. Для основного кошелька предпочтительна минимальная область полномочий. Если вы уже подписали chain_id=0 неизвестному target, переходите от проверки одной сети к полной инвентаризации EVM-активности.

Одинаковый адрес пользователя не означает одинаковое состояние delegation

Ethereum, Base, Arbitrum, Optimism, BNB Chain и другие сети ведут собственное состояние. В одной chain account может быть delegated, в другой code останется пустым. Поэтому интерфейс одного explorer не способен подтвердить безопасность остальных сетей. Даже нулевой баланс сегодня не исключает исторические токены, staking claims или будущие входящие переводы.

Проверяйте сети, где адрес когда-либо использовался, а не случайный список из сотен chains. Источниками inventory служат история wallet, биржевые withdrawal records, bridge operations и token trackers. Это даёт управляемый scope без бессмысленной отправки gas во все возможные сети.

Delegate implementation по тому же адресу может отличаться между chains

Cross-chain безопасность зависит не только от одинакового authority address, но и от того, какой код существует по delegate target. Даже при визуально одинаковом адресе deployment context может различаться. Если chain-agnostic authorization применяется к сети, где target-код другой или контролируется иначе, фактическая политика account тоже может стать другой.

Сравнивайте verified code или code hash implementations на релевантных сетях. Не делайте вывод по одному ENS-name или UI label. Для непрофессионального пользователя безопаснее использовать wallet provider, который сам ограничивает допустимые implementations и документирует поддержку сетей.

Revoke в Ethereum не очищает автоматически состояние другой chain

Сброс delegation — on-chain state transition конкретной сети. Если неизвестный delegation уже установлен в нескольких chains, его нужно подтвердить и удалить там, где он реально присутствует. Одна успешная transaction в Ethereum mainnet не меняет Base или BNB Chain. Это особенно важно после chain_id=0 authorization.

После каждого revoke записывайте chain, transaction hash и результат code check. Не путайте список «проверено» со списком «нужно оплатить gas»: если delegation в сети отсутствует, ничего отзывать там не требуется. Read-only проверка должна предшествовать любой платной операции.

Нулевой баланс не всегда делает сеть неважной

Адрес может иметь NFT, claimable rewards, позиции в protocol или токены, которые wallet не показывает по умолчанию. Кроме того, контрагент может позже отправить активы на старый публичный адрес. Если он скомпрометирован делегацией, новый входящий баланс снова окажется под риском, даже если сегодня на chain пусто.

После серьёзного incident обновите адреса для регулярных поступлений: выплаты, OTC-контакты, биржевые whitelist, ENS/профили и бухгалтерские реквизиты. Не ограничивайте безопасность моментальным sweep. Коммуникационная миграция важна так же, как техническая.

Gas для revoke должен поступать безопасным способом

Для on-chain revoke понадобится native gas конкретной сети, если wallet не использует sponsorship. На скомпрометированный account иногда опасно отправлять крупный gas reserve: неизвестная логика или украденный ключ могут использовать его. Размер пополнения должен быть минимально достаточным, а маршрут — контролируемым.

Не следуйте инструкциям неизвестных «rescue experts», которые требуют внести большую сумму для разблокировки revoke. Если account полностью под контролем атакующего, самостоятельный rescue может требовать специализированной помощи. Сначала определите модель компрометации и только затем финансируйте gas.

Bridge не является инструментом отзыва delegation

Перевод активов между сетями через bridge изменяет местонахождение токенов, но не code state authority. Попытка «уйти в другую сеть» не удаляет EIP-7702 delegation. Более того, bridge добавляет approvals, contracts и новые транзакции, усложняя инцидент. Это плохой первый шаг, если цель — восстановить контроль.

Сначала стабилизируйте account: revoke или миграция на новый ключевой материал. Затем решайте, где хранить активы. Любой bridge после incident должен быть отдельным осознанным действием, а не панической попыткой скрыться от malicious delegate.

Как отличить компрометацию delegation от утечки seed-фразы или private key

Одинаковый симптом — неожиданное списание — может иметь разные причины. Ошибка диагностики приводит к неправильному лечению: пользователь отзывает approvals, когда украден seed, или выбрасывает безопасный hardware wallet после одной фишинговой подписи. Нужна модель доказательств.

Одна подозрительная authorization ещё не доказывает утечку seed

Пользователь мог сам подписать EIP-7702 authorization, не поняв интерфейс. В таком случае атакующий получил конкретное on-chain полномочие, но не обязательно приватный ключ. Если после revoke неизвестные обычные транзакции не появляются, а секрет нигде не вводился, есть основания разделять signature compromise и key compromise.

Восстановите временную линию: где была подпись, был ли ввод seed, устанавливался ли APK/extension, передавался ли backup «поддержке». Не полагайтесь на память одной минуты — просмотрите browser history, wallet activity и installed apps. Вывод о key leak должен опираться на факты, но при сомнении выбирайте более консервативную миграцию.

Неизвестные обычные транзакции могут указывать на stolen key

Если с адреса исходят корректно подписанные операции, которые невозможно объяснить delegated logic или известными modules, подозрение на утечку ключа усиливается. Однако EIP-7702 implementation способна усложнять attribution, поэтому простой признак «tx.from мой адрес» недостаточен. Нужен анализ способа исполнения и authorization state в момент события.

Сохраните hashes и обратитесь к специалисту, если сумма существенна. Не отправляйте private key для «проверки подписи»: ownership можно доказывать публичными данными и контролируемой подписью сообщения, если это вообще требуется. Секрет не нужен исследователю для чтения блокчейна.

Hardware wallet защищает ключ, но не от ошибочного подтверждения на устройстве

Аппаратный кошелёк существенно снижает риск кражи private key с компьютера, но пользователь всё равно может физически подтвердить опасную authorization. Если устройство показывает неполные данные или приложение маскирует delegation как понятную операцию, human approval остаётся точкой риска. Поэтому EIP-7702 требует хорошего transaction display, а не только hardware isolation.

При hardware wallet incident не сбрасывайте seed автоматически, если нет признаков leak. Сначала проверьте, какую именно authorization вы подтвердили и к какому target. Но если seed вводилась на компьютере/сайте или фотографировалась, аппаратная защита уже не компенсирует раскрытие — создайте новый ключевой набор.

Malware может менять интерфейс и одновременно красть секреты

Поддельное расширение или APK — более тяжёлый сценарий, чем один фишинговый сайт. Оно может подменять delegate address, адреса переводов, перехватывать clipboard и собирать seed, если пользователь её вводит. Поэтому после обнаружения фейкового wallet app нельзя ограничиваться revoke EIP-7702 на том же устройстве.

Используйте чистое устройство или hardware wallet для нового аккаунта. Проверьте официальность приложения по независимым источникам. OneMagic отдельно разбирает этот риск в материале как проверить приложение криптокошелька.

Миграция на новый wallet означает новую seed-фразу

Импорт старой seed-фразы в другой бренд приложения меняет интерфейс, но не ключи и адреса. Если исходный секрет скомпрометирован, злоумышленник сохраняет доступ. Настоящая миграция создаёт новый entropy/seed, проверяет резервную копию и переносит активы на новые адреса. Старый account затем считается публично скомпрометированным идентификатором.

Перед переносом проверьте новый receive address на устройстве, выполните тест для существенной суммы и обновите whitelist/контакты. Если старый адрес используется для регулярных входящих, уведомите отправителей. Не уничтожайте доказательства старого incident до завершения бухгалтерского и forensic учёта.

Пустой восстановленный кошелёк не означает кражу EIP-7702

После panic migration пользователи иногда восстанавливают seed и видят другой account path, сеть или скрытый токен, принимая это за drain. Это отдельная проблема derivation/network display. EIP-7702 delegation привязана к конкретному authority address в конкретной chain, поэтому сначала убедитесь, что сравниваете тот же адрес.

Если приходится восстанавливать доступ, используйте официальное приложение и сверяйте эталонные публичные адреса. Пошаговая логика восстановления есть в статье как восстановить криптокошелёк по seed-фразе. Никогда не вводите seed в онлайн «EIP-7702 checker».

После key compromise старый адрес нельзя считать безопасным из-за нулевой delegation

Даже если code очищен и все approvals отозваны, украденный private key остаётся действующим. Атакующий может подписывать обычные транзакции или новые authorizations. Состояние «delegation = none» описывает только один слой account, а не секретность ключа. Это фундаментальное различие должно быть зафиксировано в incident report.

Пометьте старый адрес как compromised в собственном учёте, удалите его из whitelist получателей и не используйте для будущих накоплений. Если какие-то protocol positions нельзя перенести сразу, нужен отдельный план закрытия позиции с минимальным временем экспозиции.

EIP-7702 delegation, approvals, Permit, WalletConnect и paymaster: что именно нужно отзывать

В 2026 году один dApp может одновременно использовать несколько уровней авторизации. Пользователь подключает wallet, подписывает typed data, выдаёт ERC-20 allowance, включает smart account и получает sponsored gas. После инцидента каждое разрешение требует собственного способа проверки. Универсальной кнопки «отключить всё в блокчейне» нет.

Connected Sites — это уровень сессии интерфейса

Подключение сайта позволяет dApp видеть адрес и запрашивать подписи через wallet. Само подключение обычно не даёт права автоматически перемещать ERC-20. Отключение полезно, потому что прекращает удобный канал запросов, но не изменяет ранее созданные on-chain approvals, permits или EIP-7702 delegation.

После phishing incident отключите неизвестные sites, но не останавливайтесь. Проверьте on-chain состояния отдельно. Если пользователь только подключил сайт и ничего не подписывал, риск может быть значительно ниже, чем после SetCode authorization, однако историю всё равно стоит просмотреть.

ERC-20 approval ограничивает spender и token contract

Классический approve записывает allowance в storage конкретного ERC-20. Unlimited approval опасен, но его область понятнее: spender может распоряжаться указанным token в пределах allowance. Отзыв выполняется отдельной транзакцией, обычно устанавливающей allowance в ноль. Это не влияет на EIP-7702 code.

Если после подозрительного сайта вы видите одновременно delegation и token approvals, формируйте два результата: code cleared и allowances reduced/revoked. Не считайте, что одно действие автоматически закрыло второе. Это особенно важно для USDT, USDC и других активов с высокой ликвидностью.

Permit и EIP-712 подпись могут создавать полномочие без обычного approve transaction

Некоторые токены и протоколы используют signed permits. Пользователь может не увидеть исходную on-chain approval до момента, когда подпись будет использована. EIP-7702 authorization тоже основана на подписи, но меняет другой объект — code state EOA. Сходство UX «подписать сообщение» не должно скрывать различие последствий.

При расследовании сохраняйте текст/тип подписи, если wallet его показывает. Не соглашайтесь на «повторную подпись для отмены» от неизвестного сайта. Для permits проверяются nonce/allowance конкретного стандарта, для EIP-7702 — delegation state и authorization history.

Permit2 добавляет ещё один слой между owner и конкретным dApp

Permit2 может централизовать token allowances и выдавать downstream permissions через подписанные данные. Это удобно, но после фишинга требует проверки как базового approval токена на Permit2, так и внутренних permissions. Наличие EIP-7702 поверх этой модели увеличивает число независимых контрольных точек.

Не пытайтесь упростить отчёт словом «approve». Запишите отдельными строками: Connected Site, token allowance, Permit2, EIP-7702 delegation, session key. Только так можно доказать, что каждый канал закрыт. Для массового инцидента это также помогает support-команде не пропустить остаточное полномочие.

Paymaster оплачивает gas, но не является синонимом delegation

Paymaster в account abstraction отвечает за sponsorship или альтернативную оплату gas. EIP-7702 может использоваться в архитектуре smart account вместе с paymaster, но это разные роли. Опасная delegation не становится безопасной из-за надписи Sponsored, а нормальный paymaster не обязательно означает, что EOA вообще delegated.

Если задача — понять gasless, используйте отдельный материал OneMagic; при security incident фиксируйте delegate implementation независимо от fee payer. Не выдавайте неизвестному spender unlimited allowance только для «оплаты комиссии токеном».

Session key может быть ограниченным даже при постоянной delegation

Smart account способен держать persistent implementation, но выдавать dApp временные полномочия: лимит суммы, набор контрактов, срок. Отзыв session key сокращает текущую поверхность, однако account остаётся delegated. Это может быть нормальным состоянием продукта, если implementation доверенная, но не возвращает классический EOA.

Если ваша цель — полностью отказаться от smart-account режима после incident, требуется reset EIP-7702. Если цель — только закрыть скомпрометированную игровую session, возможно достаточно снять session permission. Решение зависит от доверия к самой implementation.

Почему нельзя использовать один термин «доступ к кошельку»

Фраза слишком широкая и приводит к опасным инструкциям: «отключите сайт — всё безопасно» или «отзовите approve — кошелёк чист». В реальности доступ разбит на уровни с разной persistence и scope. EIP-7702 особенно важен, потому что меняет account code и может влиять на нативные активы и логику исполнения, а не только на один ERC-20.

В пользовательском чек-листе называйте конкретный механизм. Если support не может объяснить, что именно было отозвано, запросите transaction hash или state proof. Без проверяемого результата фраза «мы закрыли доступ» недостаточна.

Как безопасно использовать EIP-7702, если smart account действительно нужен

Цель статьи не в том, чтобы объявить EIP-7702 вредным. Механизм решает реальные UX-задачи Ethereum. Безопасность достигается не запретом технологии, а минимизацией доверия: известная implementation, прозрачный интерфейс, ограниченная область, отдельный operational wallet и проверяемый путь revoke.

Используйте delegation только из нативного сценария известного wallet

Если wallet provider официально внедрил smart account, логично ожидать, что upgrade инициируется внутри приложения и target implementation заранее известна продукту. Это гораздо безопаснее, чем произвольный dApp, который предлагает «улучшить» ваш EOA. Wallet может применять allowlist implementations и показывать понятный security prompt.

Для первого включения откройте официальную документацию вручную, а не по ссылке из pop-up. Сравните полное имя функции и support article. Если приложение неожиданно просит delegation во время простого receive или просмотра баланса, остановитесь и выясните причину.

Разделяйте reserve wallet и operational smart account

Долгосрочный резерв выигрывает от минимальной поверхности доверия. Operational wallet может использовать batching, sponsorship и session keys ради удобства. Хранить весь капитал на адресе, который регулярно тестирует новые dApps и implementations, необязательно. Разделение уменьшает blast radius человеческой ошибки и zero-day.

Определите лимит рабочего баланса заранее, а не после инцидента. Крупные накопления держите на более консервативной схеме — hardware wallet или multisig — если ваши процессы это поддерживают. Smart-account функции используйте там, где выгода от автоматизации действительно оправдывает дополнительный код.

Hardware wallet должен показывать, что вы делегируете account

Одна из ключевых защит — transaction display. Пользователь должен понимать, что подтверждает не обычный перевод ETH, а authorization конкретному implementation. Если устройство или companion app не умеет безопасно интерпретировать EIP-7702 и показывает blind signing, риск заметно выше.

Для существенного кошелька не включайте произвольную delegation через blind signing только ради удобной функции. Дождитесь официальной поддержки вашего hardware ecosystem или используйте отдельный тестовый wallet. Аппаратный ключ защищает секрет, но не может исправить осознанно подтверждённый неправильный target.

Проверяйте chain scope до подписи

Chain-specific authorization соответствует принципу минимальных полномочий: функция работает там, где нужна. Chain_id=0 должен иметь понятное обоснование и проверенную cross-chain deployment model. Если dApp не объясняет, зачем нужна авторизация «для всех сетей», пользователь не обязан принимать такой scope.

Запишите chain ID и target при первой настройке. Это кажется избыточным до инцидента, но потом превращает расследование из догадок в проверку нескольких фактов. Для корпоративного или семейного treasury такие записи должны быть частью операционной документации.

Проверяйте возможность revoke до того, как доверите implementation деньги

Хорошая security-модель включает exit. Пользователь должен знать, где удалить delegation, какой gas нужен и как проверить, что code cleared. Если продукт отлично объясняет upgrade, но ничего не говорит о downgrade, это сигнал незрелости процесса. EIP-7702 предусматривает технический reset, но UX всё равно важен.

Протестируйте lifecycle на небольшом operational account: включение, одна безопасная операция, revoke, независимая проверка. Не используйте основной резерв как первый тест новой wallet capability. Практический rehearsal снижает риск паники, если функцию придётся отключать срочно.

Не подменяйте проверку delegate contract симуляцией одной транзакции

Transaction simulation показывает предполагаемый результат конкретного call при текущем состоянии, но не отвечает на вопрос, что implementation сможет делать в будущем. Delegation — более долгоживущее доверие. Даже хороший preview первого действия не является аудитом кода, upgradeability и session policy.

Используйте simulation как дополнительный слой: проверяйте balance changes, approvals и recipients. Но решение о delegation принимайте по происхождению implementation и модели безопасности. Это особенно важно после появления атак, которые специально ориентируются на доверие пользователя к preview.

Обновляйте wallet только из проверенного источника

Новые функции account abstraction часто требуют свежих версий приложения. Этим пользуются мошенники, распространяя fake extensions и APK под видом «версии с EIP-7702». Поддельное приложение опаснее отдельной delegation: оно контролирует интерфейс и может попытаться получить seed.

Обновляйте через официальный store/repository, сверяйте publisher и не устанавливайте файл из чата. Если версия уже установлена из сомнительного источника, рассматривайте устройство как потенциально скомпрометированное и переходите к более строгому сценарию миграции ключей.

Как оформить расследование EIP-7702 incident так, чтобы им можно было пользоваться

Хороший incident report — не рассказ «я нажал что-то и деньги пропали», а последовательность проверяемых фактов. Это помогает владельцу, wallet provider, бирже и специалисту по безопасности быстро понять механизм. Даже если активы не украдены, документирование полезно: оно показывает, какие полномочия были закрыты и какие адреса больше нельзя использовать.

Запишите исходную точку и пользовательское действие

Начните с даты, устройства, wallet version, сети, домена/приложения и того, что пользователь собирался сделать: swap, claim, bridge, upgrade, gasless. Затем зафиксируйте, какую подпись показывал wallet и какой target был виден. Не нужно восстанавливать точный текст по памяти, если есть screenshots или transaction data.

Отделяйте факты от предположений. «Подписал authorization на 0x…» — факт; «сайт украл seed» — гипотеза, пока нет доказательств. Такое разделение предотвращает ненужное уничтожение устройства и помогает выбрать правильный remediation.

Сохраните authority, delegate и chain как три разные сущности

Authority — ваш EOA, delegate — contract implementation, chain — конкретная сеть состояния. В бытовом описании эти понятия часто смешиваются, из-за чего support проверяет не тот адрес. Запишите полные hex addresses без сокращения и chain ID/название сети. Если delegation была chain-agnostic, отметьте это отдельно.

Не публикуйте домашние данные, документы KYC и секреты вместе с on-chain report. Для технической помощи обычно достаточно публичных адресов, hashes, chain и версии wallet. Персональные сведения передаются только официальной стороне и по необходимости.

Разделите hashes установки, вредных transfers и revoke

Один transaction hash редко описывает весь incident. Нужен hash SetCode/authorization transaction, hashes последующих подозрительных операций, hash revoke и при миграции — transfers на новый wallet. Это формирует причинно-временную цепочку и позволяет проверить, случилась ли кража до или после удаления delegation.

Каждый hash проверьте в независимом explorer. Если UI кошелька показывает внутреннюю activity без обычного transaction, сохраните UserOperation hash или другой идентификатор продукта. Не подменяйте технический hash скриншотом push-уведомления.

Зафиксируйте code state до и после

Для EIP-7702 главный артефакт — изменение code state authority. До revoke сохраните delegation indicator/target, после — результат, подтверждающий отсутствие delegation. Это сильнее формулировки «нажал Disable». Если делегация осталась, incident не закрыт, даже если интерфейс перестал показывать smart-account label.

Для нескольких сетей сделайте таблицу: chain, before, target, revoke hash, after. Такой формат быстро выявляет пропущенную сеть. Храните report вместе с остальными security records, но без seed и private key.

Параллельно ведите таблицу активов и остаточных permissions

Account code — только один слой. Отдельно запишите balances, token approvals, Permit2, NFT operators и session keys. После cleanup у каждого объекта должен быть проверяемый итог. Например: delegation none, USDT allowance 0, unknown NFT operator false, session key revoked. Это превращает «кажется безопасно» в набор состояний.

Для высокой суммы повторите проверку через некоторое время и перед новым пополнением. Если старый address признан key-compromised, не возвращайте туда деньги даже при идеальном on-chain cleanup. Final status должен явно говорить: reusable или retired.

Wallet provider должен получить минимально достаточный технический пакет

Если подозрение связано с официальным wallet, сообщите version, chain, authority, delegate, authorization hash и screenshot prompt. Это позволяет provider отличить phishing frontend от ошибки собственной implementation. Не отправляйте seed, private key, password и 2FA codes — поддержке они не нужны для анализа публичной EIP-7702 state.

Обращайтесь через официальный support domain/app. Мошенники часто появляются в публичных комментариях после жалобы и предлагают «revoke bot». Считайте любой unsolicited DM отдельной угрозой. Никто не должен просить секретную фразу для отмены delegation.

После закрытия incident обновите правила использования адреса

Технический revoke без изменения поведения оставляет причину инцидента. Зафиксируйте, почему подпись была принята: непонятный UI, реклама, отсутствие hardware display, использование reserve wallet для новых dApps, отсутствие второго контроля. Затем измените процесс: allowlist сервисов, отдельный operational wallet, лимиты и обязательная проверка target.

Если адрес retired, обновите whitelist, payment instructions и контакты. Если reused, документируйте, почему key считается секретным и какие проверки завершены. Перенос кошелька на новое устройство выполняйте только после стабилизации incident; инструкция OneMagic: как перенести криптокошелёк на новый телефон.

Пять практических сценариев: как меняется решение в зависимости от того, что именно произошло

EIP-7702 incident редко приходит в виде сообщения «вы подписали вредоносную delegation». Обычно пользователь видит более бытовую картину: после обновления кошелька появился Smart Account, после airdrop сайт попросил Upgrade, USDT списались без понятного approve, hardware wallet показал неизвестные данные или один и тот же адрес ведёт себя по-разному в нескольких сетях. Ниже — сценарии, которые помогают связать техническую модель с реальным решением.

Сценарий 1: официальный wallet сам предложил включить smart account

Пользователь обновил известное приложение через официальный store, внутри самого wallet появилась новая функция Smart Account, а documentation provider описывает EIP-7702 и публикует адрес implementation. Балансы на месте, неизвестных transfers нет, delegate address совпадает с официальной реализацией, chain scope соответствует заявленной функции. Это не выглядит как incident только потому, что account теперь содержит delegation indicator. В данном случае задача — не панически отзывать всё, а понять новую модель безопасности: какие permissions доступны, кто может upgrade implementation, как устроен recovery и где находится штатный revoke.

Перед хранением существенного баланса проведите lifecycle test на небольшой сумме: зафиксируйте target, выполните одну понятную операцию, проверьте transaction result, затем протестируйте revoke или хотя бы убедитесь, что provider документирует exit. Если функция не нужна, обычный EOA с меньшей поверхностью доверия может быть рациональнее. Сам факт легитимности implementation не обязывает использовать её для долгосрочного резерва.

Сценарий 2: airdrop-сайт просит «Enable Smart Wallet» перед получением токенов

Пользователь открывает ссылку из рекламы или сообщения, подключает кошелёк и видит обещание бесплатного токена. Вместо обычной claim transaction интерфейс просит включить smart wallet или подписать account upgrade. Target contract не объяснён, официальный проект не подтверждает необходимость EIP-7702, а ценность airdrop мала по сравнению с балансом кошелька. Это высокорисковая асимметрия: ради неизвестной награды пользователь выдаёт полномочие, способное изменить логику всего EOA.

Правильное действие — не подписывать и не пытаться «проверить, что будет» основным wallet. Отключите сайт, проверьте, не было ли уже подписей/approvals, и при необходимости используйте отдельный пустой research wallet. Если authorization уже подписана, действуйте как при suspicious delegation: code state, target, chain scope, revoke. Не отправляйте средства на сайт для «активации airdrop» или «оплаты отмены».

Сценарий 3: после неизвестной delegation с кошелька ушли USDT, но approvals выглядят чистыми

Такой случай хорошо показывает различие уровней доступа. Пользователь открывает approval checker и видит, что allowance для USDT равен нулю, поэтому решает, что токен не мог быть списан контрактом. Но если EOA был delegated вредоносному implementation, движение средств могло происходить через логику account, а не классический transferFrom по сохранённому allowance. Нулевые approvals не опровергают EIP-7702 incident. Нужно восстановить code state в момент списания, delegate target и транзакционную цепочку.

Сначала сохраните hashes и не создавайте повторные approvals «для возврата». Если остаток средств ещё есть, определите, безопасно ли выполнять revoke с этого account; при признаках stolen key подготовьте новый wallet. После стабилизации проверьте USDT transfer events и все остальные токены. Для конкретной транзакции используйте независимый explorer и сверку TXID: как проверить транзакцию по TXID.

Сценарий 4: пользователь подписал chain_id=0, но видит delegation только в одной сети

Отсутствие delegation в других сетях в момент проверки не делает chain-agnostic подпись безопасной навсегда. Chain_id=0 расширяет допустимую область authorisation; фактическое применение зависит от nonce, состояния и наличия подходящего target. Пользователь должен исходить не из предположения «у меня только Ethereum», а из истории адреса: где он получал токены, использовал bridge, держал NFT или был записан в whitelist. Каждая такая chain становится отдельной точкой контроля.

Зафиксируйте сети с реальной историей, проверьте code и implementation на каждой, а затем решите, где нужен revoke. Не создавайте ненужные транзакции в пустых сетях. Если адрес будет retired из-за key compromise, дополнительно обновите все будущие источники поступлений. Cross-chain безопасность включает не только состояние сегодня, но и предотвращение новых переводов на старый адрес.

Сценарий 5: hardware wallet подтвердил EIP-7702 authorization, seed не раскрывалась

Аппаратное устройство уменьшает вероятность скрытой кражи private key, но не исключает ошибку пользователя при подписании. Если человек физически подтвердил authorization, а seed никогда не вводил вне устройства, исходная гипотеза — signature/delegation compromise, а не автоматически stolen key. Это позволяет действовать точнее: исследовать target, chain scope и revoke, не уничтожая рабочую систему хранения без необходимости. Но нужно проверить, не было ли blind signing и не установлено ли вредоносное companion-приложение.

После revoke смените только то, что действительно скомпрометировано. Если hardware wallet и recovery phrase остаются секретными, можно рассмотреть сохранение ключа после независимой проверки. Для особо крупного резерва более консервативный вариант — миграция, особенно если невозможно доказать происхождение подписи. В любом случае не вводите seed в компьютер для «проверки EIP-7702»: это превратит ограниченный incident в потенциальную утечку ключа.

Итог: EIP-7702 нужно проверять как изменение модели самого аккаунта

EIP-7702 делает привычный EOA программируемым без смены адреса. Для нормального smart-wallet продукта это мощное улучшение: batching, sponsorship и ограниченные permissions становятся доступнее. Но security-модель тоже меняется. Пользователь должен проверять не только recipient и сумму, но и delegate implementation, chain scope, upgradeability и путь revoke. Самый опасный сценарий — неизвестная authorization, которую человек принимает за техническое обновление или бесплатный gas.

Если подозрительная EIP-7702 delegation уже существует, рабочий маршрут таков: прекратить взаимодействие с источником, зафиксировать authority/delegate/chain и hashes, проверить code state, использовать официальный revoke на zero/null address, повторно подтвердить отсутствие delegation, затем проверить approvals и transfers. При раскрытии seed/private key нужен новый wallet с новым секретом. При chain_id=0 и мультисетевой истории каждую EVM-сеть проверяют отдельно. Такой подход отделяет реальную безопасность от косметических действий вроде disconnect сайта.

Не используйте seed-фразу для онлайн-проверки EIP-7702. Публичное состояние account, transaction hashes и code читаются без секретов. Если сервис утверждает, что для просмотра delegation нужно импортировать seed, закрывайте его. Для спорного случая лучше остановить операции и получить независимую помощь, чем подписывать ещё одну неизвестную authorization под обещание «вернуть обычный кошелёк».