3 поверхности кошелька, один чек-лист для старта
На столе 3 поверхности кошелька: расширение для браузера, мобильное приложение и Telegram Mini App. Мы начинаем с определения потребностей пользователей и ключевых обязанностей.
Перед тем как забронировать реализацию, отправьте нам эти 7 пунктов:
- Пользователи: кому нужен кошелек и какая задача их приводит?
- Хранение: кастодиальное, некастодиальное или еще на рассмотрении?
- Управление ключами: кто контролирует каждое действие, связанное с ключами?
- Сети: какие блокчейны и активы нужны в первом релизе?
- Действия: переводы, обмены или и то и другое?
- Формат: расширение для браузера, мобильное приложение, Telegram Mini App или комбинация?
- Существующая работа: дизайны, интеграции, компоненты бэкенда или заметки по безопасности?
Эти ответы удерживают фокус первого релиза. Они не дают списку функций расширяться без решения. Мы превращаем ваши вводные в четкие границы продукта. Сюда входит и то, что будет позже.
Если действия кошелька связаны с dApp, согласуйте требования с разработкой dApp. Если кошелек опирается на актив проекта, добавьте создание и развертывание токена в то же обсуждение продукта.
Какая модель хранения подходит пользователям вашего кошелька?
2 модели хранения создают разные обязанности по продукту: кастодиальная и некастодиальная. Решите, кто контролирует управление ключами, до утверждения экранов, сценариев учетных записей или операционных задач.
Кастодиальный кошелек помещает управление ключами в операционную модель продукта. Это может подойти для сервиса, где команда управляет доступом пользователей и связанными операциями.
Некастодиальный кошелек передает контроль над ключами пользователю. Его интерфейс должен четко объяснять эту ответственность. Процесс восстановления также должен быть легко понятен.
Используйте эти 3 решения, чтобы выбрать направление:
- Контроль: кто отвечает за действия, связанные с ключами?
- Восстановление: что должны понимать пользователи, если потеряют доступ?
- Операции: что ваша команда должна поддерживать после запуска?
Затем опишите каждое действие кошелька от входа до подтверждения. Для переводов и обменов определите, что видят пользователи перед подтверждением. Также определите состояния, показываемые, когда действие не может быть завершено. Фиксируйте решения на простом языке продукта.
Если вам также нужна работа с контрактами, свяжите требования к кошельку с разработкой смарт-контрактов. Кошелек в составе более широкого продукта можно спланировать с Web3-разработкой.
3 формата, разная работа над криптокошельком
3 формата формируют разные интерфейсы и потребности в интеграции. Выберите первый релиз, исходя из основной задачи пользователя. Затем укажите, какие именно сети и действия он поддерживает.
| Формат | Что это | Срок релиза | Что вы отправляете |
|---|---|---|---|
| Расширение для браузера | Действия кошелька в браузерном потоке продукта | Устанавливается после согласования функций и интеграций | Пользовательские сценарии, целевые сети, потребности связанного продукта |
| Мобильное приложение | Мобильный интерфейс кошелька | Устанавливается после согласования действий и платформенных требований | Задачи учетной записи, транзакционные потоки, дизайн-материалы |
| Telegram Mini App | Действия кошелька внутри продукта Telegram | Устанавливается после согласования функций Mini App | Необходимые действия, интеграции, связанные функции Telegram |
Относитесь к поддержке нескольких сетей как к именованному списку сетей, а не к широкому заявлению. Для каждой сети укажите действия кошелька, необходимые пользователям. Выделите обмены в отдельный поток. Определите шаги, видимые пользователю, необходимую интеграцию и детали подтверждения. Это упрощает решения по первому релизу.
Для мобильного продукта сравните смежные потребности с разработкой мобильных приложений для Web3-продуктов. Для функций Telegram, выходящих за рамки интерфейса кошелька, ознакомьтесь с разработкой Telegram-ботов и мини-приложений.
5 этапов от брифа продукта до сдачи
5 этапов делают разработку кошелька контролируемой: вводные по продукту, решения по релизу, дизайн, реализация и сдача. Мы подтверждаем работу до начала сборки.
- Вводные по продукту: Поделитесь целевыми пользователями, направлением хранения, форматом, сетями и ключевыми действиями.
- Решения по релизу: Отделите обязательные функции от будущих дополнений. Зафиксируйте интеграции и ответственных за открытые вопросы.
- Дизайн: Опишите шаги учетной записи, транзакций и обменов, включая то, что пользователи должны подтвердить.
- Реализация: Создайте согласованный интерфейс и функции кошелька. Добавьте необходимые компоненты бэкенда или мониторинга.
- Проверка и сдача: Сверьте сборку с согласованными требованиями. Перечислите открытые вопросы и следующие действия.
Мы отправляем письменную смету в течение 2 рабочих дней после рассмотрения деталей вашего продукта. Работа может начаться в течение 24 часов после подтверждения оплаты. Перед стартом DigitalMedia1 проверяет модель хранения, целевой формат, список сетей, действия пользователей и ответственных за проверку в одном коротком чек-листе.
Во время сдачи работ мы фиксируем прогресс по согласованным функциям. Мы поднимаем изменения до их добавления. При сдаче вы получаете четкую запись выполненной работы, открытых вопросов и подготовки к аудиту безопасности. Приносите существующие дизайны и заметки по интеграции. Они помогают нам быстрее определить первый релиз.
Что требует решения перед запуском кошелька?
4 проверки перед запуском имеют значение: обязанности по ключам, поддерживаемые действия, операционная ответственность и статус проверки. Сверьте каждую с кошельком, которым будут пользоваться.
Перед релизом убедитесь, что:
- Интерфейс объясняет модель хранения и обязанности пользователя.
- Шаги транзакций и обменов соответствуют утвержденному поведению продукта.
- Команда знает, какие задачи бэкенда и мониторинга она будет выполнять.
- У вопросов по аудиту безопасности есть ответственные и последующие действия.
Для кастодиальных продуктов ваш юрист должен проверить регуляторную классификацию перед запуском. Разработка может включать согласованный аудит безопасности и подготовку к аудиту. Внешний аудитор контролирует свои выводы. Сетевые условия и доступность сторонних интеграций также находятся вне контроля команды разработки.
Если кошелек является частью более крупного приложения, согласуйте следующий релиз с разработкой dApp. Вы также можете спланировать более широкую разработку с Web3-разработкой. Отправьте нам бриф продукта, предполагаемую модель хранения, целевой формат и сети первого релиза. Мы проверим чек-лист и вернем письменный план разработки.
Как мы работаем
- Отправьте вводные по кошелькуПоделитесь целевым пользователем, направлением хранения, форматом сдачи, сетями и основными действиями.
- Определите первый релизПодтвердите потребности в транзакциях и обменах, интеграциях, работе бэкенда и ожиданиях по мониторингу.
- Опишите пользовательские сценарииСогласуйте экраны, ключевые действия и состояния подтверждения до начала реализации.
- Соберите и проверьтеМы реализуем согласованные функции и сверяем прогресс с записанными требованиями.
- Подготовьте сдачуПроверьте выполненную работу, открытые вопросы и вопросы для вашего юриста или аудитора.
Частые вопросы
Что мне отправить для получения сметы на криптокошелек?
4 вводных запускают первое рассмотрение: направление хранения, целевой формат, поддерживаемые сети и необходимые действия кошелька. Добавьте существующие дизайны, детали интеграции и потребности бэкенда, если они есть. Стоимость зависит от формата, функций и интеграций. Вы получаете фиксированную письменную смету в течение 2 рабочих дней, до оплаты.
Может ли один кошелек поддерживать кастодиальных и некастодиальных пользователей?
2 подхода к хранению могут быть рассмотрены, но для каждого нужны четкие обязанности по ключам и пользовательские сценарии. Сначала мы подтверждаем, уместны ли оба в одном продукте. Затем мы определяем, что должна делать каждая группа пользователей. Это решение влияет на дизайн интерфейса, операции и требования к проверке, поэтому примите его до планирования реализации.
Можете ли вы разработать кошелек как Telegram Mini App?
1 Telegram Mini App может быть частью согласованного формата кошелька. Мы определяем, какие действия кошелька входят в него, какие интеграции нужны и требуются ли связанные функции Telegram. Отправьте предполагаемый пользовательский сценарий и обязательные действия. Мы отделим первый релиз от будущих дополнений.
Сколько времени занимает разработка криптокошелька?
1 график сдачи следует за выбранной моделью хранения, форматом, функциями, интеграциями и этапами проверки. У сфокусированного MVP другая последовательность, чем у более широкой production-сборки. После рассмотрения ваших вводных мы излагаем этапы разработки и сроки в письменном плане. В нем также указано, когда вашей команде нужно утверждать решения.
Что включает работа по безопасности кошелька?
3 области могут быть спланированы: согласованные сценарии кошелька, подход к управлению ключами и необходимые интеграции или компоненты бэкенда. Мы также готовим материалы для внешнего аудита, если он включен. Ваша команда продукта должна назначить ответственных за проверку на раннем этапе. Для кастодиальных продуктов попросите вашего юриста проверить регуляторную классификацию перед запуском.
Можете ли вы гарантировать, что внешний аудит одобрит кошелек?
1 аудитор проводит собственную оценку. Мы можем разработать согласованные функции кошелька, провести аудит безопасности, включенный в план, и подготовить материалы для аудита. Мы не можем влиять на выводы аудитора. Мы фиксируем последующие действия по проверке, чтобы ваша команда могла назначить ответственных и решить открытые вопросы до запуска.
Расскажите о проекте
Ответьте на четыре коротких вопроса — менеджер в течение часа пришлёт план, сроки и вилку бюджета. Всё строго конфиденциально.
Загружаем форму…