Розробка криптогаманця для компанії - це не тільки екран балансу й кнопка відправлення. Справжня складність починається там, де продукт має створювати рахунки, керувати активами в різних мережах, підписувати транзакції, виконувати правила, вести операційний журнал, звіряти події і давати фінансовій команді доказову базу.
Для стартапу гаманець може виглядати як набір API-викликів. Для регульованого оператора це інфраструктурне рішення про зберігання активів, відповідальність, відновлення, права доступу, робочий режим і вартість підтримки. Саме тут BroLabel розділяє інтерфейс гаманця і нижній фінансовий шар: BroWallet може бути продуктом для користувача, а BroSettlement - інфраструктурою MPC-гаманців, журналу і розрахунків під ним.
Table of Contents
- Чому проєкти гаманців зупиняються до запуску
- Як обрати правильну архітектуру гаманця
- DKG, порогове підписання і модель Co-Signer
- Керування ключами, API-авторизація і операційні обмежувачі
- Як будувати операційний журнал і шар звірки
- Картки, фіат і гаманці AI-агентів на одному шарі
- Ризики, контролі і що перевірити перед запуском
Чому проєкти гаманців зупиняються до запуску
Команди часто починають із найвидимішого: створити адресу, показати баланс, дозволити відправити актив. Це швидко дає прототип, але не дає операційну систему. Після перших реальних користувачів виникають питання: як обробляти повторні події, хто має право підписувати виводи, що робити з помилкою мережі, як закривати звірку, як зупинити підозрілий рух і як відновити контроль у разі інциденту.
Гаманець для бізнесу має працювати в контексті. Біржі потрібні депозити й виводи. iGaming-платформі потрібні швидкі зарахування і контроль виплат. Необанку потрібна інтеграція з картками і фіатним вводом/виводом. Платформі AI-агентів потрібні ліміти, наміри і контрольована автономія.
Як обрати правильну архітектуру гаманця
Є кілька моделей. Кастодіальна модель дає простіший користувацький досвід, але провайдер або оператор бере більше відповідальності за активи. Некастодіальна модель дає користувачу більше контролю, але ускладнює відновлення, підтримку і відповідність вимогам. MPC-модель дозволяє розділити підписання між сторонами й уникнути одного приватного ключа, який може стати точкою відмови.
| Модель | Перевага | Основний ризик |
|---|---|---|
| Кастодіальна | простіший досвід і відновлення | більше відповідальності за зберігання активів |
| Некастодіальна | більше контролю в користувача | складніше відновлення і підтримка |
| MPC з Co-Signer | розділене підписання і програмні правила | потрібно правильно побудувати операційний шар |
DKG, порогове підписання і модель Co-Signer
DKG дозволяє створити частки ключа без збирання повного приватного ключа в одному місці. Порогове підписання дає можливість підписати транзакцію, коли потрібна кількість сторін бере участь у процесі. Co-Signer додає клієнтський контроль: підписання відбувається тільки тоді, коли намір відповідає правилам, лімітам і правам.
Ця модель особливо корисна для компаній, які хочуть автоматизувати депозити й виплати, але не хочуть передавати повний контроль над рухом активів зовнішньому провайдеру.
Керування ключами, API-авторизація і операційні обмежувачі
Безпечний гаманець починається не з красивого інтерфейсу, а з меж доступу. API-ключі мають бути з обмеженими правами. Сервіси мають мати тільки ті дії, які їм потрібні. Оператори мають працювати через ролі. AI-агенти мають створювати наміри в межах лімітів, а не отримувати необмежене право підписання.
Операційні обмежувачі включають списки дозволених адрес, ліміти швидкості операцій, максимальні суми, ручні винятки, географічні обмеження, AML-сигнали і зупинку процесу в разі підозрілої поведінки.
Як будувати операційний журнал і шар звірки
Журнал потрібен для того, щоб внутрішній баланс мав пояснення. Блокчейн показує зовнішній рух, але не знає вашого користувача, тарифу, бонусу, резерву, комісії або внутрішнього статусу. Тому кожен депозит, вивід, переказ і корекція мають бути записані як операційна подія.
Зробіть кожен запис ідемпотентним
Повторний запит не повинен створювати повторний фінансовий результат. Це стосується створення адрес, зарахування депозитів, запитів на вивід і записів комісій. Ідемпотентність - одна з найважливіших умов для гаманця в робочому режимі.
Ставтеся до подій як до операційних сигналів
WebSocket-події мають запускати оновлення статусів, повідомлення підтримці, зміни в журналі і винятки для ручної перевірки. Вони не повинні бути лише декоративним сповіщенням.
Звіряйте так, щоб це було корисно фінансам
Фінансова команда має бачити звʼязок між користувачем, рахунком, активом, мережею, хешем і записом журналу. Якщо для звірки потрібен ручний експорт із трьох систем, архітектура ще не готова до масштабування.
Картки, фіат і гаманці AI-агентів на одному шарі
Сильна інфраструктура гаманців може підтримувати кілька продуктів. Вбудований гаманець може приймати стейблкоїни. Картковий продукт може використовувати той самий журнал для резервів і списань. Фіатний ввід/вивід може звірятися з криптопотоками. AI-агент може створювати намір платежу, але проходити ті самі правила, що й будь-який сервіс.
Про агентські сценарії варто окремо прочитати в матеріалі BroLabel AI Agents: як використовувати гаманці агентів безпечно.
Ризики, контролі і що перевірити перед запуском
Перед запуском перевірте відновлення доступу, поведінку Co-Signer, повторні запити, затримки мережі, подвійну подію депозиту, ручне схвалення, блокування адреси, звірку дня, експорт доказів і права API-ключів. Гаманець готовий не тоді, коли працює щасливий сценарій, а тоді, коли команда знає, що станеться під час помилки.