Подписал неизвестную транзакцию в кошельке: что делать

Подписал неизвестную транзакцию в кошельке — это не один технический сценарий, а несколько принципиально разных ситуаций, которые внешне могут выглядеть одинаково: пользователь нажал «Confirm» или «Sign», а затем понял, что не уверен в адресе, контракте, сумме или смысле операции. От правильной классификации зависит всё дальнейшее. Прямой перевод уже отправленных монет нельзя «отозвать» тем же способом, которым отзывают token approval; офчейн-подпись может не отображаться среди обычных транзакций, но всё равно давать право на действие; разрешение spender может сохраняться после закрытия сайта; а раскрытая seed-фраза означает уже не локальный риск конкретного контракта, а компрометацию самого контроля над кошельком.

Первая ошибка после подозрительной подписи — действовать вслепую. Пользователь пугается, начинает быстро нажимать revoke на случайных сервисах, повторно подключает кошелёк к неизвестным страницам, копирует адреса из истории или пытается «отменить» операцию новой транзакцией, не разобравшись, что было подписано. Такой подход способен увеличить ущерб: можно заплатить gas за бесполезные действия, раскрыть ещё больше данных, подписать второе опасное разрешение или перевести активы на адрес, который также контролирует злоумышленник.

Правильная реакция строится как техническое расследование. Сначала фиксируют исходные данные: адрес кошелька, сеть, время, сайт или приложение, текст окна подписи, transaction hash или отсутствие hash, изменения баланса и новые approvals. Затем определяют тип действия: обычный transfer, вызов смарт-контракта, ERC‑20 approve, NFT operator approval, permit, Permit2, EIP‑712 message, personal_sign, авторизация account delegation или другой механизм. После этого выбирают средство защиты: проверка TxID, revoke, invalidation, перенос активов, смена кошелька, очистка устройства или обращение к платформе.

Материал сфокусирован именно на аварийном сценарии после уже совершённой неизвестной подписи. Он не дублирует отдельную инструкцию о том, как проверить разрешения после подозрительной подписи, и не заменяет общий гайд о том, как защитить криптокошелёк. Здесь задача другая: быстро понять последствия конкретного действия и выбрать минимально достаточную, но технически корректную реакцию.

Важно также различать «неизвестную транзакцию» и «неизвестную подпись». В пользовательском интерфейсе эти слова часто смешиваются. Транзакция обычно отправляется в сеть, имеет nonce, платит сетевую комиссию и после распространения получает hash. Подпись сообщения может происходить без gas и без немедленной записи в блокчейн. Но это не делает её автоматически безопасной: EIP‑712 и permit-механизмы специально позволяют подписать структурированное разрешение вне сети, а затем передать его контракту через другого отправителя.

Поэтому главный вопрос звучит не «была ли комиссия», а какие полномочия создала подпись и успел ли кто-то ими воспользоваться. Если в блокчейне виден только approve на ограниченную сумму, риск локализуется конкретным токеном, сетью и spender. Если был прямой transfer, актив уже перемещён. Если подписана авторизация, способная изменить контроль над аккаунтом или дать широкие права, оценка должна быть жёстче. Если seed-фраза или приватный ключ были введены на подозрительном ресурсе, все отдельные approvals становятся вторичными: старый кошелёк нельзя считать надёжным.

Практический принцип: не пытайтесь «лечить кошелёк» одной универсальной кнопкой. Сначала установите тип подписи, затем проверьте состояние on-chain и только после этого выбирайте revoke, перенос активов или полный отказ от старого ключа.

Что именно могло произойти после неизвестной подписи

Обычный перевод: актив ушёл непосредственно получателю

Самый понятный вариант — обычный перевод нативной монеты или токена. Для ETH и других нативных активов транзакция содержит адрес получателя, значение и параметры комиссии. Для токена часто вызывается функция transfer самого token contract. Если такая транзакция успешно включена в блок, блокчейн считает изменение состояния совершённым. В self-custody нет центрального оператора, который может нажать «undo». Дальнейшие действия направлены не на технический откат, а на фиксацию доказательств, поиск возможного получателя, уведомление сервисов и предотвращение следующего списания.

При прямом transfer важно проверить не только крупную строку «Sent», но и реальный адрес назначения. Иногда кошелёк показывает понятное имя, полученное из адресной книги или внешнего интерфейса, а в блокчейне записан другой hex-адрес. Сравнивают весь адрес, сеть и transaction hash. Если перевод ушёл на централизованную биржу или иной идентифицируемый сервис, можно оперативно обратиться в его официальную поддержку с hash и обстоятельствами, но нельзя обещать заморозку или возврат: это зависит от платформы, юрисдикции, статуса средств и скорости реакции.

Вызов смарт-контракта: одна транзакция может содержать несколько эффектов

Контрактный вызов сложнее обычного transfer. Поле To указывает на контракт, а calldata задаёт метод и аргументы. Внутри исполнения контракт может переводить токены, вызывать другие контракты, создавать события, обменивать активы, добавлять ликвидность, выдавать позиции или устанавливать разрешения. Поэтому просмотр только верхней строки транзакции недостаточен. Нужно анализировать token transfers, internal calls, events и итоговые изменения балансов.

Успешный status не означает, что пользователь получил ожидаемый результат. Он означает, что EVM не откатила выполнение всей транзакции. Мошеннический контракт тоже может исполниться «успешно». И наоборот, failed-транзакция обычно откатывает изменения состояния конкретного выполнения, хотя сетевой gas уже израсходован. Исключения и современные механизмы делегирования требуют отдельного внимания, поэтому при необычном типе транзакции полезно смотреть не только receipt, но и account state после операции.

ERC-20 approve: право spender тратить токены

Функция approve не обязана сразу переводить токены. Она записывает allowance: сколько конкретный spender вправе перемещать от имени владельца через transferFrom. Именно поэтому пользователь может подписать вроде бы «пустую» операцию, не увидеть мгновенного списания и решить, что всё обошлось. Если spender вредоносный, право может быть использовано позже — пока allowance не исчерпан или не изменён.

Риск ограничен параметрами разрешения, но эти параметры нужно читать точно: сеть, token contract, spender и amount. «Unlimited» или практически неограниченный лимит делает потенциальный ущерб равным доступному балансу соответствующего токена сейчас и в будущем. Простое отключение dApp от кошелька это право не удаляет, потому что allowance хранится в состоянии токен-контракта. Нужна отдельная on-chain операция, которая изменит allowance.

NFT approvals: operator может управлять не одним активом

Для NFT встречаются разрешения на один token ID и setApprovalForAll, которое способно дать operator право распоряжаться всеми активами соответствующей коллекции владельца. Если пользователь проверяет только ERC‑20 allowances, он может пропустить NFT-риск. Особенно опасна привычка считать, что «на кошельке нет токенов, значит нечего красть»: дорогой NFT или другой объект может находиться в том же аккаунте и подчиняться другой модели разрешений.

Проверка должна учитывать стандарты конкретного актива и события Approval или ApprovalForAll. После подозрительной подписи не стоит переносить новые NFT в старый адрес, пока не понятно, какие полномочия там остались. Если operator неизвестен, разрешение прекращают через штатную функцию контракта или доверенный интерфейс, затем перепроверяют состояние в explorer.

Permit и EIP-2612: разрешение может родиться из офчейн-подписи

Permit-механизм переносит часть процесса из обычной транзакции в подпись. В типичной модели владелец подписывает данные owner, spender, value, nonce и deadline, а затем другая сторона может передать эту подпись в token contract. Из-за этого пользователь способен не увидеть никакого своего исходящего on-chain approve сразу после нажатия Sign. Опасность остаётся до тех пор, пока подпись допустима по nonce, сроку и правилам конкретного контракта.

Поэтому отсутствие transaction hash непосредственно после подписи не доказывает отсутствие риска. Нужно вспомнить, что именно показывал кошелёк: домен EIP‑712, verifying contract, spender, amount, deadline, nonce. Если подпись подозрительна, дальнейшая стратегия зависит от механизма токена: иногда разрешение можно сделать бесполезным, изменив nonce или allowance через предусмотренную функцию, иногда проще перенести активы. Нельзя автоматически применять рецепт одного токена ко всем.

Permit2 и многоуровневые разрешения

Permit2 и похожие системы разделяют базовое разрешение токена специальному контракту и более детальные полномочия конкретным приложениям. Это удобно для UX, но после неизвестной подписи создаёт дополнительный слой диагностики. Пользователь может отозвать соединение с сайтом и даже удалить его из списка connected dapps, однако базовый approve токена или внутренний allowance продолжит существовать.

Проверяют оба уровня: кому разрешено тратить токен в самом token contract и какие полномочия записаны или подписаны внутри специализированного механизма. Если статья про revoke даёт детальную механику отмены, то здесь важнее аварийный приоритет: сначала понять, способен ли неизвестный spender списать актив прямо сейчас, затем уменьшить окно риска, а уже потом приводить список approvals к аккуратному состоянию.

EIP-712 и personal_sign: сообщение может быть авторизацией

EIP‑712 создан для структурированных данных, чтобы кошелёк мог показывать поля более осмысленно, чем сырой hex. Но безопасность зависит от содержания этих полей и логики verifying contract. Сам факт, что окно называется «Sign message», не означает безобидный вход. Подпись может подтверждать торговый ордер, permit, листинг NFT, делегирование или другое действие, которое позже исполняется контрактом.

personal_sign и другие простые подписи часто дают пользователю меньше контекста. Если неизвестный сайт просил подписать строку или набор байтов, нужно сохранить точный текст, origin сайта и время. Повторная подпись «для отмены» без понимания протокола опасна: в большинстве механизмов подпись не отменяется подписью с противоположным текстом. Требуется понять, как приложение проверяет nonce, срок или on-chain state.

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

Современные EVM-аккаунты могут использовать делегирование кода, которое меняет поведение привычного EOA и позволяет выполнять более сложные сценарии — batching, sponsorship и другие функции. Для пользователя это означает, что в 2026 году неизвестную подпись нельзя всегда классифицировать только как transfer или approve. Если интерфейс предлагал «upgrade account», «enable smart features», «delegate», «batch» или похожую операцию, нужно проверить тип транзакции и состояние кода аккаунта.

Такое действие потенциально чувствительнее обычного allowance, потому что влияет на то, какой код выполняется в контексте аккаунта. Нельзя пытаться исправлять неизвестное делегирование случайным revoke ERC‑20: это другой слой полномочий. Следует определить точный механизм кошелька, адрес делегата и поддерживаемый способ отмены или замены. Если интерфейс не объясняет это однозначно, безопаснее остановить операции и использовать официальную документацию конкретного кошелька.

Первые действия: как остановить развитие инцидента без новых ошибок

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

Первое действие — не «нажать отмену», а прекратить давать источнику новые возможности. Закройте подозрительную страницу, не переходите по ссылкам из её чата, не устанавливайте «security update», не запускайте удалённый доступ и не подписывайте предложенную «recovery transaction». Если сайт уже получил только публичный адрес, его закрытие уменьшает риск социальной инженерии; если подписано разрешение, закрытие само по себе его не отменяет, но предотвращает следующую подпись.

Не нужно сразу удалять всю историю браузера и очищать устройство, если это уничтожит полезные доказательства. Сначала зафиксируйте URL, время, скриншоты окна, название расширения и transaction hash. После фиксации можно перейти к технической очистке. Главное — не продолжать активное взаимодействие из той же вкладки в надежде, что она покажет правильный способ отмены.

Не вводите seed-фразу «для проверки кошелька»

Если неизвестная транзакция сопровождалась просьбой повторно ввести Secret Recovery Phrase, seed-фразу или приватный ключ, это уже отдельный красный флаг. Legitimate dApp не нуждается в seed-фразе для чтения баланса, revoke или проверки transaction hash. Если секрет уже был введён на подозрительной странице, следует исходить из предположения, что ключ мог быть скопирован.

В такой ситуации анализ approvals всё ещё полезен как источник информации, но он не восстанавливает доверие к старому ключу. Создают новый кошелёк с новой seed-фразой на чистом доверенном устройстве и планируют перенос активов. Нельзя «сменить пароль MetaMask» и считать проблему решённой: локальный пароль защищает приложение на устройстве, но не изменяет приватные ключи, выведенные из seed.

Зафиксируйте адрес, сеть, время и всё, что было видно в окне

Минимальный журнал инцидента должен позволить через несколько часов восстановить последовательность событий без догадок. Запишите публичный адрес кошелька полностью, chain/network, примерное время подписи, домен сайта, название dApp, адрес контракта или recipient, отображённую сумму, обещанный результат и фактический результат. Если кошелёк показывал предупреждение, сохраните его текст.

Важно сохранять именно исходные значения. Не заменяйте длинный адрес подписью «Uniswap» или «биржа», пока не подтверждено, что адрес действительно принадлежит этому сервису. Не обрезайте transaction hash до первых и последних символов. Для технического разбора нужны полные строки, потому что похожие адреса и address poisoning специально эксплуатируют привычку проверять только края.

Если есть TxID, откройте его через независимый explorer

Переходить в explorer безопаснее не по ссылке, которую дал подозрительный сайт, а через заранее известный или официальный источник. Введите transaction hash вручную или вставьте его в поиск. Сверьте сеть: hash из одной EVM-сети может не находиться в другой. Если кошелёк показывает несколько сетей, убедитесь, что анализируете ту, где подписывалось действие.

Проверьте status, from, to, nonce, value, fee, method, token transfers и events. Даже если интерфейс кошелька написал «Swap», blockchain receipt может показать approve или другой вызов. Если транзакция ещё pending, не спешите создавать новую с тем же nonce без понимания механизма замены: это может изменить приоритет, но не гарантирует безопасный исход, особенно если вредоносная операция уже распространена.

Если TxID нет, выясните, была ли это подпись сообщения

Отсутствие hash после Sign часто указывает на офчейн-подпись. Откройте историю dApp или кошелька, если она сохраняет запросы, и определите тип: EIP‑712 typed data, personal_sign, SIWE/login или специализированная подпись. Сохраните fields и domain. Если приложение отказывается показывать содержимое, это повод повышать осторожность, а не снижать её.

Проверять только блокчейн сразу после офчейн-подписи недостаточно: злоумышленник может использовать подпись позже. Нужно установить, для какого контракта и на какой срок она действует. Если известно, что речь о permit, смотрят nonce и deadline. Если механизм неизвестен, лучше не пополнять старый адрес новыми активами до завершения анализа.

Не доверяйте случайной «поддержке», которая пишет первой

После публикации вопроса в Telegram, Discord или X часто появляются аккаунты с логотипом кошелька и предложением «отменить smart contract». Типичная схема заставляет подключиться к новой странице, ввести seed или подписать ещё одну операцию. Наличие точного описания вашей проблемы не доказывает легитимность: мошенник мог увидеть публичный пост или blockchain-транзакцию.

Связь с поддержкой открывают только из официального приложения или официального сайта. Настоящая поддержка может помочь интерпретировать интерфейс, но не имеет магической возможности отменить подтверждённую публичную транзакцию. Требование оплатить «страховой депозит», «gas verification» или «unlock fee» на личный адрес — повод прекратить контакт.

Разделите две задачи: сохранить доказательства и спасти активы

Иногда пользователи откладывают перенос средств, потому что хотят сначала собрать идеальный отчёт. Иногда делают обратное: в панике переводят всё, а затем не могут доказать, что произошло. Правильный баланс зависит от риска. Если уже идут несанкционированные списания, приоритет — остановить дальнейшую потерю. Если движения нет и риск ограничен одним approval, можно сначала зафиксировать состояние.

Хорошая практика — использовать отдельное доверенное устройство для анализа и нового кошелька, а старое оставить в неизменном состоянии до копирования необходимых данных. Не следует делать скриншоты seed-фразы или отправлять её себе в облако ради «доказательств». Секретные данные не входят в доказательственный пакет; достаточно публичных адресов, hashes, URL и истории взаимодействия.

Как разобрать TxID и понять, что именно изменилось в блокчейне

Если сначала нужно понять, что такое TXID, воспринимайте его как публичный идентификатор конкретной on-chain транзакции. По нему можно открыть запись в обозревателе нужной сети и независимо от интерфейса кошелька проверить результат операции. Для аварийного разбора этого мало само по себе, но TXID задаёт точку, от которой проверяют status, адреса, value, вызванный метод и события.

Status: successful, failed и pending означают разные вещи

Successful означает, что транзакция прошла правила сети и её выполнение не было полностью откатано. Это не оценка полезности или безопасности. Failed обычно означает, что state changes внутри этой транзакции были откатаны, но gas израсходован. Pending означает, что окончательного результата ещё нет: транзакция может быть включена, заменена, вытеснена или долго оставаться в mempool в зависимости от сети и fee.

При неизвестной транзакции полезно записать block number и число confirmations, а затем перепроверить статус позже. Но защита не должна зависеть от надежды, что вредоносная транзакция «сама пропадёт». Если она pending и потенциально опасна, оцените возможность штатной замены через официальный интерфейс кошелька. Не копируйте случайные инструкции по nonce, если не понимаете, как конкретная сеть обрабатывает replacement.

From и To: адрес отправителя и адрес вызова

Поле From должно совпадать с вашим публичным адресом, если транзакцию отправляли вы. To может быть обычным адресом получателя или смарт-контрактом. Если To — контракт, это ещё не говорит, кому в итоге ушли токены: дальнейшие transfers формируются внутри исполнения. Нужны token transfer events и internal call trace.

Если адрес To ранее не использовался, проверьте его историю и код контракта. Но отсутствие негативных меток не является доказательством безопасности. Новый мошеннический контракт может ещё не иметь репутации. Полезнее сопоставить адрес с официальной документацией dApp, убедиться в правильной сети и понять method signature.

Value и token transfers: нативная монета и токены считаются отдельно

Поле Value верхнего уровня обычно отражает нативную монету, отправленную вместе с вызовом. Токены ERC‑20 перемещаются через вызовы контрактов и отображаются отдельно. Поэтому transaction value = 0 не означает отсутствие финансового эффекта. Внутри операции могли уйти USDT, USDC, NFT или иные активы.

Сравните баланс до и после, а также все transfer events. Если explorer показывает несколько токенов, разберите каждый. Иногда пользователь видит один входящий токен как результат swap и не замечает второй исходящий перевод, который был частью вредоносного маршрута. Net-изменение по активам важнее красивого названия метода.

Method и input data: что просили исполнить

Explorer может декодировать calldata и показать название функции, если ABI известен. Для стандартных функций встречаются transfer, approve, transferFrom, setApprovalForAll, multicall и другие методы. Название полезно, но его нужно воспринимать вместе с адресом контракта и аргументами. Один и тот же метод approve на легитимный router и на случайный spender имеет совершенно разный риск.

Если метод не распознан, сохраняйте raw input. Не нужно вручную декодировать всё без опыта; достаточно зафиксировать данные и использовать проверенный декодер или официальный интерфейс. Важно не загружать seed/private key ни в какой «decoder». Для анализа calldata достаточно публичной транзакции.

Logs и events: Approval часто важнее основного заголовка

Events — один из лучших способов увидеть, что контракт записал в ходе выполнения. ERC‑20 approve обычно создаёт Approval; transfer — Transfer. NFT стандарты имеют собственные события. Если подозрительный transaction receipt содержит Approval на неизвестного spender с большим amount, это существенный сигнал даже без немедленного исходящего transfer.

Список events нужно сопоставлять с токен-контрактами. Мошеннический контракт может испускать собственные события с убедительными названиями, поэтому нельзя доверять одному слову «Success» или «Verified». Стандартный Approval важен, когда он исходит от настоящего token contract вашего актива.

Internal transactions и traces: куда пошёл вызов дальше

Контрактный вызов может породить цепочку CALL, DELEGATECALL и внутренних переводов. Explorer иногда выводит internal transactions отдельно. Для сложных DeFi-операций это помогает понять путь средств. Но raw trace быстро становится техническим, поэтому цель аварийного анализа — найти финансово значимые изменения: кто получил активы, какие approvals остались, какие контракты были вызваны.

Если trace показывает неизвестный контракт в середине маршрута, не делайте вывод только по этому факту. Агрегаторы и routers легитимно вызывают множество адресов. Проверяйте конечные токены, spender, amount и официальный маршрут приложения. Подозрение усиливается, если адрес не связан с ожидаемым протоколом и одновременно появились неожиданные approvals или transfers.

Nonce и replacement: полезный инструмент, но не универсальная отмена

В EVM nonce задаёт порядок транзакций аккаунта. Pending-транзакцию иногда можно заменить другой транзакцией с тем же nonce и более привлекательной комиссией. Кошельки часто предлагают Speed up или Cancel. Это работает только до подтверждения исходной операции и зависит от того, какая версия первой попадёт в блок.

После confirmation nonce уже не служит кнопкой отмены. Нельзя отправить вторую транзакцию с тем же nonce и ожидать отката истории. Более того, при цепочке pending операций неправильная ручная работа с nonce может заблокировать последующие транзакции или привести к неожиданному исполнению. Используйте штатный механизм кошелька и проверяйте итоговый hash.

Сверяйте transaction hash с реальным состоянием кошелька

Финальный вывод делается не по одному экрану explorer, а по состоянию адреса. Составьте список активов и разрешений, которые были до инцидента, и отметьте изменения. Если баланс токена не изменился, но появился allowance, риск ещё активен. Если allowance отозван, но seed был раскрыт, риск не устранён. Если transfer произошёл, а других разрешений нет, дальнейшая защита фокусируется на причинах подписи и безопасности ключа.

После всех действий повторно проверьте account state с независимого устройства или explorer. Нельзя считать revoke успешным только по уведомлению сайта. Нужен новый on-chain state: allowance = 0 или другое ожидаемое значение, operator отключён, новая транзакция подтверждена, а старый адрес больше не используется, если ключ скомпрометирован.

Как определить уровень риска: от локального approval до компрометации ключа

Низкий риск: подключение без подписи и без разрешений

Если выяснилось, что кошелёк только подключили к сайту, но не подписывали транзакцию или сообщение, финансовых полномочий могло не возникнуть. Подключение обычно раскрывает публичный адрес и позволяет dApp видеть баланс и запрашивать действия. Это вопрос приватности и фишингового контекста, но не автоматический доступ к средствам.

В таком случае отключите dApp в кошельке, удалите подозрительные site permissions в браузере и проверьте, не было ли незаметных approvals до этого. Если seed не вводилась и ничего не подписывалось, создавать новый кошелёк только из-за факта connect обычно не требуется. Однако если сайт устанавливал вредоносное расширение или файл, риск устройства оценивается отдельно.

Средний риск: ограниченный approval известного токена

Если подписан approve на небольшой amount и spender оказался подозрительным, риск ограничен этим token contract и allowance. При условии, что ключ не раскрыт и других разрешений нет, разумный ответ — оперативно отозвать allowance, затем проверить историю. Создание нового seed может быть избыточным, если нет признаков более глубокой компрометации.

Но нельзя путать ограниченный amount с ограниченным ущербом во всех случаях. Spender может успеть использовать весь allowance до revoke, а затем пользователь может ошибочно пополнить старый адрес. После отзыва убедитесь, что новое значение действительно записано в блокчейне, и некоторое время контролируйте активность.

Высокий риск: unlimited approval или неизвестный NFT operator

Unlimited approval предоставляет широкий коридор для последующего transferFrom. Если токен ликвидный и баланс значим, скорость имеет значение. Подготовьте gas в соответствующей сети, отзовите разрешение через доверенный инструмент и параллельно оцените, не было ли других подписей. Не переходите по revoke-ссылке от того же подозрительного сайта.

NFT operator approval также может иметь широкий охват. При дорогостоящих NFT стоит рассматривать перенос на чистый адрес после отключения operator, особенно если происхождение подписи не ясно. Новый адрес должен быть создан независимо, а не импортирован из той же скомпрометированной seed.

Высокий риск: неизвестная permit или EIP-712 подпись

Офчейн-подпись тревожна тем, что пользователь не всегда видит немедленный on-chain след. Если неизвестный сайт получил typed signature с spender, amount и deadline, он может передать её позже. Проверьте специфический контракт и nonce. Иногда можно создать другую транзакцию, которая меняет nonce или allowance и тем самым лишает старую подпись практической силы, но это зависит от реализации.

Не используйте универсальный совет «просто revoke». Если signature authorization ещё не materialized on-chain, обычный allowance может быть нулевым до момента исполнения permit. Нужно понимать, какие функции у токена или протокола изменяют nonce и как он проверяется. При большом балансе и неясном механизме перенос активов на новый адрес часто является более понятным способом сократить риск.

Критический риск: seed-фраза или приватный ключ раскрыты

Если Secret Recovery Phrase, seed или private key были введены на неизвестной странице, отправлены в чат, сохранены в вредоносном расширении или переданы «поддержке», старый кошелёк перестаёт быть доверенной средой. Не существует revoke, который делает украденный приватный ключ снова секретным. Смена локального пароля приложения тоже не меняет ключ.

Создайте новую seed-фразу на чистом устройстве и перенесите активы. Если нужны подробности восстановления, используйте отдельный материал о том, как восстановить криптокошелёк по seed-фразе, но при утечке важно не восстанавливать старую фразу как постоянное решение, а мигрировать на новые ключи. Старая seed остаётся скомпрометированной навсегда.

Критический риск: уже видны несанкционированные исходящие транзакции

Если после подписи появляются transfers, которых вы не делали, действуйте как при активном взломе. Не ждите завершения полного анализа. Подготовьте чистый адрес и спасайте то, что ещё контролируется, с учётом риска sweeper-бота. Одновременно сохраните hashes и адреса. Старый кошелёк после вывода остатка не используется.

Важно не отправлять на скомпрометированный адрес новый gas без плана: sweeper может забрать нативную монету быстрее, чем вы выполните rescue-транзакцию. В сложных случаях нужны специализированные механизмы приватной отправки или помощь компетентного специалиста, но никогда не передавайте ему seed. Любая сторона, требующая полный секрет для «спасения», получает те же полномочия, что и злоумышленник.

Отдельный риск: вредоносное расширение или заражённое устройство

Если неизвестная подпись появилась после установки расширения, APK, программы удалённого доступа или подозрительного обновления, проблема может быть не в одном контракте. Malware способен читать буфер обмена, подменять адрес, перехватывать ввод, показывать ложный интерфейс кошелька или красть локальные секреты. Даже новый кошелёк, созданный на том же заражённом устройстве, может быть снова скомпрометирован.

В такой ситуации сначала создают безопасную среду: другое доверенное устройство либо полностью очищенная и проверенная система. Затем генерируют новый seed и выполняют перенос. Не импортируйте старую seed в новую установку «для удобства». Это возвращает тот же ключевой материал и не устраняет компрометацию.

Revoke, перенос или новый кошелёк: как выбрать правильное средство

Revoke решает проблему allowance, но не возвращает отправленные средства

Отзыв разрешений нужен, когда риск связан с spender или operator. Для ERC‑20 это обычно изменение allowance до нуля или безопасного значения; для NFT — отключение operator либо удаление разрешения на конкретный токен. Действие записывается on-chain и требует сетевой комиссии. После подтверждения проверьте состояние ещё раз: spender, token contract, сеть и новое значение allowance должны совпасть с вашим ожиданием.

Revoke не отменяет уже совершённый transfer и не делает украденную seed секретной. Это принципиально важно: многие мошеннические сайты продают «revoke transaction» как универсальную очистку кошелька. В реальности каждое полномочие существует в конкретном контракте и сети. Если вредоносный spender уже потратил allowance, revoke остановит будущие списания в рамках оставшегося разрешения, но не вернёт прошлый transfer.

Disconnect dApp не равен revoke

Отключение сайта удаляет текущую связь интерфейса с кошельком и может запретить ему автоматически видеть адрес или формировать новые запросы. Но on-chain allowance не хранится в браузерной сессии. Поэтому после подозрительного approve нужно проверить разрешения отдельно. Это одна из самых частых ошибок при ликвидации инцидента: пользователь видит, что dApp исчез из списка connected sites, и считает активы защищёнными.

Полезно делать оба действия: disconnect снижает вероятность новых запросов от сайта, revoke изменяет blockchain-state. После этого очистите site permissions и WalletConnect sessions, если они были. Но не принимайте пустой список connected sites за доказательство, что spender больше не имеет прав. Подтверждением служит только фактическое состояние allowance или operator в соответствующей сети.

Перенос активов нужен, когда механизм подписи неясен

Если невозможно быстро понять, что именно авторизовала неизвестная EIP‑712 подпись, а на адресе хранится значимая сумма, перенос на новый чистый адрес уменьшает поверхность риска. Особенно это разумно, когда подпись имела долгий deadline, неизвестный verifying contract, сложный permit-механизм или интерфейс вообще не показал человеку понятных полей.

Перенос должен быть системным. Сначала создайте новый кошелёк с новым seed на чистом устройстве, затем проверьте адрес тестовым переводом, если ситуация позволяет. После этого перемещайте ценные активы, учитывая нужный gas и отдельные сети. Не переносите только USDT, забыв NFT, LP tokens, staking positions или активы в других chains. Аварийная миграция считается завершённой только после инвентаризации.

Новый кошелёк обязателен при компрометации ключа

Когда seed или private key раскрыты, old wallet рассматривается как публично известный секрет. Даже если злоумышленник пока не проявился, он может ждать будущего пополнения. Не стоит оставлять старый адрес как «резервный», принимать на него новые платежи или использовать для airdrop. Привычка «я всё вывел, значит адрес снова чистый» неверна: ключ не становится секретным после обнуления баланса.

Новая seed должна быть действительно новой. Создание нового account внутри того же HD-кошелька не всегда решает проблему, потому что разные accounts могут выводиться из одной seed. Если скомпрометирована мастер-фраза, нужен новый wallet root, а не просто Account 2. После миграции старую фразу не импортируют в новый основной кошелёк.

Когда можно сохранить старый кошелёк после revoke

Если расследование убедительно показало, что ключ не раскрывался, устройство чистое, подписан только конкретный approval, он отозван, а других неизвестных действий нет, старый адрес можно продолжать использовать. Но решение должно основываться на доказательствах, а не на отсутствии списаний в первые десять минут. Неизвестная permit-подпись или вредоносное расширение меняют эту оценку.

Проверьте approvals в основных сетях, историю взаимодействий и настройки кошелька. Если адрес используется как основной для крупных сумм, после серьёзного фишингового инцидента миграция может быть разумной даже без доказанной утечки: стоимость переноса ниже потенциальной неопределённости. Это решение управления риском, а не обязательное правило протокола.

Gas для revoke и rescue должен приходить из безопасного источника

Чтобы выполнить on-chain revoke или transfer, кошельку нужен нативный gas token соответствующей сети. Если старый адрес пуст по ETH, BNB или другой нативной монете, возникает соблазн быстро пополнить его крупной суммой. При подозрении на sweeper это опасно. Пополняйте только минимально необходимое и только после оценки того, кто контролирует ключ и способен ли бот перехватить поступление.

Если private key известен злоумышленнику, открытая mempool-транзакция может конкурировать с его ботом. Сложные rescue-сценарии требуют понимания private relay, bundle или особенностей конкретной сети. Не следуйте случайным «скриптам спасения», требующим вставить private key в сайт. Секрет не должен покидать доверенную среду даже ради технически сложного восстановления.

После переноса не возвращайте старые разрешения автоматически

Новый адрес — возможность построить более строгую модель доступа. Не стоит в первый же день повторять unlimited approvals всем старым dApps. Подключайте только необходимые сервисы, проверяйте token contract, spender, сеть и spending cap. Разделяйте активный hot wallet и долгосрочное хранение, чтобы следующий ошибочный approve не затронул весь портфель.

Если dApp нужен редко, ограниченный allowance может быть разумнее unlimited. Если поддерживается permit с коротким deadline, оценивайте его содержание. Главная цель не запретить web3, а сделать так, чтобы компрометация одного приложения не открывала путь ко всему портфелю. Управляемые разрешения удобнее расследовать и быстрее отзывать.

Как безопасно перенести активы и не повторить компрометацию

Создайте новый кошелёк на чистом устройстве

Новый кошелёк создают не в той же подозрительной вкладке и не через ссылку из сообщения «поддержки». Используйте официальный источник выбранного wallet software или аппаратное устройство. Если есть подозрение на malware, предпочтительно другое устройство, которому вы доверяете. Сгенерируйте новую seed-фразу и запишите её офлайн, не используя старую фразу как основу.

Не фотографируйте seed, не храните её в заметках, облаке или почте. Для восстановления достаточно корректной офлайн-копии. Перед крупным переносом убедитесь, что можете открыть новый кошелёк, видите правильный адрес и понимаете, как восстановить доступ. Тест восстановления выполняют только в доверенной среде, а не на сайте, который обещает «проверить 12 слов».

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

Копируйте адрес из нового кошелька и сверяйте его целиком перед первым переводом. Если используется аппаратный кошелёк, подтвердите адрес на экране устройства. Не берите адрес из старой истории транзакций: address poisoning строится именно на похожих адресах, которые подсовываются в историю и рассчитывают на проверку только первых и последних символов.

Полезно сохранить новый адрес в собственной офлайн-записи или проверенной адресной книге после контрольного перевода. Если адрес подменяется при вставке, прекратите работу на устройстве и разберитесь с возможным clipboard malware. Не отправляйте крупную сумму, пока копирование и отображение адреса не ведут себя предсказуемо на чистом устройстве.

Составьте инвентаризацию по сетям

Один seed может контролировать адреса в нескольких EVM-сетях и других экосистемах. Пользователь часто спасает активы на Ethereum и забывает BNB Chain, Polygon, Arbitrum, Base или другие сети. Составьте таблицу: сеть, нативная монета, токены, NFT, DeFi-позиции, approvals, ориентировочная ценность и нужный gas. Это уменьшает риск забыть актив в старом адресе.

Сначала перемещают ликвидные активы с высоким риском, затем менее критичные. Но порядок зависит от технической возможности: некоторые DeFi-позиции нужно сначала закрыть, claim или withdraw. Не подписывайте сложные действия в панике. Если позиция требует взаимодействия со старым dApp, проверьте официальный контракт и маршрут отдельно, чтобы rescue не стал новой точкой компрометации.

Сделайте небольшой тест, когда окно риска позволяет

Если злоумышленник ещё не активен и ключ не раскрыт, небольшой тестовый transfer снижает риск ошибки сети или адреса. Проверьте, что токен пришёл в ожидаемой сети и отображается в explorer. Затем переносите основную сумму. Для срочного rescue при активном компрометированном ключе тест может быть слишком медленным — решение зависит от угрозы и скорости несанкционированных действий.

Не путайте адрес-совместимость и сеть. Одинаковый hex-адрес в EVM-сетях не означает, что биржа или мост поддержит неправильный route. При выводе на централизованную платформу сеть должна совпадать с её депозитной сетью. Внутренний transfer между собственными EVM-адресами проще, но gas token всё равно зависит от конкретной сети.

Сначала перемещайте активы, которые можно вывести простым transfer

Обычный transfer уменьшает число контрактов, с которыми приходится взаимодействовать в аварийной ситуации. Если токены можно безопасно отправить напрямую на новый адрес, это часто предпочтительнее сложного swap. Не пытайтесь сначала «продать всё в один токен» через новый неизвестный агрегатор — это создаёт дополнительные approvals и повышает число мест, где можно ошибиться.

Для NFT используйте официальный интерфейс кошелька или проверенный transfer-механизм коллекции. Для активов с transfer restrictions, staking или vault-позиций понадобится отдельный plan. Главное — не увеличивать количество новых доверенных контрактов на старом адресе без необходимости. Чем проще rescue-транзакции, тем легче проверить их содержание до подписи.

После rescue проверьте старый адрес повторно

Сразу после переноса просмотрите balances, approvals и activity старого адреса. Остались ли dust tokens, NFT, claimable rewards, разрешения, активные позиции? Небольшой остаток не всегда стоит дополнительного риска и gas, но вы должны понимать, что именно оставлено и почему. Неожиданный актив может указывать на незавершённую позицию или scam token.

Если ключ скомпрометирован, пометьте старый адрес в своих записях как unsafe и не используйте повторно. Удаление account из интерфейса не удаляет адрес из блокчейна. Он будет существовать, но вы больше не должны считать его безопасным местом для получения ценностей или хранения gas.

Не импортируйте старый private key в новый основной кошелёк без необходимости

Импорт отдельного compromised private key в новый wallet software может смешать опасный аккаунт с новой инфраструктурой и создать операционные ошибки. Для наблюдения достаточно watch-only или explorer. Если старый адрес нужен для юридической или бухгалтерской истории, храните публичный адрес и hashes, а не продолжайте активно использовать ключ.

Новый кошелёк должен иметь чёткую границу доверия. Отдельный hot wallet для dApps и отдельное долгосрочное хранилище уменьшают последствия будущих фишинговых подписей. Чем меньше активов находится на адресе, который регулярно подписывает DeFi-операции, тем меньше потенциальный ущерб от одного ошибочного approve или permit.

После миграции обновите источники поступлений

Если на старый адрес приходили выплаты от биржи, работодателя, клиентов, майнинга или других сервисов, обновите реквизиты. Иначе через месяц можно забыть об инциденте и снова получить значимую сумму на compromised address. Отправителям сообщайте только новый публичный адрес, не seed и не приватный ключ.

Сделайте контрольный список всех мест, где сохранён старый адрес: exchange withdrawal whitelist, merchant profile, invoice template, contacts, bots, OTC counterparties. После изменения обязательно проверьте адрес повторно. Ошибка при обновлении реквизитов способна привести к потере средств не хуже исходного инцидента.

Что сохранять для поддержки, биржи и собственного расследования

Публичные blockchain-данные — основа доказательств

Сохраните transaction hashes, полный адрес отправителя, получателя, spender и token contract, network, block number, timestamp и суммы. Для approvals фиксируйте значение allowance до и после revoke. Для NFT — operator и коллекцию. Публичные данные можно перепроверить независимо, поэтому они особенно ценны для технического разбора и последующих обращений.

Не ограничивайтесь скриншотом explorer: текстовый список hashes удобнее для последующей проверки. Скриншот полезен как снимок интерфейса на конкретный момент, но blockchain-state лучше подтверждать самим hash и параметрами транзакции. Seed-фраза и private key не нужны для доказательства владения публичным адресом в обычном обращении и не должны передаваться третьим лицам.

Сохраните URL и происхождение подозрительного сайта

Запишите полный домен, путь страницы, источник ссылки и время посещения. Если ссылка пришла из рекламы, Telegram, Discord, email или поисковой выдачи, укажите это. Фишинговые домены быстро исчезают, поэтому ранняя фиксация повышает ценность данных. Не возвращайтесь на сайт только ради красивого скриншота после того, как решили прекратить взаимодействие.

Если браузер показывает историю посещений, список расширений или разрешения сайта, сохраните эти данные до очистки. Не запускайте скачанные файлы повторно. Для вредоносного расширения фиксируют название, extension ID, источник установки и permissions, но не нужно передавать кому-либо свои секреты или экспортировать wallet vault.

Скриншот окна подписи особенно важен для офчейн-сценария

Офчейн-подпись может не иметь transaction hash до момента использования, поэтому содержание окна — ключ к пониманию риска. Сохраните domain, chainId, verifyingContract, spender, amount, deadline, nonce и primaryType, если они были видны. Для personal_sign сохраните точный message. Эти поля помогают отличить login от permit, ордера или иной авторизации.

Если скриншота нет, восстановите хотя бы последовательность действий своими словами сразу после инцидента. Память быстро искажает детали, особенно под стрессом. Напишите: какая кнопка была нажата, что обещал сайт, потребовался ли gas, что появилось в кошельке после подтверждения, изменился ли баланс, появился ли новый allowance.

Для биржи или кастодиального сервиса важны hash и адрес назначения

Если средства ушли на адрес, который может принадлежать бирже или платёжному сервису, обращение должно содержать проверяемые факты: сеть, asset, amount, transaction hash, адрес отправителя и адрес получателя, время и объяснение, почему перевод считается несанкционированным. Не отправляйте пароли, seed и приватный ключ даже официальной поддержке.

Сервис может запросить KYC или доказательство владения аккаунтом через свой официальный процесс. Это не то же самое, что просьба прислать seed в чат. Возможность заморозки зависит от обстоятельств и не гарантируется. Чем быстрее сообщение после инцидента, тем выше шанс, что средства ещё не прошли дальнейшее движение, но обещать результат нельзя.

Не платите «комиссию за возврат блокчейн-транзакции»

После кражи часто появляется recovery scam: обещают отменить transaction hash, «разморозить blockchain», взломать адрес получателя или вернуть средства после предоплаты. Публичные сети не предоставляют третьей стороне административную кнопку отката. Реальные варианты зависят от получателя, кастодиального сервиса, суда, правоохранительных процедур или добровольного возврата.

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

Локальные данные устройства нужны при подозрении на malware

Если причиной могло быть расширение или программа, полезны список установленных приложений, browser extensions, время установки, antivirus logs и hashes подозрительных файлов. Не обязательно самостоятельно проводить глубокую форензику, если вы не специалист. Главное — не уничтожить всё до фиксации базовых данных, если сумма и обстоятельства оправдывают дальнейшее расследование.

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

Составьте хронологию без домыслов

Хорошая хронология отделяет факты от предположений. «В 14:12 открыл домен X», «в 14:14 кошелёк показал Sign», «в 14:15 появился hash Y», «в 14:17 token balance уменьшился» — факты. «Сайт точно украл seed» — гипотеза, если seed не вводилась и malware не подтверждена. Такая дисциплина помогает быстрее найти реальную причину.

Отмечайте все защитные действия: revoke hash, transfer на новый кошелёк, disconnect, удаление расширения, смену паролей. Это позволит позже убедиться, что incident response завершён, а не остановился на одном шаге. Хронология также полезна для банка, биржи или полиции, если в ситуации присутствовал фиатный платёж или идентифицируемый контрагент.

Как снизить вероятность неизвестной подписи в будущем

Читайте действие до кнопки Confirm, а не после

Самый сильный контроль — сформировать привычку останавливаться до подписи. Сверяйте сеть, recipient или contract, asset, amount и ожидаемое действие. Если сайт обещает login, а кошелёк показывает approve, это несоответствие. Если обещан swap, но сначала требуется approval, убедитесь, что spender принадлежит ожидаемому router и лимит соответствует задаче.

Не торопитесь из-за countdown, «последнего шанса на airdrop» или угрозы блокировки. Легитимный протокол не должен требовать, чтобы вы подписали непонятную операцию за десять секунд. Если интерфейс скрывает детали, отмените запрос и вернитесь после проверки. Потерянная возможность обычно дешевле потерянного кошелька.

Ограничивайте spending cap вместо постоянного unlimited

Unlimited approvals удобны, потому что уменьшают число будущих транзакций, но расширяют последствия компрометации spender. Для редко используемых dApps задавайте разумный лимит, если кошелёк и контракт позволяют. После завершения работы регулярно пересматривайте allowances и удаляйте те, которые больше не нужны.

Ревизия не должна превращаться в механическое нажатие revoke на всё подряд. Сначала определяйте, какие dApps вы действительно используете. Revoke требует gas и может заставить позже повторно approve, поэтому цель — управляемая поверхность доступа, а не формально пустой список любой ценой.

Разделяйте кошелёк для dApps и кошелёк для хранения

Если один адрес содержит все долгосрочные активы и одновременно ежедневно подписывает новые DeFi-транзакции, одна ошибка получает максимальный радиус поражения. Практичнее иметь отдельный hot wallet с ограниченным балансом для экспериментов и отдельное хранилище, которое редко взаимодействует с неизвестными контрактами.

Такое разделение не заменяет проверку подписей, но снижает потенциальный ущерб. Даже если hot wallet выдаст плохой approval, долгосрочные активы остаются вне этого spender. Переводы между собственными кошельками тоже требуют проверки адресов и сети, поэтому структура должна быть понятной, а не хаотичной.

Используйте аппаратное подтверждение как дополнительный экран проверки

Hardware wallet защищает private key от обычного извлечения на компьютере, но не делает опасную подпись безопасной, если пользователь сам её подтверждает. Его ценность — отдельный доверенный экран и необходимость физического подтверждения. Сверяйте адрес, сумму и тип операции на устройстве, если оно показывает эти данные.

Blind signing или плохо читаемая calldata уменьшают эту пользу. Если устройство не может объяснить действие, относитесь к нему как к повышенному риску. Лучше отказаться от операции, чем подтверждать неизвестный hex только потому, что сайт известен по логотипу или обещает привычный результат.

Проверяйте домен и источник приложения

Фишинг часто копирует дизайн известного dApp один в один, поэтому визуальная похожесть не доказательство. Открывайте сервисы из закладок или официальных источников, проверяйте домен целиком и избегайте ссылок из личных сообщений. Устанавливайте wallet extensions только из официального маршрута и проверяйте publisher.

Если подозрение связано с расширением, используйте отдельную инструкцию о том, как проверить фейковый криптокошелёк или приложение. После такого инцидента полезно пересмотреть browser profile, site permissions и extensions, потому что проблема могла затронуть больше одной подписи.

Понимайте разницу между transaction и signature

Gas — плохой критерий безопасности. Офчейн-подпись может быть бесплатной, но экономически значимой. EIP‑712 делает данные структурированными, но не гарантирует добросовестность приложения. ERC‑2612 permit позволяет изменить allowance на основе подписи. Поэтому важнее понимать поля message, чем смотреть только на размер комиссии.

Полезно заранее прочитать материал о том, как проверить транзакцию по TXID. Когда пользователь узнаёт approve, permit, spender, verifying contract и deadline до инцидента, аварийная диагностика становится намного быстрее и реже требует радикальной миграции.

Проверяйте адреса после копирования

Address poisoning и clipboard malware делают проверку первых и последних символов недостаточной. Для значимых переводов сверяйте полный адрес или несколько групп символов, используйте адресную книгу после первого подтверждённого transfer и аппаратный экран. Не копируйте recipient из истории, если не уверены в его происхождении.

Перед крупным переводом допустим небольшой тест, но только если destination и сеть заранее проверены. Тест не доказывает, что смарт-контракт безопасен; он проверяет маршрут обычного transfer. Для dApp-взаимодействия нужны contract address, ожидаемый метод и понимание финансового эффекта функции.

После каждого нового dApp задайте себе четыре вопроса

Первый: какой актив и какая сеть участвуют? Второй: кому я даю право — recipient, spender, operator или verifying contract? Третий: какое максимальное финансовое последствие этой подписи? Четвёртый: как я прекращу это право после завершения работы? Если хотя бы на один вопрос нет ответа, подпись лучше отложить.

Такой подход масштабируется от простого swap до NFT marketplace, lending, bridge и account delegation. Он не требует читать байткод каждого контракта, но заставляет пользователя проверять ключевые границы полномочий. Именно отсутствие этой границы делает «неизвестную транзакцию» опасной.

Финальная проверка после инцидента

Инцидент можно считать закрытым, когда вы знаете тип подписи, подтвердили фактический blockchain-state, остановили лишние approvals, перенесли активы при необходимости, устранили compromised keys или device и зафиксировали доказательства. Простое отсутствие новых списаний в течение часа — недостаточный критерий.

Если причина осталась неизвестной, не возвращайте крупные активы на старый адрес. Лучше сохранить консервативную модель и продолжить расследование. В self-custody безопасность строится не на обещании сервиса, а на контроле ключа, понимании подписываемых полномочий и способности независимо проверить результат в блокчейне.

Главный вывод прост: неизвестная подпись — это повод перейти от интерфейса к проверяемым данным. Transaction hash, события, allowance, nonce, message fields и состояние ключа дают объективную картину. Чем точнее определён механизм, тем меньше лишних действий и тем выше шанс сохранить оставшиеся активы.

Если нужно именно проверить permissions после подозрительного взаимодействия, пошагово проверьте их и отзовите ненужные разрешения. Если подозрение связано с самим ключом, приоритет — новый seed и перенос. Если уже есть несанкционированные transfers, действуйте как при активной компрометации и не используйте старый кошелёк для новых поступлений.

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

Сценарий 1: подписали approve, но токены ещё на месте. Пользователь открывает explorer и видит успешную транзакцию Approval на неизвестного spender. Баланс USDT не изменился. В этом случае задача — не ждать списания, а подтвердить token contract, размер allowance и spender, затем выполнить revoke через доверенный маршрут и убедиться, что новое значение записано on-chain. Если seed нигде не вводилась, устройство чистое и других неизвестных подписей нет, новый кошелёк может не понадобиться. Однако до подтверждённого revoke адрес не следует пополнять тем же токеном.

Сценарий 2: нажали Sign, gas не было, TxID отсутствует. Это не доказательство безопасности. Нужно восстановить содержимое message: domain, verifyingContract, spender, amount, deadline, nonce или иные поля. Если это permit или другая авторизация, злоумышленник может использовать подпись позже. В зависимости от протокола проверяют способ инвалидировать nonce, изменить allowance или безопасно перенести активы. Когда механизм подписи неясен и сумма значима, консервативное решение — новый чистый адрес, а не ожидание появления первой кражи.

Сценарий 3: после подписи уже появились неизвестные transfers. Здесь incident response становится срочным. Сначала оценивают, скомпрометирован ли только allowance или сам ключ. Если средства уходят без новых подтверждений, есть основания подозревать украденный private key, активный approval, permit или автоматизированный sweeper. Оставшиеся активы переносят на новый кошелёк, созданный в безопасной среде, а старый адрес выводят из эксплуатации. Параллельно сохраняют hashes и уведомляют идентифицируемые сервисы, если средства пришли на их адреса.

Во всех трёх случаях внешне пользователь может описать проблему одинаково: «я что-то подписал и теперь боюсь за кошелёк». Но технически это три разных класса риска. Поэтому хороший аварийный алгоритм не начинается с универсального совета «отзови всё» или «создай новый кошелёк». Он начинается с классификации: есть ли on-chain транзакция, что записано в logs, существует ли allowance, была ли офчейн-подпись, раскрывались ли секреты и наблюдаются ли последующие действия без участия владельца.

Если вы ведёте крупные суммы, полезно заранее подготовить собственный incident checklist: список explorers по используемым сетям, чистый резервный кошелёк, понятный способ проверить approvals, контакты официальной поддержки бирж и процедуру переноса активов. Такой план не требует хранить seed в электронном виде. Напротив, он позволяет при проблеме действовать по заранее проверенной последовательности и не искать решения в случайных чатах.

Самая опасная неизвестная транзакция — не обязательно та, которая выглядит сложнее всего. Иногда один простой unlimited approve опаснее длинного swap-маршрута, а одна бесплатная EIP‑712 подпись важнее дорогой on-chain операции. Оценивайте не внешний вид окна и не gas, а максимальное полномочие, которое фактически получил recipient, spender, operator, verifying contract или delegate.

После завершения разбора сохраните короткий итог для себя: что было подписано, какой риск существовал, какой hash подтвердил защитное действие и почему старый адрес считается безопасным либо выведенным из эксплуатации. Этот итог превращает разовый стрессовый эпизод в полезный опыт и помогает не повторить ту же ошибку при следующем взаимодействии с dApp.

Для контрольной проверки через сутки снова откройте старый адрес в explorer и убедитесь, что после revoke или миграции не появились новые неизвестные операции. Сверьте остаточные balances, approvals и активность во всех сетях, которыми вы действительно пользовались. Если старый ключ признан скомпрометированным, не пытайтесь «проверить его надёжность» новым пополнением: отсутствие немедленной кражи ничего не доказывает. Если же инцидент был локализован одним разрешением, повторная проверка помогает подтвердить, что состояние действительно стабильно и кошелёк не получил новых полномочий без вашего ведома.

Когда инцидент можно считать технически локализованным

Закрывать инцидент только потому, что «деньги пока не ушли», нельзя. Нужен набор проверяемых признаков, соответствующих типу первоначального риска. Если была обычная транзакция перевода, достаточно понять её фактический результат и убедиться, что она не создала дополнительных полномочий. Если был approve, важно подтвердить новое значение allowance после revoke. Если использовался permit или другая офчейн-подпись, нужно установить, могла ли она быть исполнена позднее и существует ли способ сделать её недействительной. При раскрытой seed-фразе никакой revoke не возвращает секрету конфиденциальность: локализация достигается только переносом активов на новый независимый кошелёк и прекращением использования старого ключевого материала.

Полезно мыслить не одним статусом «безопасно/опасно», а четырьмя слоями. Первый — транзакционный: нет ли незавершённых или неизвестных операций. Второй — контрактный: не осталось ли allowances, NFT operators, Permit2-полномочий или иных делегирований. Третий — ключевой: не могла ли seed-фраза, private key или пароль попасть к постороннему. Четвёртый — средовой: не остаётся ли вредоносное расширение, фишинговая вкладка, заражённое устройство или скомпрометированная учётная запись. Только совместная проверка этих слоёв позволяет обоснованно завершить аварийный режим.

Почему полезно провести вторую проверку после защитных действий

Сразу после стресса легко проверить только тот актив, который был виден в интерфейсе кошелька. Но один и тот же EVM-адрес может использоваться в нескольких сетях, NFT могут находиться в отдельных коллекциях, а разрешения — относиться к токенам с нулевым текущим балансом. Поэтому после первичного спасения стоит сделать вторую, более спокойную ревизию: перечислить реально использованные сети, просмотреть историю адреса в каждой из них, проверить остаточные разрешения и убедиться, что не осталось активов, которые позже будут случайно отправлены на старый адрес.

Особое внимание уделяйте адресам, которые сохранены в биржах, адресных книгах, бухгалтерских шаблонах, ботах или у постоянных контрагентов. Если старый кошелёк выведен из эксплуатации, техническая миграция не закончена, пока привычные маршруты пополнения продолжают указывать на него. Обновляйте такие записи только после проверки нового адреса и сети; для значимой суммы разумен тестовый перевод. Это снижает риск, что через неделю пользователь сам вернёт средства на уже скомпрометированный адрес.

Наконец, зафиксируйте причину инцидента одной конкретной формулировкой: «не проверил spender», «перешёл по ссылке из личного сообщения», «подписал typed data без чтения domain», «ввёл seed на веб-странице». Такой пост-инцидентный вывод ценнее абстрактного обещания «быть осторожнее», потому что его можно превратить в правило: неизвестный spender — отказ; seed — только в официальном процессе восстановления; новые dApp — отдельный рабочий кошелёк; крупные активы — минимальные allowances и изолированное хранение.

Проверяйте все сети, где использовался тот же EVM-адрес

Одна из частых ошибок после инцидента — проверить только сеть, которая была выбрана в кошельке в момент подписи. В EVM-экосистеме один и тот же публичный адрес может существовать в Ethereum, BNB Smart Chain, Polygon, Arbitrum, Optimism, Base и других совместимых сетях. Это не означает, что одно разрешение автоматически действует во всех сетях: состояние контрактов раздельное. Но пользователь мог ранее выдавать approvals тому же приложению в нескольких сетях или подписать данные, относящиеся не к той сети, которую он ожидал. Поэтому аудит строят по фактической истории использования адреса, а не по одному текущему переключателю network в интерфейсе.

Составьте список сетей, где у адреса были активы или взаимодействия с dApp. Для каждой сети отдельно проверьте balance нативной монеты, токены, последние transactions, Approval events и NFT operators. Если кошелёк поддерживает автоматическое обнаружение сетей, не воспринимайте отсутствие сети в интерфейсе как доказательство нулевой активности: интерфейс может скрывать сеть, токен или NFT, тогда как блокчейн хранит состояние независимо от отображения. Для значимой суммы полезнее открыть адрес в соответствующем explorer, чем полагаться только на агрегированный баланс приложения.

Мультичейн-проверка особенно важна при миграции. Пользователь может перенести ETH и USDT из одной сети и забыть токены в другой, а через несколько месяцев случайно снова начать пользоваться старым адресом. Если seed признана скомпрометированной, цель — вывести из эксплуатации весь ключ, а не только «очистить Ethereum». Если же проблема локализована конкретным approve в одной сети, не нужно автоматически совершать десятки ненужных транзакций: сначала докажите, где действительно существует риск.

Аппаратный кошелёк не отменяет последствия плохой подписи

Hardware wallet хорошо защищает приватный ключ от прямого извлечения, но не может решить за пользователя, является ли предложенная операция экономически безопасной. Если на устройстве подтверждён approve неизвестному spender, опасный contract call или структурированная подпись с нежелательными параметрами, криптографически корректная подпись будет создана самим владельцем. Поэтому фраза «ключ не покидал аппаратный кошелёк» не означает, что неизвестная операция безопасна. Она лишь снижает вероятность одного класса компрометации — кражи ключевого материала.

После подозрительной подписи с hardware wallet классификация остаётся той же: определить тип действия, проверить on-chain результат, allowances и последующие операции. Если seed аппаратного кошелька не вводилась на компьютере, не фотографировалась и не передавалась третьим лицам, обычно нет оснований считать её раскрытой только из-за плохого approve. В таком случае перенос всего портфеля на новый seed может быть избыточным. Но если фишинговая страница убедила пользователя ввести recovery words «для синхронизации устройства», модель угроз меняется полностью: аппаратный кошелёк больше не защищает раскрытую seed.

Практический вывод прост: аппаратный кошелёк уменьшает риск кражи ключа, а проверка содержания подписи уменьшает риск добровольной авторизации вредоносного действия. Это два разных слоя защиты. Для крупных операций полезно сверять адрес контракта и основные параметры на доверенном экране устройства, а если устройство показывает только непонятный hash или blind signing без расшифровки, повышать уровень осторожности и не подтверждать операцию, смысл которой невозможно независимо проверить.

Если TxID нет, расследование всё равно возможно

Отсутствие TxID означает только то, что вы не видите обычную отправленную в сеть транзакцию. Это полезный факт, но не финальный вывод. Кошелёк мог подписать произвольное сообщение, EIP-712 typed data, permit, ордер, login challenge или авторизацию, которую позже передаст в сеть другой участник. В таких схемах пользователь не платит gas в момент подписи, а relayer или spender может использовать подпись позднее. Поэтому ключевой артефакт — не TxID, а данные, которые фактически были подписаны.

Попробуйте восстановить их из истории dApp, уведомления кошелька, логов браузера, сохранённого скриншота или интерфейса сервиса. Ищите domain name, chainId, verifyingContract, spender, token, amount/value, deadline/expiration, nonce и тип сообщения. Не отправляйте саму seed-фразу для «декодирования». Публичные поля подписи и адрес кошелька обычно достаточно отделить от секретов, чтобы понять механизм. Если вы видите permit или Permit2, проверяйте, изменилось ли on-chain состояние и возможно ли инвалидировать соответствующее разрешение или nonce.

Если содержание подписи восстановить не удаётся, решение зависит от стоимости возможного ущерба. Для пустого рабочего адреса может быть достаточно перестать им пользоваться. Для адреса с крупным портфелем неопределённость сама по себе становится фактором риска: безопаснее перенести активы на новый адрес, чем ждать, пока неизвестная подпись будет использована. При этом перенос выполняют из чистой среды и не подписывают дополнительные «cancel» операции на том же подозрительном сайте.

Сохраняйте различие между доказательством и предположением

В инциденте легко перейти от одного факта к цепочке недоказанных выводов. Например, факт: после взаимодействия появился Approval event. Предположение: «сайт украл seed». Эти утверждения не равнозначны. Approval доказывает изменение allowance, но не доказывает утечку приватного ключа. И наоборот, отсутствие Approval не доказывает безопасность, если пользователь ввёл seed на фишинговой странице. Хорошая диагностика помечает каждый вывод как подтверждённый on-chain, подтверждённый локальными данными или пока гипотетический.

Такой подход помогает выбрать пропорциональную реакцию. Подтверждённый unlimited approval неизвестному spender требует revoke и проверки последующих transfers. Подтверждённая утечка seed требует миграции. Неясное всплывающее окно без подписи и без изменений on-chain может требовать очистки браузера и наблюдения, но не обязательно дорогостоящего переноса всех активов. Разделение фактов и гипотез снижает одновременно две опасности: недореагировать на реальную компрометацию и совершить множество рискованных действий из-за паники.

Для себя можно оформить короткую таблицу инцидента: время, сеть, адрес, сайт, действие, TxID или тип подписи, обнаруженные изменения, защитная операция и финальный статус. Не храните в ней seed, private key или секретные коды. Такая запись полезна при повторной проверке, обращении в официальную поддержку сервиса и сравнении с будущими подозрительными событиями. Чем точнее сохранены публичные технические данные, тем меньше приходится полагаться на память и скриншоты без контекста.