Найчастіше радять вибирати провайдера криптогаманців за кількістю мереж, знайомим брендом або літерами MPC. Ця порада не витримує першої виплати, для якої потрібні визначений схвалювач і файл, придатний для звірки фінансовою командою. Seed-фраза, кастодіальний гарячий гаманець або логотип MPC без відповіді на питання, хто може підписувати, — це зберігання. Це не система, яка створює адреси, застосовує правила, відправляє транзакції та залишає запис.
Оцінюйте провайдера за керуванням відновленням, правилами до підписання й реагуванням на інциденти. Некастодіальна конструкція не скасовує ліцензування, дані контрагента чи обов'язок обслуговувати користувачів, коли мережа затримує або змінює порядок депозиту. Цей короткий список призначений для бірж, необанків, платіжних шлюзів, iGaming-операторів і казначейств. Позначайте кожну клітинку як «пройдено», «прогалина» або «невідомо» й залишайте лише стеки з клієнтським підписантом, правилами до підписання, дедуплікованими подіями та експортованим журналом.
Зміст
- Що має забезпечувати провайдер криптогаманців
- Оціночна таблиця провайдерів для списку 2026 року
- Моделі зберігання та порогове підписання
- Події, операційний журнал і контроль API
- Операційні моделі, що змінюють вибір
- Ризики, які потрібно контролювати до зобов'язань
- Виберіть стек і перенесіть підписання
- Запитання покупців перед запуском
Що має забезпечувати провайдер криптогаманців
Платіжна команда може мати гаманець із USDT і водночас не мати записів для пояснення виплати. Для переказу на $40 000 фінансова команда має знати, хто його схвалив, яку мережу й актив вибрано та якому клієнту належить адреса отримувача. Провайдер, який лише зберігає ключі, залишає ці операційні питання без відповіді.
Провайдер криптогаманців підтримує повний транзакційний процес: створення адреси, перевірки правил, підписання, відправлення в мережу й записи для звірки. Головна перевірка — керування: чи може клієнт визначити, хто схвалює транзакцію, які правила мають пройти до підписання та як відновлюється сервіс за недоступності підписанта або провайдера?
Пов'язуйте особу, адресу, актив, мережу, рішення за правилами й остаточний розрахунок в одному записі транзакції. Якщо ці дані розділені, реорганізація блокчейну, переказ не того токена або кадрова зміна ускладнять відстеження балансу.
Чому провайдер не може замінити вашу ліцензію
Настанови FATF щодо віртуальних активів за жовтень 2021 року описують очікування щодо ліцензування або реєстрації провайдерів послуг віртуальних активів і Travel Rule, яка вимагає передавати дані відправника та отримувача для охоплених переказів. На момент публікації багато юрисдикцій ще не ухвалили закони про Travel Rule. API провайдера не визначає, чи є ваш бізнес провайдером послуг, які записи ви маєте зберігати або як ідентифікувати клієнтів. Брокери-дилери мають окремі обов'язки ідентифікації клієнта за настановами щодо FINRA Rule 2090. Ваші рішення щодо ліцензування, відповідності та переказів залишаються вашими.
Практичне правило: вимагайте, щоб рішення за правилами зберігалося поруч із записом і хешем транзакції. Інакше ви не зможете надійно пояснити, чому виплату авторизували.
Оцінюйте процес відновлення провайдера, правила до підписання та шлях реагування на інцидент. Список мереж або позначка MPC не пояснюють, хто відновлює сервіс, хто зупиняє виплату й як фінансова команда відтворює активність після збою.
Оціночна таблиця провайдерів для списку 2026 року
Пройдіть цю таблицю один раз. Позначте пройдено, прогалина або невідомо. Маркетингова назва ніколи не означає «пройдено».
| Критерій | Кастодіальний гаманець | Універсальний MPC API | Стек із клієнтським Co-Signer |
|---|---|---|---|
| Контроль ключів | Ключ зберігає провайдер | Частки часто на вузлах провайдера | MPC 2-з-3; один підписант у клієнта |
| Зрілість API | Портал і звіти за запитом | Лише REST, події продаються окремо | REST, Ed25519, події WebSocket |
| Схвалення виплати | Процес або заявка провайдера | Механізм правил як платне доповнення | Правила клієнта мають пройти до початку підписання |
| Недоступність однієї сторони | Провайдер відновлює сервіс | Може підписувати, якщо має досить часток | Підписання зупиняється до повернення або ротації клієнтського підписанта |
| Мережі в робочому режимі | Часто небагато, пакетно | Просіть активний список, не дорожню карту | BroSettlement документує 10 мереж |
| Події депозитів і виплат | Портал або затримані звіти | Вебхуки різної якості | WebSocket для депозитів, виведень і результатів правил |
| Запис для звірки | Виписка рахунку | Часто доповнення | Експортований клієнтом операційний журнал лише з доповненням |
| Власник відповідності | Провайдер може бути VASP | Зазвичай клієнт | Ліцензування, AML і рішення щодо користувачів у клієнта |
| Фіат і картки | Іноді в комплекті | Зазвичай інший провайдер | Окремі продукти, залежать від юрисдикції та емітента |
| Комерційна придатність на малому обсязі | Часто є мінімуми | Часті корпоративні договори | Умови плану показані під час активації |
| Доступність продукту | Гаманець активний, картки часто в комплекті | Гаманці активні, карток немає | BroCard і гаманці агентів у розробці; перевірте стан при підписанні |
Як оцінювати рядок
Контроль ключів — прогалина, якщо ви не можете назвати машини й людей із ключовим матеріалом. Схвалення виплати — прогалина, якщо процес може почати заявка або типове правило провайдера. Недоступність проходить перевірку лише тоді, коли зрозуміло, чи зупиниться підписання. Мережі невідомі до отримання робочого списку, а не слайда дорожньої карти. Події не проходять, якщо депозит можна зарахувати з непідписаного повідомлення. Записи не проходять, якщо фінансова команда отримує PDF замість експорту. Відповідність — прогалина, якщо договір натякає, що провайдер перебрав ваше AML-рішення. Фіат і картки невідомі без назви емітента й країни. Комерційна придатність — прогалина, якщо мінімум припускає неіснуючий обсяг. Доступність невідома для всього, що ще розробляється.
Кастодіальний біржовий гаманець може швидко запуститися, але зосереджує ризик зупинки й ключа в одного оператора. Універсальний MPC API може залишити дві частки на вузлах провайдера, тому клієнт не зможе заблокувати відправлення. Модульний стек перемагає лише тоді, коли клієнт контролює підписанта й журнал.
Правило короткого списку: залишайте провайдера лише тоді, коли він проходить контроль ключів, правила до підписання, дедуплікацію подій і експорт записів. Решту обговорюйте пізніше.
Моделі зберігання та порогове підписання
Ігноруйте слово MPC, доки не зафіксовано поріг, сторони та припущення про компрометацію. Логотип не є контролем.
| Конструкція | Потрібні сторони | Одна частка або ключ | Якщо одна потрібна сторона недоступна | Головний операційний ризик |
|---|---|---|---|---|
| Ключ на одному сервері | 1 | Повний ключ відкритий | Підписання зупиняється | Компрометація одного хоста забирає кошти |
| Ончейн-multisig | M із N повних ключів | Кожний ключ повний | Потрібно досить онлайн-ключів | Видимий, залежний від мережі та складний у відновленні |
| 2-з-3 у провайдера | 2 з 3 | Одна частка не є ключем | Провайдер може й далі підписувати | Провайдер може бути фактичним зберігачем |
| Клієнтський Co-Signer 2-з-3 | 2, включно з клієнтом | Одна частка не є ключем | Підписання зупиняється | Клієнт має обслуговувати й відновлювати підписанта |
| Комітет 3-з-5 | 3 з 5 | Одна частка не є ключем | Дві сторони можуть бути офлайн | Повільніші схвалення й складніші інциденти |
Презентація NIST про порогові схеми конкретно описує випадок 2-з-3. Два вузли мають співпрацювати для підпису, а одна частка не є повним секретом. Твердження порожнє без розміщення сторін, DKG, оновлення часток і письмового правила для недоступного підписанта.
Що насправді змінює клієнтський підписант
BroSettlement — API-інфраструктура гаманців із DKG, MPC-підписанням, відправленням у мережі й Co-Signer під контролем клієнта у 10 мережах. Виведення потребує цього незалежного шляху, тому один скомпрометований сервер або облікові дані оператора не завершать відправлення самостійно. Контроль працює лише за правил до початку підписання й автентифікації та аудиту кожного підписанта. Ставте питання про розміщення так само, як під час аналізу зберігання цифрових активів: хто утримує кожну частку і хто може її ротувати.
Клієнтський підписант зменшує одноосібний контроль провайдера. Водночас персонал, особи й реагування на інциденти стають вашою відповідальністю.
Відновлення — це операційний процес, а не прапорець резервної копії. Визначте, хто його починає, чи можна ротувати підписанта без перебудови всіх гаманців, відокремте аварійні виведення від звичайних виплат, задайте тривалість замороження й подію-доказ. Комітет 3-з-5 сповільнює погане відправлення, але й недільний інцидент. Вибирайте відмову, яку можете обслуговувати.
Події, операційний журнал і контроль API
Зелений стан WebSocket не є зарахуванням. Вважайте deposit.observed, deposit.confirmed, оновлення виведень і результати правил недовіреними даними, доки сервіс їх не перевірить.
Перевіряйте зовнішні події шістьма кроками: особа відправника й цілісність тіла, актуальність часу, захист від повтору, схема та бізнес-правила. Застосовуйте їх послідовно.
- Перевірте відправника. Відхиляйте тіла, що не проходять Ed25519 або підпис події.
- Перевірте актуальність і форму. Відхиляйте застарілі часові мітки, невалідні схеми й події для іншої мережі чи активу.
- Дедуплікуйте за ID події. Повторна доставка депозиту не має створювати друге зарахування.
- Застосуйте правила підтвердження. Спостережений депозит не є підтвердженим. Мережі й провайдери можуть затримувати, змінювати порядок, відхиляти чи змінювати стан.
- Застосуйте правила до підписання. Невдала перевірка не має створювати підпис.
- Запишіть операцію в журнал. Фіксуйте результат лише після потрібних перевірок.
Що має містити журнал
Операційний журнал має зберігати бізнес-історію, а не лише хеші. Записуйте гаманець або клієнта, актив, мережу, суму, час, результати перевірок, рішення правил, схвалення підписання й результати відправлення. Журнал лише з доповненням і потік подій підтримують звірку й процес аудиту.
BroLabel надає операційний журнал гаманців і транзакцій, REST API, Ed25519 та події WebSocket. Ваша команда все одно визначає правила підтвердження депозитів, звірки балансів і реагування на інциденти.
Використовуйте ключі ідемпотентності для запитів створення й виплат, щоб повтори не дублювали дії. Обмежуйте облікові дані, щоб слухач депозитів не міг авторизувати виведення. Додавайте метадані комісій і чіткі стани, сповіщайте про завислі запити й мовчазні потоки подій. Застосовуйте ту саму дисципліну, що й для моніторингу стану систем у DevOps.
До запуску двічі доставте одну подію депозиту й переконайтеся, що вона створює одне зарахування. Надішліть невдалий результат правил і перевірте, що запит підписання не продовжився.
Операційні моделі, що змінюють вибір
Не переоцінюйте всього провайдера для кожного продукту. Кожна модель має один головний збій і один критичний рядок.
| Операційна модель | Небезпечний збій | Вирішальний контроль | Критичний рядок |
|---|---|---|---|
| Біржа або платіжний шлюз | Зависла чи недооцінена транзакція створює дубльовані заявки й ризик виплати | Оцінка комісії з цільовим вікном і стани життєвого циклу | Події депозитів і виплат |
| Необанк або фінтех | Вбудовані гаманці випереджають модель користувача; фіатний ввід/вивід зупиняється | Модель користувача в продукті й контроль гаманця в провайдера | Фіат і картки |
| iGaming-оператор | Виплату підписано без правил; баланс гравця не збігається | Правила оператора до підписання й журнал на гравця | Схвалення виплати |
| AI-агенти | Агент підписує без контролю та аудиторського сліду | Некастодіальний контроль на агента й журнал після загальної доступності | Доступність продукту |
Емпіричне дослідження 45 821 відгуку про п'ять провідних мобільних криптогаманців виявило 6 859 відгуків щодо гаманців: перекази зависали через надто низькі комісії, а високі комісії спричиняли переплату. Шлюз має вимагати оцінку комісії для цільового вікна підтвердження та стани submitted, pending, confirmed і failed. Затримані події створюють другу заявку підтримки, а казначейство може заплатити двічі. Критичний рядок — події депозитів і виплат.
Необанк, який створює гаманець до запису користувача, не знатиме, кого відключати. Зберігайте модель користувача у своєму продукті. Фіатний ввід/вивід залежить від провайдера й юрисдикції, тому фіат і картки можуть зупинити запуск.
Дві моделі, які легко перебільшити
Для iGaming робоча модель — гаманець TRON USDT і окрема адреса TRC20 на гравця, події deposit.observed і deposit.confirmed, правила оператора до підписання виплати й журнал балансів лише з доповненням. Це не кастодіальний платіжний провайдер. Критичний рядок — схвалення виплати. Та сама звичка потрібна в керуванні криптоказначейством, коли отримувачем є казначейство, а не гравець.
Гаманці агентів із MPC-контролем та абстракцією газу перебувають у розробці. Проєктуйте контроль і аудиторський слід для кожного агента вже зараз, але не вважайте їх загальнодоступними. Доступність продукту блокує дату запуску.
Ризики, які потрібно контролювати до зобов'язань
Кількість мереж і позначка MPC мало говорять про компрометовані облікові дані, спірну транзакцію чи збій залежності. Оцінюйте керування відновленням, контроль до підписання й докази після інциденту. Chainalysis повідомила, що до кінця червня 2025 року з криптосервісів викрали понад $2,17 млрд, більше за весь 2024 рік; 23,35% активності викрадених коштів припало на компрометації особистих гаманців. Запитуйте, як провайдер виявляє збої й реагує, а не чи обіцяє нуль інцидентів.
| Залишковий ризик | Контроль | Потрібний доказ |
|---|---|---|
| Неправильна адреса, актив або сума | Перевірки клієнта до інструкції | Визнання незворотності блокчейн-транзакцій |
| Скомпрометовані дані оператора | Правила до підписання | Логи відхилених неавторизованих запитів |
| Дубльований депозит або повтор | Збережені ID подій та ідемпотентні записи | Тест повтору без другого зарахування |
| Реорганізація або втрачена транзакція | Правила observed і confirmed | Письмові правила підтвердження для активу |
| Провайдера вважають емітентом | Договірні межі балансів і консультацій | Умови, що залишають рішення клієнту |
| Відсутній файл Travel Rule | Дані понад хеш транзакції | Експорт особи, перевірок, правил і схвалень |
Ваша команда відповідає за адреси, мережі, активи, суми, дані отримувачів, інструкції та власні рішення щодо відповідності й ризиків. Транзакції можуть бути незворотними. Технічна інфраструктура не робить провайдера емітентом, юридичним радником або відповідальним за баланси користувачів чи регуляторні рішення.
Публічні блокчейни, валідатори, емітенти токенів і незалежні провайдери можуть збоїти, затримувати, відхиляти чи змінювати порядок транзакцій і змінювати або скасовувати видимий стан. Встановіть власні правила підтвердження, звірки й обслуговування.
Вимагайте чітке керування відновленням, правила до підписання й журнал для звірки та аудиту. Визначте, хто призупиняє підписання, хто відповідає за інцидент і які записи доступні під час збою. Застосуйте основи моніторингу сайтів до залежностей гаманця. Не погоджуйте провайдера лише за слайдами: вимагайте докази кожного контролю.
Виберіть стек і перенесіть підписання
Провайдер заслуговує місця завдяки зрозумілому контролю підписання та записам для звірки, а не довгому списку функцій. Вибирайте модульний стек під контролем клієнта, якщо команда рання або масштабується, обсяг невідомий, а вам потрібні гаманці, відправлення транзакцій, події та журнали без кількох провайдерів. BroSettlement надає орієнтоване на API MPC-зберігання та вбудовані гаманці. Інженери BroLabel допомагають спроєктувати гаманці, записи, правила підписання й події.
До зобов'язань зафіксуйте комерційні умови. Передплата, включене використання, ліміти й перевищення відповідають показаним під час активації, якщо підписана форма замовлення не передбачає іншого. BroLabel може змінювати ціни для майбутніх періодів, але не заднім числом. Інтеграції для фіатного вводу/виводу залежать від провайдера й юрисдикції. BroWallet і BroCard — окремі продукти, а не функції BroSettlement.
Переносьте підписання в такому порядку:
- Інвентаризуйте адреси, активи й нинішніх підписантів.
- Визначте правила виплат і підтвердження для кожної мережі.
- Налаштуйте Co-Signer під контролем клієнта й призначте операторів.
- Повторіть депозити в пісочниці, включно з дублікатами, і звірте з журналом.
- Перенесіть обмежений робочий потік до відмови від старих ключів.
- Експортуйте доступні записи й зберігайте потрібні бізнесу копії.
Не мігруйте, доки контроль ключів, правила підписання або відновлення незрозумілі. Визначте BroSettlement як інфраструктуру й погоджуйте перехід лише після готовності підписання та звірки.
Запитання покупців перед запуском
Чи скасовує некастодіальна інфраструктура ліцензування або Travel Rule? Ні. Ви й надалі приймаєте рішення щодо відповідності й ризиків і встановлюєте правила для затриманих чи переставлених депозитів. API не стає вашою ліцензією.
Чи входять BroWallet і BroCard до BroSettlement? Ні. Це окремі продукти. Згадка на сайті не надає доступу, а майбутні функції не включаються до BroSettlement. Після доступності діятимуть окремі умови. BroCard залишається в розробці й залежить від емітента, партнерів і ринку, включно з планованим шляхом Mastercard та Apple Pay або Google Pay.
Що має зберігати клієнт? Можна експортувати доступну інформацію про рахунки й транзакції через застосунок або документований API. Ви маєте створювати й зберігати копії для обліку, відповідності та безперервності. Наша копія не є вашими книгами.
Що має охоплювати замороження відновлення понад звичайні виплати? Окремого ініціатора, обмеження часу, незалежне схвалення й аудиторську подію. Перевірте шлях до запуску. Якщо немає власника підписанта, правил підтвердження чи експорту, поверніться до послідовності міграції, а не відкривайте новий список провайдерів.
BroLabel надає API-first командам вбудовані MPC-гаманці, Co-Signer під контролем клієнта, відправлення в підтримувані мережі, події WebSocket й операційний журнал для звірки. Якщо вибираєте провайдера для виплат, депозитів гравців або казначейства, почніть із правил до підписання та власного експорту. Зверніться до BroLabel, щоб зіставити BroSettlement із вашими підписантами, правилами підтвердження й обсягом.
