«Зберігайте власні ключі» — неповна порада для продуктової команди. Вона пояснює, хто контролює активи, але не визначає, хто може авторизувати виплату, відновити доступ після інциденту або пояснити фінансовій команді розбіжність у балансі.
Некастодіальний програмний гаманець залишає авторизацію транзакцій користувачеві чи клієнтові, а не централізованому зберігачу активів. В інституційному впровадженні ця обіцянка виконується лише тоді, коли політика підписання, механізм відновлення й операційний журнал зберігають такий контроль у робочому режимі, зокрема в разі відмови пристрою, завершення часу очікування запиту чи помилки оператора.
Зміст
- Єдиний секрет, який вирішує долю кожної транзакції
- Порівняння моделей гаманців за контролем підписання
- Як частки ключа й стани журналу розподіляють контроль
- Як інтегрувати виклики гаманця без дублювання транзакцій
- Яка модель гаманця підходить вашому типу продукту
- Засоби контролю ризиків до запуску
- Запитання покупців про некастодіальні гаманці
- Підтвердьте модель гаманця до запуску
Єдиний секрет, який вирішує долю кожної транзакції
Один секрет підписання може авторизувати кожну транзакцію з гаманця. Якщо для підписання достатньо володіти цим секретом, викрадений приватний ключ або витік seed-фрази можуть відкрити доступ до відповідного балансу. Скомпрометований користувацький інтерфейс також може обманом змусити законного власника схвалити шкідливу транзакцію без викрадення ключа.
Некастодіальна модель змінює того, хто несе цей ризик. Вона зменшує залежність від посередника, але пристрій користувача, інтерфейс застосунку й рішення про підписання все одно потребують захисту.
Масштаб потребує уваги. Звіт TRM Labs про криптозлочинність за 2026 рік повідомляє, що атаки на приватні ключі, seed-фрази, привілейований доступ, інфраструктуру гаманців і користувацькі інтерфейси спричинили втрати на 2,2 млрд доларів США у 45 інцидентах, що становить 76% повідомлених втрат від викрадення криптоактивів.
Очікування щодо відновлення є частиною проблеми
Користувачі можуть розуміти право власності, але неправильно сприймати відновлення. Дослідження відновлення гаманців 2026 року, засноване на 22 інтерв'ю та подальшому опитуванні 430 людей, виявило, що значна частка учасників помилково вважала: втрачену секретну фразу відновлення все ще можна повернути.
Таке переконання може змусити користувачів очікувати, що постачальник відновить доступ після відмови. У некастодіальній моделі постачальник може не мати для цього повноважень або матеріалів.
Практична відмінність: право власності визначає, хто має повноваження. Політика підписання, модель відновлення й операційний журнал визначають, як ці повноваження застосовуються, відновлюються й обліковуються. Якщо конфігурація покладається на Co-Signer або матеріали відновлення під контролем клієнта, клієнт відповідає за їхній захист та експлуатацію.
Гаманець може виконати чинний підпис і все одно спричинити катастрофічний бізнес-результат. Некастодіальна модель передає контроль і відповідальність; вона не усуває потреби визначити, як схвалюються транзакції, відновлюється доступ і звіряються баланси.
Порівняння моделей гаманців за контролем підписання
| Модель | Повноваження підписання | Шлях відновлення | Основний сценарій відмови | Типове застосування |
|---|---|---|---|---|
| Кастодіальний рахунок | Постачальник зберігає ключі | Підтримка й скидання облікового запису силами постачальника | Відмова постачальника, замороження рахунку або неплатоспроможність | Роздрібні застосунки, де пріоритетом є відновлення через підтримку |
| Програмний гаманець з одним ключем | Користувач володіє однією seed-фразою або приватним ключем | Лише seed-фраза користувача в цій моделі | Втрата чи витік seed-фрази, схвалення через фішинг | Окремі користувачі, які керують невеликими балансами |
| Апаратний гаманець | Користувач зберігає ключ на пристрої | Резервна seed-фраза зберігається офлайн | Втрата пристрою без резервної копії, небезпечне підписання на скомпрометованому комп'ютері | Окремі власники й холодне зберігання |
| Смартрахунок (ERC-4337) | Логіка контракту застосовує політики підписувачів і витрат | Підписувачі відновлення визначені в контракті | Помилки контракту, зловживання повноваженнями оновлення, слабке управління відновленням | Команди, яким потрібні ліміти витрат у блокчейні |
| MPC 2-of-3 із клієнтським Co-Signer | Три сторони мають частки; дві повинні співпрацювати | Уцілілі частки й налаштований шлях відновлення через Co-Signer під контролем клієнта | Помилка конфігурації політики, компрометація Co-Signer, нечіткі правила схвалення | Продуктові команди, казначейства, програми вбудованих гаманців |
Читайте таблицю як карту повноважень, а не рейтинг безпеки. Апаратний пристрій змінює місце підписання, але не встановлює автоматично правила бізнес-схвалення. Смартрахунок може застосовувати правила в блокчейні, однак його дозволи відновлення й оновлення можуть створити додаткові повноваження.
Для ширшого організаційного контексту матеріал Arch Web3 для керівників цифрових напрямів стане корисним доповненням, коли продуктовим і фінансовим сторонам потрібен спільний словник до перевірки технічної моделі зберігання активів.
Оцініть розгорнуту конфігурацію
BroSettlement надає MPC-зберігання активів і вбудовані гаманці. Модель зберігання активів і відповідальність кожної сторони залежать від конфігурації сервісу й договірних умов, а не лише від назви продукту.
Зробіть перевірку повноважень конкретною:
- Звичайна робота: визначте всіх, чия співпраця може створити чинну транзакцію.
- Відновлення: визначте, хто може замінити підписувача або відновити доступ.
- Винятковий доступ: перевірте адміністративні дозволи, права оновлення й аварійні дозволи.
- Вихід: установіть, що відбудеться, якщо учасник або сервіс стане недоступним.
Дані про вподобання не відповідають на ці запитання. CoinLaw оцінює, що у 2025 році приблизно 59% користувачів криптогаманців у світі віддавали перевагу некастодіальним гаманцям, а 41% — кастодіальним; це вподобання, а не доказ того, що конкретне впровадження зберігає контроль клієнта.
Вирішальна перевірка проста: якщо інша сторона може перемістити кошти без схвалення клієнта, зокрема через обхідний шлях відновлення чи адміністрування, модель є кастодіальною незалежно від маркетингових заяв.
Як частки ключа й стани журналу розподіляють контроль
Почніть із життєвого циклу ключа: створення, зберігання, резервного копіювання, використання, відновлення й знищення. Активи залишаються в блокчейні, але контроль матеріалу авторизації визначає, хто може їх переміщувати.
Рекомендації NIST з керування ключами пояснюють, чому сильна криптографія не може компенсувати слабке керування ключами. Наприклад, шифрування файлу гаманця допомагає захищати збережений матеріал, але не захищає розшифрований ключ, який шкідлива програма читає з пам'яті застосунку.
Розподіляйте підписання, не втрачаючи підзвітності
Рекомендації NIST із порогової криптографії описують розподіл секрету приватного ключа між учасниками та розподілене виконання операцій; у схемі 2-of-3 два учасники мають співпрацювати, а недоступність одного учасника допускається. Під час звичайного підписання жодному учасникові не потрібно відновлювати повний ключ.
Уявімо, що сервіс підписання клієнта стає недоступним під час технічних робіт. Правильно налаштований кворум уцілілих учасників може зберегти безперервність, але лише якщо його співпраця дозволена політикою схвалення клієнта. Доступність не дає дозволу обходити схвалення.
BroSettlement поєднує розподілену генерацію ключів, MPC-підписання, надсилання в 10 мереж і Co-Signer під контролем клієнта. Наш посібник із MPC-гаманців надає додатковий контекст для оцінювання цієї операційної моделі.
Для впроваджень, сумісних з Ethereum, рівень смартрахунку може додати виконувані правила авторизації. Дослідження Ethereum про абстракцію облікових записів описують можливості, зокрема модульну авторизацію й відновлення; рахунок ERC-4337 може реалізувати ліміти витрат, списки дозволених отримувачів і відкладені виведення.
Компроміс явний: авторизація стає виконуваним кодом. Коректність контракту, повноваження оновлення й підписувачі відновлення потребують управління, співмірного з управлінням самими матеріалами підписання.
Записуйте розрахунок окремо від авторизації
Підписана транзакція ще не є завершеним платежем. Записуйте активність у блокчейні у станах спостерігається, очікує, підтверджено або відхилено, використовуючи записи лише з додаванням замість перезаписування балансу без історії.
Наприклад, виявлений депозит може з'явитися в операційному поданні, але залишатися недоступним для виведення. Документація Bitcoin з опрацювання платежів рекомендує щонайменше шість підтверджень для платежів великої вартості або чутливих до шахрайства; це умовність політики, а не універсальна гарантія.
Установлюйте правила надання доступу до коштів за мережею, активом, вартістю й ризиком. Не застосовуйте правило підтверджень Bitcoin без розбору до інших мереж.
Наш операційний журнал записує гаманці й транзакції для звірки та аудиту. Він підтримує докази авторизації й розрахунку, але сам не створює повноважень підписання в блокчейні.
Поріг визначає, хто має співпрацювати. Процес відновлення й аудиторський слід визначають, чи залишається ця співпраця підзвітною.
Як інтегрувати виклики гаманця без дублювання транзакцій
Завершення часу очікування означає, що викликач не знає результату. Воно не означає, що виплата не відбулася, а створення іншого виведення може перетворити інцидент доступності на фінансову втрату.
Наш інтерфейс інтеграції надає REST API, автентифікацію Ed25519 і події WebSocket. Будуйте шлях команди та шлях звірки разом, із довговічними записами між ними.
Побудуйте безпечний для повторів шлях команди
Видайте API-ключ з обмеженими правами. Надайте кожному сервісу лише потрібні дії й обмежте доступ списком дозволених IP-адрес. Це зменшує можливості скомпрометованого виконавця або викрадених облікових даних.
Автентифікуйте кожен запит. Використовуйте автентифікацію Ed25519 і застосовуйте захист від повторного відтворення, пов'язуючи автентифікацію з виконуваним запитом. Самого чинного підпису не повинно бути достатньо, щоб перехоплений запит виконувався знову й знову.
Зберігайте ідемпотентність до виконання. Збережіть ключ разом із бізнес-командою, сумою, адресою призначення й статусом до надсилання виведення. Документація Stripe з ідемпотентності рекомендує ключі з високою ентропією, як-от UUID версії 4, та зберігає результати щонайменше 24 години. Це показує, чому повторні спроби мають використовувати той самий ключ і параметри в межах задокументованого строку зберігання конкретного постачальника.
Запишіть початкове спостереження депозиту. Створіть запис операційного журналу у стані спостереження й збережіть його ідентифікатор у блокчейні до подальших дій. Це не дасть сповіщенню перетворитися на коригування балансу без простежуваності.
Надійно споживайте події WebSocket. Підпишіться на депозити, підтвердження, виведення й результати політик та усувайте дублікати під час опрацювання подій. Сприймайте доставлення як сповіщення, а не доказ того, що ваша база даних зафіксувала оновлення чи мережа завершила платіж.
Застосуйте налаштований поріг надання доступу. Переводьте запис у стан підтвердженого лише після виконання відповідного правила для активу й вартості. Це не дасть ранньому спостереженню передчасно стати доступним кредитом.
Виконуйте незалежну звірку. За розкладом порівнюйте записи операційного журналу із записами блокчейну й повторно відтворюйте пропущену активність після втрати з'єднання. Документація Bitcoin Core про сповіщення транзакцій ілюструє відстеження транзакцій до досягнення цільової кількості підтверджень замість покладання на одне сповіщення.
Спричиняйте відмови в пісочниці. Перевірте завершення часу очікування після надсилання, дублікати доставлення, оновлення не за порядком і перезапуск виконавців. Ці вправи виявляють дублікати виплат, втрачені події й розходження балансів до залучення реальних коштів.
Тестуйте поведінку, а не лише успішні відповіді
Використовуйте рекомендації AskYourQA щодо тестування контракту API й функціонального тестування, щоб структурувати твердження навколо семантики запитів і поведінки в разі відмови. Успішна відповідь HTTP не є достатнім доказом безпечного опрацювання повторних спроб.
Наш посібник із SDK криптогаманця стане в пригоді під час зіставлення викликів застосунку з цим процесом. Зберігайте стабільний ідентифікатор бізнес-команди між виконавцями, щоб фінансова команда могла простежити виплату без ручного відновлення журналів застосунку.
Яка модель гаманця підходить вашому типу продукту
| Тип продукту | Рекомендована модель | Обов'язкові засоби контролю | Навантаження з відповідності вимогам |
|---|---|---|---|
| Криптобіржа або торгова платформа | MPC-гаманці з Co-Signer під контролем клієнта | Політика підписання, ліміти виведення, звірка | AML-перевірка, аудиторські сліди, рольовий доступ |
| Необанк або фінтех-застосунок | Вбудовані MPC-гаманці для кожного користувача | Рольовий доступ, сповіщення про події в реальному часі | KYC, AML-перевірка, аудиторські сліди |
| Платіжний шлюз або PSP | MPC-гаманці кожного торговця з операційним журналом | Ідемпотентні виплати, перевірка політики до підписання | Записи розрахунків, докази звірки |
| Оператор iGaming, що використовує USDT у TRON | Адреса депозиту TRC20 USDT для кожного гравця | Політика оператора до підписання виплати, події deposit.confirmed | Звірка балансів гравців, застосовні місцеві правила азартних ігор |
| Продукт з AI Agents | Окремі гаманці агентів із MPC-контролем, у розробці | Ключі з обмеженими правами, ліміти витрат, аудиторський слід | Журнали дій агентів, записи схвалення |
| Корпоративне казначейство | MPC-кворум із Co-Signer під контролем клієнта | Кворумне підписання, відкладені виведення | Записи схвалення, докази розподілу ролей |
Це операційні рекомендації, а не визначення правового статусу. Читайте кожен рядок із запитанням: хто має схвалити відтік коштів і хто потім має його пояснити.
Гаманцям гравців потрібна дисципліна від події до балансу
Наш сценарій iGaming підтримує гаманець TRON/USDT і адресу депозиту TRC20 USDT для кожного облікового запису гравця без кастодіального PSP. Застосунок отримує події deposit.observed і deposit.confirmed у реальному часі, а політика оператора виконується до підписання виплати.
Конкретний процес починається із зіставлення вхідного переказу з адресою гравця. Оператор записує спостереження, після підтвердження застосовує своє правило надання кредиту, а потім оцінює пізніше виведення відповідно до політики виплат.
Операційний журнал лише з додаванням пов'язує ці дії з балансами гравців. Це важливо, адже виявлення переказу, зарахування коштів гравцеві й схвалення виплати є окремими бізнес-рішеннями.
Гаманцям агентів потрібні обмежені повноваження
Наші гаманці AI Agents з MPC-контролем і абстракцією газу наразі перебувають у розробці. Запланована модель окремого агента поєднує рольовий доступ та аудиторські сліди замість надання автономному процесу необмеженого доступу до казначейства.
Уявімо агента, що пропонує платіж за придбану послугу. Його застосунок має надіслати обмежений платіжний намір, отримати потрібне схвалення й зберегти дію агента та результат політики разом з отриманою транзакцією.
Для бірж і PSP записи окремих користувачів чи торговців роблять атрибуцію й звірку керованими. Казначейським командам потрібні продумані схвалення, а не зручність споживчого рівня.
Якщо та сама команда може схвалити виплату й незалежно засвідчити її звірку без перевірки, архітектура має прогалину контролю незалежно від типу гаманця.
Засоби контролю ризиків до запуску
Готовність до запуску потребує доказів того, що засоби контролю працюють, а не просто наявності полів конфігурації. Використовуйте перевірку політики підписання й навчальне відновлення як умови випуску.
Вимагайте контролю навколо кожної авторизації
- Моделювання транзакцій: показуйте зрозумілі адреси отримувачів, переміщення активів, виклики контрактів і зміни схвалень до підписання, щоб виявити неочікувані наслідки.
- Списки дозволених адрес: обмежуйте адреси призначення схваленими отримувачами, щоб зменшити підміну й неправильне спрямування.
- Ліміти витрат: застосовуйте періодичні бюджети, щоб чинні облікові дані не могли авторизувати необмежений відтік коштів.
- Відкладені виведення: затримуйте транзакції понад визначений поріг, створюючи час для незалежного втручання.
- Розподіл ролей: розділяйте повноваження пропонувати виплату, схвалювати її та виконувати відновлення, щоб запобігти одноосібному зловживанню.
- Незалежна перевірка політики: попросіть когось поза командою реалізації перевірити дозволи підписувачів і шляхи винятків.
- Стійка до фішингу автентифікація: захищайте доступ операторів від викрадення облікових даних, а не покладайтеся лише на паролі.
- Моніторинг підписання: позначайте незвичні обсяги, адреси призначення й години роботи для розслідування.
- План пісочниці й призупинення: доведіть, що оператори можуть зупинити нові запити та безпечно відновити сервіс, не припускаючи, що відправлені в мережу транзакції можна повернути.
Наш посібник із безпеки гаманців надає контекст для порівняння захисту в різних архітектурах гаманців.
Чітко визначте межу відповідальності
Клієнт відповідає за правильні адреси гаманців, вибір мережі й активу, суми, дані отримувачів, інструкції транзакцій, а також власні рішення щодо відповідності вимогам і ризиків. Транзакції в блокчейні можуть бути незворотними.
Якщо конфігурація використовує Co-Signer під керуванням клієнта або матеріали підписання чи відновлення під контролем клієнта, клієнт має експлуатувати й захищати ці компоненти. Це охоплює контроль доступу, резервні копії та правила схвалення.
Наші умови відповідальності виключають втрати, спричинені інструкціями чи засобами контролю клієнта, Co-Signer під керуванням клієнта, скомпрометованими обліковими даними клієнта, непідтримуваними процесами, зовнішніми блокчейнами або сторонніми системами, якщо їх прямо не спричинило наше власне порушення умов. Вважайте цей розподіл операційною межею під час призначення відповідальних, а не заміною планування інцидентів.
Практичний урок — відокремити того, хто може підписати, від того, хто може відновити доступ, а потім перевірити обидва шляхи. Резервна копія, яку ніхто не відновлював, і політика відновлення, яку ніхто не випробував, не є доказами готовності до запуску.
Запитання покупців про некастодіальні гаманці
Чи може постачальник відновити мої кошти в разі втрати доступу?
Ні, не за замовчуванням у суто некастодіальній архітектурі. Відновлення залежить від налаштованого вами шляху, уцілілих матеріалів авторизації та Co-Signer під контролем клієнта там, де застосовується така схема.
Хто сплачує мережеві комісії?
Ви — через гаманець, який ініціює транзакцію. Мережеві комісії списуються з цього гаманця, ми не додаємо окремої сторонньої комісії, а ви маєте підтримувати достатню кількість потрібного комісійного активу, оскільки комісія блокчейну не залежить від нас і може змінитися між оцінюванням та виконанням.
Чи доступний BroWallet зараз?
Ні, BroWallet позначено як продукт, що незабаром з'явиться, зокрема із запланованим позиціюванням гаманця AI Agents та інтерфейсами Telegram, веб і мобільними застосунками. BroWallet і BroCard — окремі продукти: згадки на сайті не надають доступу й не включають їхні майбутні функції до BroSettlement, а після запуску діятимуть окремі умови.
Чи усуває некастодіальна модель роботу з відповідністю вимогам?
Ні, некастодіальна модель не усуває обов'язків клієнта щодо відповідності вимогам. AML-перевірка, аудиторські сліди, рольовий доступ і регуляторні рішення все одно потребують відповідальних власників; технічна інфраструктура підтримує ці процеси, а не замінює їх і не робить нас юридичним радником клієнта.
Хто експлуатує застосунок після інтеграції?
Ваша команда залишається відповідальною за експлуатацію свого застосунку, навіть якщо делегує визначені завдання підтримки. Пояснення Grail Computer Labs про те, що охоплюють послуги з керування застосунками, допомагає відрізнити постійне обслуговування застосунку від повноважень зберігання активів, схвалення транзакцій і відповідальності за відновлення.
Підтвердьте модель гаманця до запуску
Застосуйте правило хто підписує, хто відновлює, хто пояснює до демонстрації в пісочниці, а не лише до архітектурного слайда. Впровадження має залишатися зрозумілим, коли підписувач недоступний, подія надходить із запізненням або виконавець повторює завершену команду.
Підготуйте докази для рішення про запуск
- Назвіть кворум підписання: задокументуйте власника Co-Signer, дозволених учасників, відповідальних за відновлення й схвалення, потрібні для їх зміни.
- Перелічіть стани операційного журналу: продемонструйте результати у станах спостереження, очікування, підтвердження й відхилення з ідентифікаторами, що пов'язують бізнес-команди з активністю в блокчейні.
- Виконайте тести дублікатів і повторних спроб: покажіть, що повторні запити й сповіщення не створюють додаткових виплат або непідтримуваних зарахувань.
Фінансова команда повинна мати змогу простежити транзакцію, не просячи інженерів тлумачити неструктуроване вивантаження журналу. Операційна команда має знати, який компонент призупинити, а команда з відповідності — мати змогу отримати відповідні докази схвалення.
Наші інженери допомагають проєктувати гаманці, операційні журнали, політики підписання й події від початку до кінця. Практичний шлях від пісочниці до запуску охоплює налаштування консолі й калібрування комісій, а BroSettlement і документація API на нашому сайті надають технічні деталі.
Виберіть конфігурацію, поведінку якої в разі відмови ваша команда може продемонструвати. Успішний переказ доводить наявність з'єднання; контрольована відмова доводить значно більше про готовність.
BroLabel пропонує інфраструктуру вбудованих MPC-гаманців, інтеграцію Co-Signer під контролем клієнта й операційні журнали для побудови підзвітних транзакційних процесів. Відвідайте BroLabel, щоб спланувати пісочницю BroSettlement, яка охоплює політику підписання, відповідальність за відновлення, опрацювання подій і перевірки звірки. Bro has your back!
