Как добавить поддержку новых токенов в старый мобильный кошелёк без перезапуска

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

Почему перезапуск — это плохо

Перезапуск приложения — это не просто «обновить и всё». Это:

Потеря пользователей, которые не обновляют приложение — а их до 30% в первые 2 недели после релиза.
Риск, что пользователь удалит приложение, если увидит, что «опять что-то обновилось».
Задержка: ты ждёшь 3–7 дней на модерацию в App Store и Google Play.
Сложность: нужно тестировать всё заново, писать changelog, готовить push-уведомления.

А если ты добавляешь токен для нового проекта, который только вышел — и ты хочешь успеть к хайпу? Перезапуск — это смерть скорости.

Как работает «горячая» поддержка токенов

Всё строится на одном принципе: конфигурация должна быть динамической.

Если токены жёстко прописаны в коде приложения — ты не можешь их менять без пересборки. Но если они приходят с сервера — ты можешь добавить, удалить или изменить их в любой момент.

Пример: твой кошелёк при запуске загружает список поддерживаемых токенов с API. Не из бандла, не из базы данных приложения — а по HTTP-запросу. Ты просто меняешь JSON на сервере — и через 5 минут у всех пользователей появляется новый токен.

Пошаговая инструкция: как настроить

Убери токены из кода. Если у тебя есть массив вроде const supportedTokens = ['ETH', 'USDT', 'WBTC'] — удали его. Это твоя первая ошибка, если ты ещё этого не сделал.
Создай API-эндпоинт. Например: https://your-wallet-api.com/tokens. Он должен возвращать JSON с полями: address, symbol, name, decimals, logoUrl, chainId.
Настрой клиентскую логику. При старте приложения (или при открытии экрана токенов) делай GET-запрос к этому эндпоинту. Загружай данные в память. Замени статический список на динамический.
Добавь кэширование. Не запрашивай токены при каждом открытии кошелька. Кэшируй ответ на 1–4 часа. Это снизит нагрузку на сервер и ускорит загрузку.
Сделай fallback. Если API недоступно — используй последний известный набор токенов (хранится в локальном хранилище). Это защитит от падений при отсутствии интернета.
Добавь версию конфига. В ответе API возвращай configVersion: 123. Приложение проверяет: если версия изменилась — обнови список и сбрось кэш. Это предотвратит кэширование устаревших данных.

Пример JSON-ответа API

{
  "configVersion": 47,
  "tokens": [
    {
      "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
      "symbol": "USDT",
      "name": "Tether USD",
      "decimals": 6,
      "chainId": 1,
      "logoUrl": "https://your-cdn.com/tokens/usdt.png"
    },
    {
      "address": "0x514910771af9ca656af840dff83e8264ecf986ca",
      "symbol": "LINK",
      "name": "Chainlink",
      "decimals": 18,
      "chainId": 1,
      "logoUrl": "https://your-cdn.com/tokens/link.png"
    }
  ]
}

Этот ответ можно менять вручную через админку — или автоматически через CI/CD, если ты добавляешь токены по расписанию.

Что делать, если токен на другой сети?

Если ты поддерживаешь только Ethereum, а новый токен — на Polygon или Arbitrum — это не проблема. Просто добавь в JSON поле chainId. Приложение уже должно уметь работать с несколькими сетями (если не умеет — это другая задача).

Ты не добавляешь новую сеть в код — ты просто добавляешь токен с другим chainId. Приложение отображает его в соответствующей сети. Пользователь видит: «LINK на Arbitrum» — и может переводить токен туда, как и раньше.

Если ты не поддерживаешь эту сеть вообще — тогда тебе нужно добавить поддержку сети. Но это уже не «горячая» замена токена — это расширение функционала. И тут уже без обновления не обойтись.

Сравнение подходов: статический vs динамический

Критерий	Статический (в коде)	Динамический (через API)
Время добавления токена	3–7 дней (релиз + модерация)	5 минут (обновление JSON)
Требуется перезапуск	Да, обязательно	Нет
Поддержка новых сетей	Только через обновление приложения	Можно, если сеть уже поддерживается
Риск ошибки	Высокий (нужно тестировать всё заново)	Низкий (только JSON, без кода)
Сложность реализации	Просто — но жёстко	Сложнее на старте, но гибче
Поддержка старых версий	Нет — только новая версия	Да — все версии получают новые токены

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

Частые ошибки

Загружаешь токены при каждом открытии кошелька. Это грузит сервер и замедляет загрузку. Кэшируй. 1–4 часа — норма.
Не проверяешь версию конфига. Пользователь с кэшем может видеть устаревший список. Добавь configVersion — это спасёт тебя от багов.
Используешь несуществующие адреса. Ты добавил токен, но адрес — фейковый или несуществующий. Проверяй адреса через Etherscan или аналоги. Даже если это твой собственный токен — протестируй на тестнете.
Не проверяешь decimals. Если ты указал decimals: 8 для токена, который на самом деле имеет 18 — баланс будет отображаться как 100 000 000 раз меньше. Это катастрофа.
Используешь HTTP, а не HTTPS. Некоторые приложения блокируют HTTP-запросы. Убедись, что твой API работает по HTTPS.
Не добавляешь логотипы. Пользователь видит просто «NEW_TOKEN» — и не понимает, что это. Логотипы — это не «прикольно», это часть доверия.

Когда нужно обновлять приложение

Динамическая загрузка токенов — это мощный инструмент, но у него есть границы. Тебе всё равно придётся выпускать обновление, если:

Ты добавляешь новую блокчейн-сеть (например, Solana или Base, если раньше не поддерживал).
Меняется способ подписи транзакций (например, переход с EIP-1559 на EIP-4844).
Ты добавляешь поддержку NFT или новых типов контрактов (например, ERC-1155).
Ты меняешь API-интерфейс кошелька (например, добавляешь стейкинг или ликвидность).

В этих случаях — обновляй приложение. Но для добавления нового токена в уже поддерживаемой сети — нет. Не нужно.

Сценарии выбора: что делать в твоей ситуации

Вот как принимать решение:

Если ты добавляешь токен на Ethereum, BSC, Polygon или другой уже поддерживаемый чейн — используй динамическую загрузку. Загружай через API. Добавляй в JSON. Готово.
Если ты добавляешь токен на новой сети — тебе нужно обновить приложение. Но можно сделать так: добавь токен в API с флагом networkSupported: false. Пользователь увидит его, но не сможет отправлять. В следующем релизе включи поддержку — и удали флаг. Так ты синхронизируешь ожидание и функционал.
Если твой кошелёк устарел и не умеет работать с несколькими сетями — сначала сделай архитектурный рефакторинг. Без этого динамические токены не сработают. Это не «горячая замена» — это «переписывание подсистемы».
Если ты не можешь поднять API — используй Firebase Remote Config или AWS AppConfig. Это облачные сервисы, которые позволяют менять конфиги без релиза. Ты не пишешь сервер — ты просто настраиваешь ключи.

Как лучше сделать — рекомендации

Сделай админку для управления токенами. Даже простую: форма с полями — адрес, символ, название, логотип, сеть. Сохраняет в базу — и генерирует JSON. Это сэкономит тебе часы в будущем.
Подключи мониторинг: если токен не загрузился у 5% пользователей — пришли алерт. Это может быть проблема с CDN, DNS или API.
Добавь логирование: «Токен USDT добавлен в конфиг v47 — загружено 12 345 пользователями». Это поможет понять, как быстро токены распространяются.
Не используй сторонние сервисы вроде CoinGecko для получения списка токенов. Они не знают, какие токены ты поддерживаешь — они знают, какие есть в мире. Ты должен сам решать, какие добавлять.
Проверяй токены на наличие балансов у пользователей. Если ты добавляешь токен, который никто не держит — зачем? Проверь на блокчейне: есть ли хотя бы 100 адресов с балансом > 0.01.

Итог: что делать прямо сейчас

Если ты читаешь это — значит, у тебя есть старый кошелёк, и ты хочешь добавить токен без релиза. Вот что делать:

Найди в коде список токенов. Удали его.
Создай простой API-эндпоинт (на Node.js, Python, или даже через Firebase Functions).
Сделай его возвращать JSON с токенами, как в примере выше.
В приложении добавь загрузку этого JSON при старте.
Добавь кэширование и версию конфига.
Загрузи первый токен в JSON — и проверь, что он появляется в приложении без перезапуска.
Сделай админку — чтобы не править JSON вручную.

Это займёт 1–2 дня. Не неделю. Не месяц. И после этого ты будешь добавлять токены за 5 минут — без релизов, без модерации, без потерь пользователей.

Ты не улучшаешь кошелёк — ты меняешь его архитектуру. И это не «маленький фикс». Это переход от статичного продукта к живому сервису.

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