Зберігання цифрових активів та інфраструктура гаманців 2026

Зберігання активів є архітектурою контролю

Надійність залежить від того, хто може дозволити рух активів, які операційні правила оточують ці повноваження та чи залишається доступним перевірений шлях відновлення після відмови звичайної залежності.

Зберігання цифрових активів часто зводять до категорії на кшталт самостійного зберігання, регульованого зберігання, MPC, холодного зберігання чи смартрахунку. Такі назви описують лише один рівень. Повна архітектура має пояснювати, хто може створити чинний підпис, хто змінює правила схвалення, де перебувають матеріали ключів, які системи спостерігають і звіряють рух коштів та що відбувається, коли підписувач, провайдер, з'єднання з мережею або застосунок клієнта недоступні. Звіт Range корисний тим, що розділяє моделі зберігання, технології та операційний стек, а не подає їх як синоніми. [1]

Перше питання стосується повноважень. Володіння однією часткою ключа може давати участь без контролю, тоді як сторона з достатньою кількістю часток для досягнення порогу може діяти одноосібно, навіть якщо клієнт також зберігає резервну частку. Друге питання стосується залежностей. Клієнт може контролювати матеріали підписання й водночас залежати від розміщених у провайдера механізмів правил, записів рахунків, інтерфейсів, блокчейн-вузлів або договорів. Третє питання стосується доказів. Задокументована функція не дорівнює продемонстрованому контролю, а криптографічна конструкція не доводить працездатність резервних копій, керування доступом чи реагування на інциденти в конкретному розгортанні.

Тому цей звіт оцінює архітектури за чотирма пов'язаними критеріями: повноваженнями підписання, операційною відповідальністю, незалежністю відновлення та якістю доказів. Ми не призначаємо універсальну оцінку безпеки. Одна модель може відповідати одному пулу активів і не підходити іншому, бо вимоги до ліквідності, юридичні зобов'язання, частота транзакцій, склад команди та очікування щодо відновлення різняться. Практична мета полягає в тому, щоб кожна межа довіри була настільки чіткою, аби продуктова команда, безпека, операційна команда та команда з відповідності бачили власну роботу.

Чотири моделі зберігання по-різному розподіляють повноваження

Власна інфраструктура, стороннє зберігання, активи на біржі та гібридний контроль створюють різні поєднання повноважень підписання, юридичної залежності й операційної роботи.

У моделі з власною інфраструктурою організація керує ключами та самостійно проєктує схвалення й відновлення. Це може дати прямі технічні повноваження, але водночас концентрує відповідальність за пристрої, програмне забезпечення, доступ, резервні копії, спостереження, персонал і реагування на інциденти. Самостійне зберігання не означає відсутності залежностей. Воно замінює договірну залежність від зберігача більшою внутрішньою операційною роботою та залежністю від обраного обладнання, програм, мереж і сервісів.

Сторонній зберігач приймає доручення щодо захисту активів або виконання їх руху через конкретну юридичну особу, договір, юрисдикцію та конфігурацію продукту. Юридичний статус активів, процес виведення, страхування, ланцюг субзберігання, режим неплатоспроможності та безперервність сервісу не випливають із самого слова «зберігач». Активи на біржі додають ризик майданчика, бо торгівля й виконання виведень належать до одних комерційних відносин. Біржі корисні для ліквідності, але ліміти та маршрути виходу мають враховувати концентрацію, створену цією зручністю.

Гібридні моделі розподіляють повноваження підписання або відновлення між клієнтом і провайдером чи поєднують кілька рівнів зберігання. Сама категорія надто широка, щоб визначити контроль. Гаманець 2-of-2, конструкція 2-of-3, де одна сторона володіє двома частками, і конструкція 2-of-3, де клієнт контролює незалежний кворум відновлення з двох часток, суттєво відрізняються. Таблиця нижче зосереджена на тому, хто може діяти, яка залежність залишається і що має робити клієнт. Ми свідомо уникаємо оцінок «найвища безпека» чи «відсутність ризику», бо наявні докази не містять спільної методики випробувань.

Шість технологій вирішують різні частини системи

EOA, multisig, MPC, HSM, TEE та смартрахунки можна поєднувати. Жодна з цих технологій не визначає повну модель зберігання чи операцій.

Зовнішній обліковий запис дозволяє блокчейн-дії за допомогою приватного ключа. Його видима простота переносить складність у генерацію та зберігання ключа, формування транзакцій, доступ і відновлення. Multisig переносить поріг у логіку ончейн-рахунку. У системах на кшталт Safe власників і пороги можна налаштовувати, підписи можна зібрати до одного виклику виконання, а modules можуть додати окремі шляхи виконання. Тому multisig не можна зводити до окремої ончейн-транзакції для кожного підписувача чи до конструкції, що завжди потребує нового гаманця після зміни власника. [5]

MPC розподіляє обчислення підпису між учасниками. DKG може створювати частки без попереднього складання повного приватного ключа, тоді як процеси з імпортованим ключем можуть мати інші передумови. Повноваження визначають поріг і власники часток, а не кількість часток на схемі. HSM захищає операції з ключами у спеціалізованому обладнанні або керованому апаратному сервісі, але саме розгортання визначає, чи організація, чи провайдер контролює інтерфейс підписання. Наприклад, AWS CloudHSM документує операції PKCS#11 для генерації ключів і підписання, але це саме по собі нічого не говорить про бізнес-правила схвалення. [2, 6]

TEE ізолює код і дані в захищеній обчислювальній межі, однак твердження про безпеку залежить від обладнання, атестації, ланцюга постачання програм, адміністрування та обробки відмов. Смартрахунки додають програмовану авторизацію, групування дій, відновлення й правила на рівні рахунку. EIP-7702 дозволяє EOA встановити делегування коду, яке зберігається після транзакції авторизації, доки його не буде змінено або очищено. Його не варто називати автоматично тимчасовим або приписувати підтримку будь-якому гаманцю без прямого доказу. [7]

Вибір технології має випливати з моделі повноважень та операційної потреби. Казначейство може поєднати холодні резерви на базі HSM з операційними MPC-гаманцями. Застосунок може використовувати смартрахунок в одній мережі та контрольований через MPC EOA в іншій. Регульований зберігач може використовувати MPC всередині, тоді як клієнт бачить договірний процес схвалення. Доречне порівняння з'ясовує, що захищає технологія, хто нею керує, як відбуваються зміни, які існують шляхи виконання та чи було відновлення відпрацьовано.

Частки ключа мають значення лише разом із порогом

Частка є матеріалом участі. Контроль визначають достатній кворум, адміністративні домени за ним і правила його використання.

Позначення порогу потрібно читати буквально. У конструкції 2-of-3 будь-яка дозволена пара може створити чинний підпис. Якщо провайдер контролює дві активні частки, він уже може мати достатній кворум, навіть коли клієнт контролює третю. Частка клієнта може покращувати резервування або брати участь в окремих процесах, не даючи права вето. І навпаки, якщо клієнт контролює дві частки в окремих доменах, він може мати незалежний кворум відновлення, але безпекова перевага різних доменів компрометації зникає, коли частки постійно зберігаються разом або доступні одному скомпрометованому адміністратору.

Адміністративне розділення є частиною практичного змісту криптографії. Повна карта часток пов'язує кожну частку з юридичним власником, інфраструктурною межею, групою доступу, місцем резервування, контекстом шифрування, призначеним шляхом та операційним станом. Схема з трьома літерами без цих фактів може створювати хибне відчуття безпеки. Такий самий аналіз потрібен для змін правил: той, хто може замінити підписувача, знизити поріг, увімкнути модуль або змінити правила адрес отримувачів, може мати контроль, невидимий у кворумі підписання.

DKG змінює історію генерації, але не завершує операційну конструкцію. Учасникам усе одно потрібні автентифікований зв'язок, надійне зашифроване зберігання, ротація доступу, резервні копії та докази того, що всі потрібні артефакти належать до тієї самої генерації гаманця. Навчання з відновлення перевіряє цей зв'язок до інциденту. Якщо лише під час відмови провайдера з'ясовується, що Share B, Share C, пароль або метадані мережі відсутні, теоретичний кворум не створив реальної можливості відновлення.

Операційний стек починається до підписання й завершується після підтвердження

Створення гаманця, намір транзакції, схвалення, підписання, відправлення в мережу, обробка подій, облікові записи та звірка утворюють один безперервний шлях контролю.

Чинний підпис доводить, що обрана криптографічна умова авторизації виконана. Він не доводить, що платіж дозволений бізнесом, адреса отримувача пройшла перевірку, кошти надала правильна юридична особа, мережа прийняла транзакцію чи баланс клієнта оновлено правильно. Архітектура зберігання стає операційною лише тоді, коли намір транзакції, контекст схвалення, стан підписувача, стан мережі та фінансові записи можна пов'язати без ручного тлумачення кожного руху.

Конструкція ліквідності визначає, які гаманці мають бути доступні для частих рухів, а які активи допускають повільніший контроль. Гарячий, резервний і холодний режими є операційними описами, а не універсальними оцінками безпеки. Гаманець для частих виплат може виправдовувати автоматичні правила в суворих межах, тоді як довгострокові резерви можуть вимагати повільнішої церемонії та іншого складу учасників. Операційний журнал має зберігати зобов'язання кожної дії: хто її запитав, з якого рахунку надано кошти, яку комісію сплачено, яка мережева транзакція виникла та як відображено скасування чи відмову.

Відправлення в блокчейн також є життєвим циклом, а не двійковою дією. Транзакція може залишатися в черзі, бути підписаною без відправлення, потрапити до mempool, бути заміненою, завершитися помилкою, підтвердитися або зазнати впливу реорганізації. Споживачам подій потрібна ідемпотентність, бо повідомлення можуть повторюватися або надходити після тимчасового розриву. Звірка має порівнювати ончейн-результат із внутрішніми зобов'язаннями та враховувати очікування, комісії, непідтримувані активи й ручні виправлення. Операційний стек Range показує цю ширшу відповідальність, а деталі реалізації належать кожному продукту й процесу клієнта. [1]

Правила, спостереження та реагування є окремими засобами контролю

Рішення до підписання може запобігти дії, спостереження може виявити закономірність, а реагування на інцидент може обмежити шкоду. Жоден рівень не замінює інші.

Правила до підписання мають оцінювати факти, які визначають дозволений рух: організацію, роль, актив, мережу, суму, адресу отримувача, контрагента, час, швидкість операцій і стан схвалення. Callback або механізм правил створює місце для рішення, але наявність точки інтеграції не доводить повноту правил клієнта. Ефективний розподіл обов'язків, контроль адрес, ліміти, аварійне призупинення та керування змінами залежать від налаштувань і від людей, які можуть їх змінювати.

Спостереження відповідає на інше питання: що відбувається з гаманцями, підписувачами, API, користувачами та мережами? Корисні сигнали охоплюють невдалу автентифікацію, незвичні зміни адрес, недоступність підписувача, зростання черги, затримані підтвердження, повторні nonce, розбіжності балансів і доступ до матеріалів відновлення. Події WebSocket та аудит-журнали можуть надавати докази, але автоматично не створюють виявлення аномалій, санкційну перевірку, відповідальність за сповіщення чи процедуру реагування. Потрібні явні пороги, маршрути, ескалація та збереження доказів.

Реагування перетворює виявлення на контрольовану зміну стану. Це може означати призупинення клієнтського процесу, ротацію API-облікових даних, відключення підписувача, зменшення експозиції гаманця, зміну мережевого маршруту або початок церемонії відновлення. Кожна дія має іншого відповідального та інший масштаб наслідків. Шлях, який повертає доступ до активів, але залишає застосунок без операційного журналу, може захистити вартість і водночас створити облікові проблеми та проблеми підтримки клієнтів. Повна інструкція називає рівень, який відновлюється, та докази для повернення до звичайної роботи.

BroSettlement відповідає клієнтсько-керованій гібридній MPC-моделі

Звичайне підписання A+B поєднує інфраструктуру BroSettlement із Co-Signer, розгорнутим у клієнта. Клієнт окремо контролює B і C для незалежного кворуму відновлення.

BroLabel розробляє BroSettlement, тому цей розділ є відкрито позначеним прикладом власного продукту, а не нейтральною оцінкою стороннього провайдера. Публічна документація описує інфраструктуру вбудованих MPC-гаманців із DKG, пороговим підписанням 2-of-3, Co-Signer, розгорнутим у клієнта, операціями транзакцій через автентифікований API, операційним журналом і подіями життєвого циклу. Ми класифікуємо архітектуру як клієнтсько-керовану гібридну MPC, бо звичайні повноваження розподілені між BroSettlement та інфраструктурою клієнта. Ця класифікація не визначає юридичний статус розгортання та не замінює регульованого зберігача, якщо він потрібен. [2, 3]

Share A перебуває в інфраструктурі BroSettlement. Share B є зашифрованим матеріалом, який Co-Signer клієнта використовує у звичайному шляху A+B. Share C є окремим матеріалом відновлення під контролем клієнта й зберігається поза активним середовищем Co-Signer. Однієї частки недостатньо. У звичайному режимі Co-Signer клієнта через вихідне з'єднання отримує завдання підписання та може викликати адресу правил клієнта перед участю. За задокументованим розподілом платформа не може створити чинний підпис лише з A. Це висновок із документації продукту, а не незалежна перевірка криптографічної реалізації. [2, 3, 4]

Межа продукту виходить за підписання й охоплює операції гаманців і транзакцій. Публічні матеріали описують доступ у межах організації, автентифікацію запитів Ed25519, RBAC, список дозволених IP-адрес, перевірки nonce, доступні активи й мережі, події WebSocket та записи журналу. Ці можливості є складовими продукту з вбудованими гаманцями, але клієнт залишається відповідальним за прив'язку користувачів, конструкцію схвалень, правила адрес і контрагентів, регуляторний аналіз, обробку винятків та звірку з власними зобов'язаннями. BroSettlement є інфраструктурою всередині продукту клієнта, а не OTC-деском чи повним сервісом відповідності вимогам. [2, 3, 8]

Опис відновлення має називати залежність, яку воно усуває

Шлях B+C у BroSettlement може усунути Share A та API BroSettlement із відновлення доступу до активів. Він автоматично не відновлює сервіс, журнал, події чи застосунок клієнта.

Клієнтський кворум B+C призначений для відновлення без участі BroSettlement. Поточний публічний інструмент аварійного відновлення документує одну транзакцію native TRX або стандартного TRC-20 у TRON mainnet чи Nile з використанням відповідних артефактів Share B і Share C та первинних матеріалів шифрування. Це межа доступної публічної реалізації станом на 14 вересня 2026 року. Її не можна узагальнювати як наявний інструмент для кожної мережі чи активу. [4]

Наступний крок — поширити ту саму модель відновлення B+C під контролем клієнта на кожен блокчейн, який підтримує BroSettlement. План розвитку зберігає чіткий принцип: клієнт має незалежний шлях до своїх активів, коли платформа недоступна. Поточні можливості та підтримку мереж описано в посібниках із відновлення. [4, 11]

Відновлення доступу до активів вужче за безперервність сервісу. Успішна транзакція B+C може перемістити активи на адресу під контролем клієнта, але не відтворює API гаманців, не повертає історію журналу, не повторює події, не відбудовує баланси користувачів, не відкриває виведення та не відновлює власний застосунок клієнта. Для цих результатів потрібні резервні копії, альтернативна інфраструктура, звірені записи, комунікаційні процедури та перевірена відповідальність. У розглянутих доказах не встановлено SLA, RTO чи RPO для такого ширшого відновлення.

Корисна перевірка відновлення має три рівні. Перший, криптографічне відновлення, перевіряє здатність кворуму й артефактів створити підпис. Другий, мережеве відновлення, перевіряє, чи можна сформувати підтримувану транзакцію, забезпечити комісію, відправити й підтвердити її. Третій, операційне відновлення, перевіряє повернення внутрішніх записів, клієнтських зобов'язань, дозволів і процесів підтримки до відомого стану. Проходження першого рівня є необхідним доказом, але не доводить третій.

Конфігурації розкривають більше, ніж назви компаній

Портфель провайдера може містити кілька моделей повноважень. Корисне порівняння називає точний продукт, поріг, рівень виконання, шлях відновлення та дату доказів.

Range розрізняє Fireblocks Direct Custody 3-of-3 та Embedded Wallets 2-of-2, однак ширші ринкові порівняння можуть втрачати цю різницю, коли стискають провайдера до одного рядка. Ці дві конфігурації не однаково розподіляють повноваження клієнта й провайдера. Доречним доказом є актуальна документація конкретного робочого середовища та продукту; у цьому звіті різниця показує лише недостатність порівняння за назвою компанії. Ми не аудіюємо Fireblocks і не поширюємо одну конфігурацію на весь портфель. [1, 9]

Safe ілюструє інший рівень. Його конструкція смартрахунку показує ончейн-власників, поріг, виконання транзакцій і модулі. Рахунок Safe може бути частиною моделі зберігання, але контракт рахунку не визначає, хто юридично контролює кожного власника, де зберігаються матеріали підписувачів, як організовано схвалення чи як звіряються офчейн-книги. Так само продукт HSM описує захищене середовище підписання, а не повну послугу зберігання. Порівняння архітектур спочатку узгоджує рівні, а вже потім зіставляє функції. [5, 6]

Таблиця конфігурацій нижче фіксує лише властивості, підтверджені зазначеною документацією. «Не перевірено» означає, що огляд не встановив цього факту, а не відсутність можливості. Такий підхід не перетворює брак доказів на негативну оцінку. Він також не дозволяє подавати задокументований репозиторій коду, callback правил або процедуру відновлення як доказ сертифікації, страхування, операційної швидкодії чи юридичного статусу.

Операційна відповідність починається з руху активу

Вбудовані гаманці, казначейство, біржова ліквідність і регульоване зберігання потребують різних повноважень, доступності, обліку та відновлення.

Вбудований стейблкоїн-гаманець є сильним прикладом частого операційного процесу. Оператор продукту прив'язує гаманець до користувача або бізнес-рахунку, спостерігає надходження, чекає потрібних підтверджень, зараховує внутрішнє зобов'язання, перевіряє запит виплати, бере участь у підписанні, відправляє транзакцію в доступну мережу, споживає події життєвого циклу та звіряє остаточний результат. Інфраструктура гаманців надає адреси, підписання, події та записи. Оператор відповідає за клієнтський досвід, бізнес-ліміти, контроль фінансових злочинів, баланси клієнтів і винятки.

Казначейство зазвичай містить кілька пулів із різними потребами в русі. Операційні баланси можуть надавати перевагу контрольованій доступності, а стратегічні резерви зменшеній експозиції та формальним церемоніям. Біржові баланси можуть бути потрібні для виконання, але їх слід обмежувати за майданчиком, активом і залежністю виведення. Регульоване зберігання може бути необхідним, коли бізнесу потрібні ліцензована юридична особа, певний режим активів, звітність або договірний захист. Компонент гаманця зі спільним підписанням автоматично не надає цих юридичних та інституційних функцій.

Правильною конструкцією може бути портфель, а не один переможець: операційні гаманці для клієнтських процесів, окреме зберігання резервів, контрольована експозиція на біржах і задокументований шлях між ними. Кожне переміщення між рівнями потребує власника, схвалення, часу, лімітів і звірки. Мета архітектури не в максимізації одного абстрактного виду контролю. Вона має розмістити відповідні повноваження й залежності навколо кожного руху активів та зберегти зрозумілу картину всієї позиції.

Юридичні висновки й докази потребують точних меж

Конструкція підписання має значення для юридичного аналізу, але не визначає його. Документація підтримує архітектурні твердження, а аудити, сертифікації, швидкодія, доступність і результати відновлення потребують власних доказів.

Нездатність провайдера підписати одноосібно може бути важливою межею, але сама по собі не визначає, чи є модель зберіганням, аутсорсингом, постачанням технології або іншою регульованою послугою. Юридичний аналіз може розглядати договірні повноваження, поняття володіння чи контролю, відокремлення активів, режим неплатоспроможності, розкриття клієнтам, операційну свободу та конкретні юридичні особи. Відповідь може різнитися за юрисдикцією, активом і типом клієнта. Технічні факти залишаються корисними, коли їх відокремлено від непідтверджених висновків про ліцензування.

Така сама дисципліна потрібна для змін бухгалтерських правил. У США Staff Accounting Bulletin 122 Комісії з цінних паперів і бірж скасував інтерпретаційні вказівки SAB 121. Ця зміна стосується попередніх бухгалтерських вказівок працівників SEC; вона не надає загального дозволу на зберігання, не страхує цифрові активи та не визначає юридичний статус певного провайдера. Твердження про відображення в балансі чи обов'язки захисту потребують актуального бухгалтерського та юридичного аналізу для звітної юридичної особи. [10]

Запит доказів має відповідати твердженню. Для ліцензування потрібен запис регулятора чи реєстру з назвою юридичної особи та сферою дозволу. Для сертифікації потрібні сертифікат, період і межа системи. Для страхування потрібні обсяг покриття та виключення. Для відокремлення активів потрібні договори й операційні записи. Для криптографічного контролю потрібні докази конструкції та реалізації. Широкі слова про відповідність без цих зв'язків приховують рішення замість його спрощення.

У цьому огляді використано рамку Range, публічну документацію продуктів, нормативні специфікації та офіційні технічні матеріали. Ці джерела підтримують описи призначеної архітектури й задокументованих інтерфейсів. Вони незалежно не підтверджують криптографічну коректність, безпечне розгортання, безперервну доступність, налаштування клієнта чи результат навчання з відновлення. Для цього звіту не виконувалися реальна транзакція підписання, переказ відновлення, тест на проникнення, аудит контролю або перевірка доказів клієнта.

Для BroSettlement розглянуті докази не встановили незалежний аудит безпеки, звіт SOC 2, сертифікацію ISO 27001, страхове покриття, статус qualified custodian, авторизацію MiCA, затримку підписання, пропускну здатність, SLA, RTO чи RPO. У звіті немає таких тверджень. Доступ до коду Co-Signer може допомогти технічній перевірці, але доступність коду не є аудитом усіх компонентів платформи. Задокументована команда відновлення є доказом спроєктованого шляху, а не підтвердженням того, що кожен клієнт зберіг правильні матеріали та відпрацював процедуру. [2, 3, 4]

Докази також втрачають актуальність. Підтримувані активи й мережі, версії підписувачів, API, юридичні особи, сертифікації та інструменти відновлення можуть змінитися після публікації. Факти у звіті перевірено 14 вересня 2026 року. Тому рішення про запуск або закупівлю залежить від повторної перевірки точної конфігурації продукту з фіксацією версії, дати, межі й джерела кожного суттєвого твердження. Невідоме залишається невідомим до появи відповідного доказу.

Рішення починається з повноважень і завершується навчанням

Найсильнішою є архітектура, яку конкретна організація може пояснити, експлуатувати, спостерігати й відновити з урахуванням реальних юридичних і кадрових обмежень.

Обґрунтоване рішення починається з активу та зобов'язання: кому належить актив, хто кому винен вартість, яка юридична особа керує продуктом, як часто актив має рухатися та що означатиме втрата доступу. Далі аналіз охоплює кожен шлях виконання, зокрема звичайний кворум підписання, аварійний кворум, адміністратора правил, адміністратора облікових даних, хости підписувачів, модулі рахунку, дії провайдера та залежності від мереж. Шлях, який існує лише на схемі, залишається твердженням про конструкцію до перевірки потрібних артефактів і відповідальності.

Наступний рівень поєднує підписання з операціями через стани транзакцій, ідемпотентність, правила адрес і контрагентів, ліміти експозиції, записи журналу, відповідальність за події, звірку та черги винятків. Повна конструкція визначає, які засоби контролю залишаються доступними під час відмови провайдера, підписувача, API або мережі. Поведінка балансів і комунікації з клієнтами після затриманої, пізно підтвердженої, заміненої чи незалежно відновленої транзакції показує, чи організація контролює повний процес, чи лише підпис.

Останній рівень складають докази для конкретних тверджень і навчання. Технічні схеми, договори, ліцензії, аудиторські звіти, сертифікати, умови страхування, записи розгортання, дані спостереження та результати відновлення відповідають на різні питання й потребують визначених власників і дат перегляду. Результати проходження звичайних та аварійних шляхів із репрезентативними активами показують, що залишається недоступним на кожному етапі. Центральний висновок простий: криптографічна технологія може посилити межу контролю, але надійність виникає з узгодження повноважень, операцій, доказів і перевіреного відновлення навколо реального продукту.