Разработка криптокошельков: кастоди, потоки и безопасность в правильном порядке

Что включает разработка кошелька?

Быстрый тест: Ответьте одной строкой: кто держит ключи? Если ответ неясен, вы не готовы проектировать.

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

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

В начале мы составляем карту:

• Кто будет использовать кошелёк и что им нужно сделать в первую очередь.
• Является ли продукт кастодиальным или некастодиальным.
• Какой формат сдачи работ подходит продукту: расширение для браузера, мобильное приложение или Telegram Mini App.
• Какие блокчейны, типы транзакций и своп-потоки запланированы.
• Какие бэкенд, мониторинг и операционная поддержка нужны продукту.

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

Как выбрать тип кошелька и платформу?

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

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

Формат сдачи работ также меняет объём работы:

Кошелёк может поддерживать более одного блокчейна, но список должен соответствовать фактическим требованиям продукта. Для связанного продукта Telegram согласуйте потребности кошелька с разработкой Telegram-ботов и Mini App; для отдельного мобильного опыта рассмотрите разработку мобильного приложения.

Транзакционные потоки и интеграции, которые нужно спланировать

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

Области, которые обычно нужно определить, включают:

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

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

Для любой связанной функциональности смарт-контрактов согласуйте план кошелька с разработкой смарт-контрактов. Держите публичное объяснение продукта и инструкции внутри кошелька согласованными; Web3-сайт и лендинг могут помочь объяснить, как работает кошелёк, не перегружая интерфейс.

Что вы получаете в процессе разработки?

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

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

Типичное взаимодействие охватывает:

• Составление карты требований и пользовательских потоков для выбранного формата кошелька.
• Архитектурные решения для кастоди, блокчейнов, требований к транзакциям и свопам.
• Работу над интерфейсом и реализацию согласованных функций.
• Интеграционную работу и компоненты бэкенда там, где они нужны продукту.
• Проверку безопасности и подготовку материалов для внешнего аудита, если требуется.
• Заметки по передаче для доставленного плана и следующих продуктовых решений.

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

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

Обеспечение безопасности кошелька и управление рисками запуска

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

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

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

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

Ваш чек-лист из 7 пунктов для планирования кошелька

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

• Решите, кто держит ключи: пользователь или сервис.
• Выберите платформы: расширение, мобильное приложение или мини-приложение.
• Составьте список блокчейнов и токенов на запуске.
• Составьте карту 3 основных потоков: получение, отправка и своп.
• Спланируйте восстановление и то, что видят пользователи, когда что-то идёт не так.
• Забронируйте проверку безопасности до запуска.
• Проверьте юридические правила для ваших рынков.

Термины одной строкой

Кастодиальный кошелёк означает кошелёк, в котором сервис держит ключи для пользователя.

Некастодиальный кошелёк: кошелёк, в котором только пользователь держит ключи.

Когда имеет смысл кастомный кошелёк?

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

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

• Что пользователь должен иметь возможность сделать в первом релизе?
• Кто отвечает за операции с ключами и поддержку пользователей?
• Какие блокчейны и типы транзакций необходимы при запуске?
• Нужен ли продукту расширение для браузера, мобильное приложение, Telegram Mini App или комбинация?
• Какие интеграции уже выбраны, а какие ещё требуют изучения?
• Какие проверка безопасности и юридические рекомендации должны быть готовы до релиза?

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

Отправьте 3 вещи: ваш выбор кастоди, ваши целевые платформы и ваш список блокчейнов.

Как мы работаем

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