Создание и привязка кошельков

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

В crypto/TON/GRAM-проекте кошельки могут появляться в системе двумя способами:

• генерироваться внутри проекта;
• добавляться извне, если у пользователя или администратора уже есть сторонние кошельки.

Оба сценария нужно учитывать в архитектуре заранее.

Генерация кошельков внутри системы

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

Обычно процесс выглядит так:

1. Пользователь или администратор запускает создание кошелька.
2. Система генерирует новый кошелёк.
3. Кошелёк получает уникальный адрес.
4. Адрес привязывается к конкретному пользователю, аккаунту, заявке или внутренней сущности проекта.
5. В базе фиксируется тип кошелька, сеть, статус, дата создания и владелец.
6. Кошелёк становится доступен для пополнения, вывода, проверки баланса или других операций.

Важно, чтобы генерация кошелька не была просто “созданием строки в базе”. Система должна понимать, кому принадлежит кошелёк, для каких операций он используется, активен он или нет, можно ли через него принимать средства, можно ли делать вывод, какие ограничения и статусы у него есть.

Добавление сторонних кошельков

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

Такой механизм нельзя пропускать, потому что в ТЗ может быть не только “создать кошелёк”, но и “импортировать существующие кошельки”.

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

Пример логики загрузки:

word1 word2 word3 ...
word1 word2 word3 ...
word1 word2 word3 ...

Каждая строка обрабатывается как отдельный кошелёк. После загрузки система должна разобрать список, проверить формат, создать записи в базе и пометить такие кошельки как загруженные извне.

В дальнейшем механизм можно расширить и добавить загрузку через JSON, XML или CSV, если проекту потребуется более сложный импорт. Но для первой версии достаточно мультистрочного добавления, чтобы не усложнять MVP.

Как хранить и помечать загруженные кошельки

Для кошельков, добавленных извне, важно хранить отдельный признак. Например:

• кошелёк создан системой;
• кошелёк загружен пользователем или администратором;
• кошелёк импортирован из внешнего списка.

Это нужно не только для истории, но и для дальнейшей фильтрации. В таблице кошельков должен быть фильтр, который позволяет показать только загруженные кошельки.

Например:

• все кошельки;
• созданные системой;
• загруженные извне;
• активные;
• неактивные;
• привязанные;
• непривязанные.

Так администратор сможет быстро отделить системные кошельки от импортированных и работать только с нужной группой.

Работа с таблицей кошельков

После загрузки кошельки должны попадать в общую таблицу. В таблице желательно показывать:

• адрес кошелька;
• тип или сеть;
• способ добавления;
• привязанного пользователя или сущность;
• статус;
• дату добавления;
• последний известный баланс;
• дату последней проверки;
• служебные ошибки, если они были.

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

Также в таблице нужен массовый выбор:

• выбрать один кошелёк;
• выбрать несколько кошельков;
• выбрать все на странице;
• выбрать все по фильтру;
• снять выделение.

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

Фильтрация и массовые действия

Если кошельков много, простого списка недостаточно. Нужны фильтры и чекбоксы.

Например, администратор выбирает фильтр “только загруженные кошельки”, после чего может отметить нужные записи или выбрать все найденные.

Дальше над выбранными кошельками можно выполнять действия:

• проверить статус;
• обновить баланс;
• привязать к пользователям;
• пометить как активные или неактивные;
• отправить в обработку;
• экспортировать;
• исключить из дальнейшей работы.

Такой подход удобнее, чем обрабатывать каждый кошелёк вручную.

Безопасность при работе с кошельками

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

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

Важно фиксировать:

• кто добавил кошелёк;
• когда он был добавлен;
• каким способом он был добавлен;
• кто просматривал или изменял запись;
• какие действия выполнялись с кошельком;
• были ли ошибки при обработке.

Для финансовых сценариев это критично: любая операция должна быть проверяемой, а история действий — восстановимой.

Итоговая логика модуля

Модуль кошельков должен поддерживать не только генерацию новых адресов, но и импорт сторонних кошельков.

Минимальный рабочий сценарий:

1. Система умеет создавать кошельки автоматически.
2. Администратор может загрузить список сторонних кошельков многострочным вводом.
3. Каждая строка обрабатывается как отдельный кошелёк.
4. Загруженные кошельки добавляются в общую таблицу.
5. Для них сохраняется признак “загружен извне”.
6. В таблице есть фильтр по загруженным кошелькам.
7. Через чекбоксы можно выбрать один, несколько или все кошельки.
8. С выбранными кошельками можно выполнять дальнейшие действия.

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