Криптокошелёк · Безопасность сети

Как сделать так, чтобы отправка «не в ту сеть» не проходила без предупреждения

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

Проблема

Большинство людей думают, что если криптоадрес «выглядит правильно» — отправлять на него безопасно. Это не так. Такие сети, как Ethereum, BNB Smart Chain и Polygon, используют абсолютно одинаковый формат адреса — кошелёк примет и отправит транзакцию без единого возражения, но если принимающая сторона отслеживает другую сеть, средства не придут никуда. В отличие от банковского перевода на закрытый счёт, здесь нет отката назад. Транзакция становится финальной в момент подтверждения.

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

Инсайт, который определил решение

Почему одной валидации недостаточно

Адрес Ethereum (ERC-20) и адрес BNB Smart Chain (BEP-20) совпадают посимвольно по формату — оба начинаются с 0x и продолжаются 40 hex-символами. Это значит, что проверка формата адреса, какой бы хорошей она ни была, структурно не может поймать именно эту ошибку. Единственная настоящая защита — сделать выбор сети явным, невозможным пропустить элементом интерфейса, а не деталью, спрятанной в выпадающем списке.

Решение

Для активов, существующих более чем в одной сети (начиная с USDT — самого распространённого мультисетевого актива), флоу отправки теперь требует явного выбора сети ещё до того, как можно будет ввести адрес:

Отдельный селектор сети — Ethereum, BNB Smart Chain и Tron показаны как раздельные, чётко подписанные варианты со своей комиссией, а не техническая деталь в выпадающем списке
Постоянное предупреждение прямо под селектором, видимое всё время, пока пользователь заполняет форму, а не только на финальном шаге подтверждения
Валидация адреса привязана к выбранной сети — адрес в формате Tron мгновенно отклоняется, если выбран Ethereum, что ловит именно те ошибки, которые проверка формата способна поймать
Визуальное эхо адреса — первые и последние символы введённого адреса показываются жирным шрифтом под полем ввода, чтобы ошибку копирования было легче заметить глазом перед отправкой
Подсказка о тестовой транзакции, которая появляется автоматически для крупных сумм и предлагает сначала отправить небольшую сумму — тот же совет, что даёт справка любого кошелька, но показанный именно в тот момент, когда он действительно важен, а не спрятанный в разделе поддержки

Как я это построил на самом деле

Как и с первым проектом, хочу быть честным насчёт процесса. Я исследовал эту проблему вместе с Claude — читал реальные отчёты об инцидентах и документацию поддержки кошельков, пока проблема совпадения форматов ERC-20/BEP-20 не выделилась как реальный механизм большинства этих потерь, а не просто «люди невнимательны». Именно этот конкретный инсайт определил решение: баннер с предупреждением сам по себе был бы общим советом; понимание того, почему проверка формата не срабатывает — вот что оправдало создание отдельного, невозможного пропустить шага выбора сети.

Сам интерфейс — флоу кошелька, обмена и отправки — был построен как рабочий код с помощью AI, поверх дизайн-системы, направление которой задавал я (цветовая палитра, логика раскладки, что подчёркивается, а что нет). Я сам проверил реализацию, в том числе намеренно пытался сломать валидацию некорректным вводом, прежде чем назвать это готовым.