Гаманець як сервіс, або Wallet as a Service, приваблює команди обіцянкою швидкого запуску: створення гаманців через API, підтримка кількох активів, підписання, події й готові інструменти для продукту. Але для серйозної платформи питання глибше. Ви обираєте не тільки провайдера гаманців. Ви обираєте, хто контролює ключі, хто веде операційний журнал, хто відповідає за збої, як працює звірка і чи витримає модель робочий режим.
BroLabel розглядає Wallet as a Service як частину фінансової інфраструктури. Якщо гаманець має приймати депозити, робити виводи, підтримувати AI-агентів або працювати з iGaming-обсягами, йому потрібні MPC, Co-Signer, події, журнал і правила, а не тільки швидке створення адреси.
Table of Contents
- Проблема, з якою стикається кожен криптооператор
- Що насправді означає Wallet as a Service
- Порівняння кастодіальної, некастодіальної і MPC-архітектур
- Ключові можливості, важливі в робочому режимі
- Шлях інтеграції від пісочниці до робочого режиму
- Де WaaS справді окупається в різних галузях
- Ризики відповідності, зберігання активів і вартості перед запуском
- WaaS проти white-label і власної інфраструктури
Проблема, з якою стикається кожен криптооператор
Перший гаманець легко запустити. Складно запустити сотні тисяч рахунків, тисячі депозитів, автоматичні виводи, кілька мереж і фінансову звірку без ручного хаосу. На цьому етапі команда вже не купує окрему функцію. Вона купує операційну модель.
Чотири питання про власність
Хто контролює підписання? Хто володіє журналом? Хто відповідає за події й звірку? Хто несе ризик, якщо процес зупиниться? Якщо провайдер не дає чітких відповідей на ці питання, швидкий старт може перетворитися на дорогий перезапуск.
Що насправді означає Wallet as a Service
Wallet as a Service - це набір сервісів для створення і керування гаманцями через API. Він може включати адреси, підписання, підтримку мереж, події, інструменти розробника, панель керування і механізми відновлення. Для інституційного покупця головне - не список функцій, а межа контролю.
Що WaaS не вирішує автоматично
WaaS не гарантує правильну модель відповідності, не замінює фінансовий журнал, не усуває потребу в звірці, не визначає ризик-правила і не пояснює, хто несе відповідальність за активи. Це треба проєктувати окремо.
Порівняння кастодіальної, некастодіальної і MPC-архітектур
| Архітектура | Що отримує команда | Що треба перевірити |
|---|---|---|
| Кастодіальна | простий запуск і підтримка | відповідальність за зберігання активів і регулювання |
| Некастодіальна | більше контролю в користувача | відновлення, підтримка і досвід |
| MPC | розділене підписання | правила, Co-Signer, журнал і відновлення |
Операційна різниця проявляється під час збою
У нормальному сценарії всі моделі можуть виглядати схоже. Різниця проявляється, коли мережа затримує транзакцію, користувач просить відновлення, подія повторюється, Co-Signer недоступний або команда з відповідності блокує вивід.
Ключові можливості, важливі в робочому режимі
Вбудовані гаманці і доступ з обмеженими правами
Вбудовані гаманці мають працювати всередині вашого продукту, а не відправляти користувача в чужий досвід. API-ключі повинні мати обмежені права. Один сервіс може створювати адреси, інший - читати події, третій - створювати наміри виводу. Підписання має проходити через правила.
Журнал, події і звірка
Журнал показує внутрішні зобовʼязання. Події показують стан мережі. Звірка доводить, що ці два світи збігаються. Без цього Wallet as a Service залишається технічною інтеграцією, а не фінансовою інфраструктурою.
Шлях інтеграції від пісочниці до робочого режиму
Почніть з ідентичності й авторизації
Визначте користувача, рахунок, роль, сервіс і право дії. Не підключайте реальні активи, поки не зрозуміло, хто може створювати гаманець, хто може ініціювати вивід і хто може змінювати правила.
Визначте правила до підключення реальних активів
Правила мають включати ліміти сум, ліміти швидкості операцій, список дозволених адрес, ручні винятки, AML-сигнали, мережі й активи. Це особливо важливо для продуктів, де AI-агенти можуть діяти автономно.
Відрепетируйте неприємні сценарії
Перед запуском перевірте повторний депозит, неправильну мережу, відхилене схвалення, недоступний Co-Signer, помилку підписання, розбіжність звірки і ручне блокування виводу.
Де WaaS справді окупається в різних галузях
WaaS корисний там, де гаманець є частиною продукту, а не побічною функцією. Біржі, iGaming, платіжні провайдери, необанки, казначейства і платформи AI-агентів мають різні вимоги, але однакову потребу: контрольований рух активів.
Операційна придатність залежить від обіцянки продукту
Якщо продукт обіцяє миттєві депозити, потрібні події й підтвердження. Якщо обіцяє швидкі виплати, потрібні правила схвалення. Якщо обіцяє самостійність користувача, потрібна зрозуміла модель ключів. Якщо обіцяє роботу AI-агентів, потрібні наміри й ліміти.
Ризики відповідності, зберігання активів і вартості перед запуском
Відповідність залежить від функції
Створення гаманця, приймання депозитів, виводи, перекази між користувачами і казначейські переміщення мають різні вимоги. Команда повинна знати, які перевірки виконує вона, які виконує провайдер і які потребують окремого партнера.
Зберігання активів і вартість потребують письмових відповідей
До контракту варто зафіксувати, хто контролює ключі, як працює відновлення, які комісії діють, як рахуються мережеві витрати, як експортуються докази і що станеться під час інциденту.
WaaS проти white-label і власної інфраструктури
White-label рішення може швидше дати готовий інтерфейс, але обмежити контроль. Власна інфраструктура дає гнучкість, але потребує більше часу й ризику. WaaS між ними: швидший запуск із глибшим технічним контролем, якщо він має журнал, події, MPC і правила. BroLabel будує цей підхід через BroSettlement і BroWallet.