Что именно вы подписываете в криптокошельке

1. Одна кнопка скрывает несколько разных действий

Кошелёк хранит или использует ключ, а действительная подпись подтверждает выполнение условий авторизации этим ключевым материалом — не личность и не намерение физического владельца. Но слово Sign не объясняет последствие. Иногда сайт только просит показать публичный адрес, иногда — доказать технический контроль над ним, а иногда — подписать данные, которые контракт сможет исполнить позже. Поэтому вопрос перед нажатием звучит не «доверяю ли я сайту вообще», а «какое право я создаю сейчас и для кого».

2. Connect показывает адрес, но не подписывает перевод

Подключение обычно даёт dapp доступ к выбранному публичному адресу, активной сети и событиям вроде смены аккаунта. Это нужно, чтобы показать баланс или подготовить следующий запрос. Само по себе соединение не должно отправлять активы и не создаёт token allowance. TRON Wallet Adapter также разделяет состояния connected и address, подключение и функцию signMessage; для транзакций существует отдельная поверхность API.

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

3. Login message создаёт сессию, а не перевод

Валидная подпись сообщения удовлетворяет выбранным правилам проверки для адреса в этот момент. Она не раскрывает private key, не устанавливает личность или фактическое намерение владельца и обычно не требует сетевой комиссии. Но из этого не следует, что сообщение безобидно: сервер может использовать подпись как авторизацию, а специально составленные данные — как право на другое действие.

ERC-4361, Sign-In with Ethereum, задаёт читаемый формат входа. В нём есть домен, адрес, URI, chain ID, nonce, время выдачи и при необходимости срок действия и список ресурсов. Nonce нужен серверу против повторного входа с той же подписью, а домен связывает согласие с конкретным сайтом. Стандарт не превращает любой произвольный текст с фразой «Sign-In» в настоящий SIWE-запрос.

4. Typed data делает поля видимыми, но не делает запрос безопасным

EIP-712 описывает подпись структурированных данных вместо непрозрачной последовательности байтов. Кошелёк может показать названия полей, значения и signing domain. В domain входят, когда это уместно, имя приложения, версия, chainId и verifyingContract. Это даёт человеку больше контекста, но смысл каждого поля всё равно определяет приложение и контракт.

5. Транзакция предназначена для исполнения в сети

Транзакция может перевести нативную монету или вызвать функцию контракта. Подпись авторизует точный payload, но запись появляется в блокчейне только после отправки. Интерфейс часто совмещает signing и broadcast, поэтому до подтверждения сверьте отправителя, сеть, получателя или контракт, актив, сумму, функцию и предельную комиссию.

Перед переводом полезно отдельно разобрать, как безопасно перевести криптовалюту: реквизиты подтверждают независимым каналом, а сеть и адрес сверяют полностью. Экран подписи — последняя проверка, а не место, где впервые узнают получателя.

6. Approve и permit дают право на будущее действие

Approve обычно является on-chain вызовом токен-контракта: владелец задаёт, сколько указанный spender сможет потратить через механизм токена. Это не перевод в момент подтверждения, однако право может быть использовано позже. Permit решает похожую задачу через подпись сообщения по правилам конкретного токена или протокола; такую подпись другая сторона может отправить в сеть позднее.

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

7. Blind signing лишает вас главной проверки

При blind signing кошелёк или аппаратное устройство не расшифровывает действие и показывает hash, hex-строку либо общее предупреждение. Ключ может оставаться внутри защищённого устройства, но человек не видит, какое намерение закрепляет подпись. Защита ключа и проверка смысла операции — разные задачи.

8. Что делать после подозрительной подписи

Сначала сохраните домен, время, скриншот запроса, выбранный адрес и, если он появился, tx hash. Не подписывайте «отмену», которую предлагает тот же сайт: это может быть второй вредоносный запрос. Дальнейшее действие определяется типом уже выданного права.

Если транзакция ушла в сеть, инструкция о том, как проверить криптотранзакцию, поможет отличить signed, pending, failed и confirmed. Если посторонний увидел резервную фразу, одной смены пароля недостаточно: правила о том, как хранить seed-фразу, применяются уже к новому кошельку, а старую фразу считают скомпрометированной.