Разработка криптокошелька: сколько стоит, какую архитектуру выбрать и когда проще без него

Стоимость зависит от трёх вещей: архитектуры безопасности, количества поддерживаемых сетей и юрисдикции. Ориентиры:

• MVP — некастодиальный кошелёк, одна сеть: $20–150 тыс.
• Standard — MPC, мультичейн, розничный продукт: $100–350 тыс.
• Enterprise — кастодиальный с HSM, институциональный: $200 тыс. и выше

Сроки: от 4 до 12+ месяцев. Но прежде чем считать бюджет, стоит разобраться, нужен ли вам собственный кошелёк вообще. В половине случаев задача решается готовым SDK или white-label решением за меньшие деньги и сроки.

К нам регулярно приходят с запросом «нам нужен криптокошелёк как MetaMask, только наш». Через две недели обсуждений обычно выясняется, что MetaMask им не нужен в принципе. Нужна авторизация в Web3-приложение, возможность подписать транзакцию или хранилище ключей для пары сценариев — задачи, которые решаются не разработкой кошелька, а его интеграцией. Поэтому первый вопрос на любой встрече не «сколько стоит», а «зачем». Если на «зачем» нет внятного ответа, обсуждать бюджет бессмысленно: можно посчитать как $80k, так и $800k, и оба числа будут правдой для разных задач.

Эта статья — попытка разложить тему по полочкам так, как мы сами объясняем её клиентам. Без хайпа и без обещаний, что кошелёк «откроет новые возможности».

Криптокошелёк — это в первую очередь хранилище приватных ключей и интерфейс к блокчейну. Всё остальное (UX, дизайн, кнопка «купить за рубли») — обвязка. Вопрос «нужен ли вам свой кошелёк» сводится к тому, готовы ли вы брать на себя ответственность за эти ключи и инфраструктуру вокруг них.

По нашему опыту, есть три сценария, когда разработка криптокошелька с нуля действительно оправдана:

• Централизованная биржа, брокер или обменник. Если бизнес-модель в хранении клиентских активов, кошелёк и есть продукт. Холодное хранилище, горячие кошельки для выводов, балансировка, мониторинг.
• Кастодиан для институциональных клиентов. Банки, фонды, корпоративные казначейства. Здесь важны не столько фичи, сколько лицензии, мультиподпись, разделение ролей, аудит-trail, интеграция с риск-системами.
• Нативный кошелёк внутри собственного блокчейн-продукта. L2-сеть, DeFi-протокол, GameFi-проект. Если у вас уже есть пользовательская база и собственная экономика, отдавать UX и брендинг внешнему MetaMask значит терять контроль над ключевой частью опыта.

И три сценария, когда разработка с нуля — это сжигание денег:

• Достаточно WalletConnect. Если задача в том, чтобы позволить пользователю подключить свой существующий кошелёк к вашему dApp, WalletConnect решает её за пару дней работы фронтенд-разработчика. Не нужны ни ключи, ни лицензии, ни поддержка.
• Достаточно SDK (Web3Auth, Privy, Magic). Если вы делаете Web3-приложение для широкой аудитории и хотите вход через email или соцсети, встраиваемые SDK с MPC-кошельком под капотом покрывают 80% сценариев. Стоит несколько тысяч долларов в месяц по подписке, разворачивается за недели.
• Достаточно white-label кошелька (Fireblocks, BitGo, ZenGo SDK). Когда нужен полноценный кастодиальный продукт, но вы не готовы строить хранилище ключей сами. Берёте готовое ядро, прикручиваете свой бренд и интерфейс. Дороже SDK, дешевле собственной разработки, и часть регуляторных вопросов закрыта за вас.

Разница задач между сегментами тоже принципиальна. Банк в первую очередь решает вопрос комплаенса: KYC, AML, отчётность регулятору, разграничение прав. Финтех-стартап бьётся за UX: как сделать так, чтобы человек, не знающий слова «seed-фраза», смог купить токен в три тапа. Web3-проект упирается в мультичейн и поддержку новых сетей: каждая интеграция это отдельный SDK, отдельные edge-кейсы, отдельные риски.

Когда хватит SDK и WalletConnect

Простой тест: если вашей команде кошелёк нужен как способ авторизации или подписания, а хранение активов — задача пользователя, начинайте с SDK или WalletConnect. Мы видели проекты, которые потратили полгода на собственный кошелёк ради того, что закрывается одной библиотекой за три недели.

Когда нужен white-label кошелёк

Если вы кастодиан или биржа в зрелой юрисдикции и вам важна скорость выхода на рынок, white-label сокращает time-to-market на 6–12 месяцев. Платите подписку и комиссию с оборота, получаете готовую инфраструктуру MPC и compliance-обвязку. Минус: зависимость от вендора и его ценовой политики на горизонте 3–5 лет.

Когда оправдана разработка с нуля

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

После того как ответили «да, нам нужен свой», начинается выбор архитектуры. От него зависит примерно всё: бюджет, сроки, состав команды, требования к лицензированию.

Кастодиальный кошелёк или некастодиальный. В кастодиальной модели ключи хранит провайдер (вы), пользователь работает через логин-пароль и доверяет вам средства. Это удобный UX и тяжёлая регуляторика. В некастодиальном кошельке ключи у пользователя, вы только даёте интерфейс. UX сложнее (seed-фразы, восстановление), регуляторика мягче, но не нулевая: в ЕС MiCA, например, многие функции некастодиалов всё равно подпадают под VASP-режим.

Hot или cold. Горячий кошелёк подключён к интернету и нужен для активных операций. Холодный изолирован, для долгосрочного хранения. Кастодианы обычно делают и то, и другое: 95% средств в cold storage, 5% в hot для ежедневных выводов. Это требует отдельной инфраструктуры мониторинга и автоматического ребаланса.

Управление ключами. Здесь основной выбор и основная стоимость:

• Seed-фраза (BIP-39). Классика, 12–24 слова. Просто, проверено, дёшево в разработке. Но это худший UX в финтехе вообще: пользователи теряют seed, фотографируют его, отправляют в облако. Любой инцидент — потеря средств без шансов на восстановление.
• MPC-кошелёк (Multi-Party Computation). Приватный ключ не хранится целиком нигде. Он разбит на несколько долей, которые живут на разных устройствах или серверах. Подписание происходит совместными вычислениями, без сборки ключа. Это стандарт де-факто для современных кастодианов: Fireblocks, ZenGo, Coinbase. Дороже в разработке, лучше в безопасности и UX.
• ERC-4337 (Account Abstraction). Кошелёк становится смарт-контрактом. Можно делать соцлогин, восстановление через доверенных лиц, оплату газа в стейблкоинах, спонсорство транзакций. Главная боль: работает только на EVM-совместимых сетях, инфраструктура (bundlers, paymasters) ещё дозревает. Спецификация: eips.ethereum.org/EIPS/eip-4337.
• HSM (Hardware Security Module). Аппаратные модули, в которых живут ключи. Стандарт для банков и крупных кастодианов. AWS CloudHSM, Fortanix, Thales. Дорого в эксплуатации, обязательно при работе с регуляторами.

Single-chain или мультичейн кошелёк. Поддержка одной сети — это одна интеграция, один набор форматов адресов, один способ построения транзакций. Каждая дополнительная сеть (Bitcoin, Solana, Cardano, Tron) — отдельный модуль с собственной криптографией, нюансами комиссий и rpc-нодами. Мультичейн с нуля — это не «добавить ещё одну монету», это новая подсистема.

Платформа. Mobile (iOS/Android), Web, browser extension, desktop. Mobile-only в 2026 году: реалистичный выбор для розничного продукта. Кастодианам и B2B чаще нужен web-кабинет плюс API, мобайл идёт как дополнение.

Кастодиальный кошелёк и некастодиальный: что меняется юридически

Решение не только техническое. Кастодиальный режим означает, что вы юридически держатель чужих активов: лицензия VASP, требования по капиталу, страхование, отчётность. В РФ статус крипто-сервисов всё ещё подвижный, в ЕС с 2024 года действует MiCA, в США каждый штат принимает решение сам. Закладывайте на юридическую обвязку столько же времени, сколько на разработку.

MPC-кошелёк и Account Abstraction

MPC — это «бронежилет» для ключей. Технология зрелая, есть open-source библиотеки (например, от Coinbase и Binance), есть коммерческие реализации. Самостоятельная разработка MPC-протокола — плохая идея почти всегда. Используйте проверенные библиотеки и/или сервисы, иначе попадёте в категорию «самостоятельная реализация криптографии» (подробнее в разделе про ошибки).

ERC-4337 — это про UX. Если ваш продукт ориентирован на пользователей без опыта в крипте, account abstraction убирает большую часть барьеров. Но это привязка к EVM и риск ранней технологии: спецификация ещё обновляется, инфраструктура bundlers/paymasters развивается.

Мультичейн кошелёк: цена универсальности

Самая частая иллюзия: «давайте сразу 10 сетей, чтобы быть конкурентоспособными». На практике каждая сеть после первых трёх-четырёх даёт убывающую отдачу и растущие затраты на поддержку. Bitcoin требует UTXO-логики и работы с PSBT, у Solana своя подпись и rent-механика, у Cardano eUTXO и Haskell-окружение. По нашему опыту, оптимально стартовать с 2–3 ключевых сетей под целевую аудиторию и добавлять остальные по запросу.

Любой проект, который мы вели, шёл примерно по одной канве. Меняются длительности этапов и состав работ, но логика одна.

1. Discovery и архитектурный аудит. Начинается с того самого вопроса: нужен ли вообще свой кошелёк. Мы на этом этапе нередко отговариваем клиента от полноценной разработки в пользу SDK или white-label. Дальше идёт выбор архитектуры, сетей, модели хранения ключей, регуляторного периметра. На выходе техническое видение и бюджетная оценка с разбивкой по сценариям.
2. Разработка ядра (8–16 недель). Управление ключами, формирование и подпись транзакций, работа с rpc-нодами, кошельковая логика для каждой сети. Параллельно строится бэкенд для кастодиальной части, если она есть: учёт балансов, очереди транзакций, мониторинг.
3. UX/UI дизайн (4–8 недель). Самая недооценённая часть. Хороший дизайн криптокошелька — это не «красивые экраны», это сценарии восстановления, обработка ошибок сети, отображение комиссий, понятные предупреждения о фишинговых dApp. Прототипирование и тесты на реальных пользователях обязательны, особенно для розничных продуктов.
4. Интеграции (4–8 недель). Подключение DEX и CEX для свопов и выводов, fiat on-ramp (MoonPay, Transak, Ramp), KYC-провайдер (Sumsub, Onfido), аналитика блокчейна (Chainalysis, TRM Labs) для AML. Каждая интеграция: отдельный контракт, отдельные SLA, отдельные комиссии.
5. Аудит безопасности (3–6 недель). Внешний пентест, аудит кода, проверка криптографических реализаций. Для смарт-контрактов (если есть) проводится отдельный аудит специализированными командами. Это не та статья расходов, на которой можно экономить: цена ошибки в кошельке считается не в часах разработки, а в украденных средствах и репутации.
6. Запуск и поддержка. Mainnet-запуск обычно идёт волнами: сначала закрытая бета на сотрудниках, потом ограниченный круг пользователей, потом публичный релиз. Поддержка: отдельная история и отдельный бюджет.

В сумме это 3–9 месяцев для среднего проекта и до 6+ месяцев для enterprise-кастодианов с серьёзной регуляторкой. Сокращать сроки можно за счёт white-label-компонентов и работы с готовыми библиотеками MPC, а вот экономить на аудите и discovery нельзя.

Бюджет на разработку криптокошелька состоит на 60–70% из трат на ФОТ/аутсорс, на 20–30% лицензии и сервисы, остальное идёт в юридическую часть и непредвиденные расходы. Соотношение меняется в зависимости от модели, но порядок такой.

Команда и разработка

Типовой состав команды на средний проект:

• Product manager — 1, может быть с вашей стороны (чаще всего так и есть)
• Архитектор / tech lead — 1
• Backend-разработчики — 2–4
• Mobile или web-разработчики — 1–2 на платформу
• UX/UI дизайнер — 1
• QA-инженер — 1–2
• Security engineer — 1 (тут стараемся подключать опытных и проверенных партнеров)
• DevOps — 1 

Лицензии и инфраструктура

Цены и продукты для примера, как самые крупные провайдеры/ресурсы, они могут меняться взависимости от проекта к проекту.

• HSM. AWS CloudHSM от $1.45 в час за инстанс, плюс резервирование. Fortanix, Thales: корпоративные модели с подпиской. На проект это десятки тысяч долларов в год. 
• MPC. Fireblocks. Coinbase Cloud: обычно подписка плюс комиссия с оборота. Точные цифры под NDA, но это значимая часть OpEx.
• RPC-провайдеры. Alchemy, QuickNode, Infura. Бесплатные тарифы для разработки, платные для продакшна: от нескольких сотен до нескольких тысяч долларов в месяц на сеть.
• KYC. Sumsub, Onfido, Veriff: оплата за проверку, в среднем $1–3 за пользователя. На объёме это становится заметной статьёй.
• Fiat on-ramp. MoonPay, Transak, Ramp: комиссию платит пользователь, но интеграция и compliance-документы это ваше время и юристы.

Юридическая часть

VASP-регистрация в выбранной юрисдикции, AML/CFT-программа, политика обработки данных (GDPR в ЕС, аналоги в других регионах), для банков нужны отдельные согласования с регулятором, плюс постоянные расходы на compliance-офицера и аудиты. Для российского рынка ситуация особая и быстро меняется: без локального юриста, который ведёт именно крипто-проекты, не стоит даже стартовать.
Мы не эксперты в лигал-части, поэтому тут мы не можем говорить ни о сроках, ни о цифрах, можем только пригласить наших партнеров для помощи вам.

Поддержка после релиза

Здесь чаще всего недооценивают. По нашим оценкам, ежегодная стоимость поддержки кошелька составляет 15–25% от стоимости разработки. Сюда входит:

• Поддержка и обновления нод, RPC, инфраструктуры
• Реакция на инциденты безопасности и обновления библиотек
• Обновления KYC/AML-логики под меняющиеся требования
• Поддержка пользователей (для розничных продуктов часто отдельная команда)

Скрытые затраты, о которых вспоминают только на проде: газ на тестовые транзакции (для частых релизов это несколько тысяч долларов в месяц), bug bounty (от $10k стартовый пул), страхование (для кастодианов обязательная статья).

Цифры ориентировочные, рассчитаны на международный рынок и не включают маркетинг и листинги.

За годы работы мы видели одни и те же грабли в проектах разных команд. Это шесть наиболее дорогих.

• Экономия на аудите безопасности. «Мы проверим сами» или «возьмём аудит подешевле». В кошельке любой пропущенный баг — это потенциальная потеря средств пользователей и конец продукта. Аудит должен быть от команды с публичной репутацией в крипте, а не от общей кибербез-конторы. Но отметим, дороже не всегда значит лучше! 
• Недооценка стоимости поддержки нод и инфраструктуры. На этапе планирования заложили $500/мес на RPC, через год платят $8000 потому, что вырос трафик и добавили две сети. Считать инфраструктуру нужно на горизонте 2–3 лет, с запасом на рост и резервирование.
• «Всё сразу» в первой версии. Десять сетей, пятьдесят токенов, NFT-галерея, встроенный DEX, стейкинг и кешбэк. В итоге релиз через 18 месяцев вместо шести, бюджет вдвое больше, и продукт всё равно сырой по всем фронтам. Лучше выйти с двумя сетями и идеальным базовым UX, чем со всеми фичами и багами в каждой.
• Игнорирование UX вокруг seed-фразы. Если выбрали seed-модель, продумайте сценарий восстановления, обучение, проверку, что пользователь действительно сохранил фразу. По разным оценкам, значительная часть потерь в самокастоди — это не взломы, а потерянные seed-фразы. 
• Самостоятельная реализация криптографии. Соблазн «написать своё MPC, чтобы не платить вендору» появляется в каждом втором проекте. Это плохая идея почти всегда: криптография — область, где даже опытные команды находят уязвимости после годов ревью. Используйте проверенные библиотеки прошедшие аудит. Будут целее и ваши нервы, и средства ваших клиентов.
• Отсутствие incident response плана. Что вы делаете, когда обнаруживается уязвимость в зависимой библиотеке в три ночи в воскресенье? Кто принимает решение о приостановке выводов? Кто пишет публичное сообщение? У зрелых кастодианов это всё прописано в runbook. У большинства проектов на старте этого нет.

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

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

• Опыт с нужными вам сетями. Если вам нужен Cardano или Solana, наличие реального опыта в команде сократит сроки на месяцы. Универсальные «мы освоим» всегда оборачиваются дольше и дороже, чем кажется.
• Security-инженеры в команде. Не «безопасность важна для нас», а конкретные люди с релевантным бэкграундом. Готовность подрядчика обсуждать threat model на первой встрече — хороший знак. Ну или проверенный партнеры из security, как у нас:)
• Понимание регуляторики. В кошельковом проекте техническая команда должна хотя бы в общих чертах ориентироваться в VASP, MiCA, AML, потому что архитектурные решения зависят от регуляторных требований. Они не обязаны разбираться глубоко, но если в ответ на вопрос про KYC слышите «это юристы скажут»: плохой признак.
• Прозрачность по поддержке и передаче кода. Что будет, когда проект сдан: как поддержка переходит к вашей команде, какие есть SLA, что в репозитории, как организованы секреты. Условия должны быть прописаны в контракте, а не в обещаниях.

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

С чего начать практически: с discovery. Это не «составить ТЗ», а структурированная работа на 2–4 недели, на которой команда вместе с вами проходит ключевые развилки: кастодиал или нет, какие сети, какая модель ключей, какая юрисдикция. На выходе техническое видение, оценка бюджета с разбивкой по сценариям и понятный план следующих шагов.

Чем отличается кастодиальный кошелёк от некастодиального?

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

Что такое MPC-кошелёк?

MPC (Multi-Party Computation) — технология, при которой приватный ключ не существует как единый объект. Он разбит на несколько математических долей, которые хранятся на разных устройствах или серверах. Подпись транзакции происходит через совместные вычисления без сборки ключа в одном месте. Это устраняет единую точку компрометации. Технология используется в Fireblocks, Coinbase и других институциональных решениях.

Нужна ли лицензия для криптокошелька?

Зависит от модели и юрисдикции. Кастодиальный кошелёк почти везде требует регистрации как VASP (поставщик услуг с виртуальными активами). В ЕС с 2024 года действует MiCA — регламент, под который подпадают и многие некастодиальные сервисы. В России ситуация отдельная и быстро меняется. Юридический бюджет на старте легко уходит за $50–100 тыс. только на первичную обвязку.

Что такое ERC-4337 и зачем он нужен?

ERC-4337 — стандарт Ethereum, который позволяет сделать кошелёк смарт-контрактом вместо обычного аккаунта с приватным ключом. Это открывает вход через email или соцсети, восстановление через доверенных лиц, оплату газа в стейблкоинах. Работает только в EVM-совместимых сетях. В мае 2025 года вышел EIP-7702 как дополнение — он позволяет существующим аккаунтам временно получать возможности смарт-кошелька.

Когда достаточно SDK вместо собственного кошелька?

Если вам нужна авторизация пользователей и подписание транзакций без хранения активов на вашей стороне, SDK вроде Web3Auth, Privy или WalletConnect закрывают её за недели, а не месяцы. Стоит несколько тысяч долларов в месяц по подписке против $80–350 тыс. на разработку. Собственный кошелёк оправдан, когда кошелёк — это ваш продукт, а не инструмент.

Сколько времени занимает разработка криптокошелька?

Средний проект — 4–9 месяцев. Enterprise-кастодиан с серьёзной регуляторкой: до 12 месяцев и выше. Из них 2–4 недели занимает discovery, 3–6 недель на проектирование безопасности, 8–16 недель на разработку ядра. Экономить время за счёт пропуска аудита или discovery — самая дорогостоящая ошибка.

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

Вопрос «сколько стоит криптокошелёк» сводится к трём другим: какая архитектура безопасности, в какой юрисдикции и сколько сетей. Ответьте на них — и оценка превратится из «от $50k до бесконечности» в конкретное число с понятной структурой.

Если хотите пройти этот путь с нами — metalamp.ru/wallet