Перейти к содержанию
Financial Context Wiki

Кастодиальные кошельки: контроль, требования и риск вывода

Узнайте, как кастодиальные кошельки разделяют контроль подписания в блокчейне и право владельца на учетную запись, а также как оценивать поддержку, разделение, безопасность и вывод средств.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Прямой ответ

Кастодиальный кошелек — это аккаунт или сервис, при котором провайдер или порог подписи, контролируемый провайдером, может разрешать перемещение криптоактивов, тогда как пользователь не может самостоятельно создать требуемое авторизованное действие в блокчейне. Пользователь аутентифицируется у провайдера и подает инструкцию; провайдер решает, принимать ее или нет, и, при необходимости, подписывает или выполняет транзакцию в блокчейне. Решающее значение имеет фактический контроль, а не то, называется ли продукт кошельком.

Баланс, показанный на кастодиальном счете, обычно является записью во внутреннем реестре провайдера, представляющей право в соответствии с соглашением по счету. Сам по себе он не является неизрасходованным выходом транзакции, балансом счета или назначением токена, зарегистрированным для этого пользователя в блокчейне. Точная юридическая природа, статус владения, приоритет и возможность исполнения права на снятие зависят от договора, структуры кастодиального обслуживания, организации, актива и применимого законодательства; один только экранный баланс не отвечает на эти вопросы.

Хранитель может использовать общие адреса, отдельные адреса, горячее или холодное хранение, аппаратные модули безопасности или MPC. Ни одна из этих категорий не определяет, кто имеет окончательный контроль. Уникальный депозитный адрес всё равно может быть объединён в общий кошелёк, а MPC остаётся кастодиальным, если поставщик может собрать порог, заменить участников, блокировать инструкции или инициировать восстановление без участия пользователя. Напротив, умный счёт с сервисом восстановления не обязательно является кастодиальным, если пользователь сохраняет независимый путь выполнения и сервис не может единолично перемещать или окончательно блокировать активы.

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

Как оценивать и использовать кастодиальный кошелек

1. Определить границу фактического контроля

Определите каждый ключ, подписанта, роль в контракте, движок политики, процесс восстановления и администратора, необходимых для перемещения или заморозки актива. Спросите, может ли пользователь создать действительное авторизованное действие в цепочке без участия провайдера, и может ли провайдер перемещать, задерживать, перенаправлять, восстанавливать или блокировать актив без новой авторизации пользователя. Зафиксируйте пороговое значение и кто может его изменить. Логин, находящийся в распоряжении пользователя, авторизует инструкцию внутри сервиса; это не то же самое, что приватный ключ блокчейна.

2. Установить поставщика и юридическое требование

Запишите точное название договаривающейся стороны, юрисдикцию, тип счета, классификацию клиента, применимые условия и любых указанных субкастодианов. Определите, что говорится в документах о праве собственности, выделении активов, бенефициарной собственности, кредитовании, стейкинге, зачете требований, залогах, страховании, форках, эирдропах, неплатежеспособности и выводе средств. Регуляторное разрешение в одном месте или для одной деятельности не устанавливает защиту для каждой организации, клиента или актива, поэтому проверяйте объем с соответствующим органом и получайте квалифицированную юридическую консультацию, если последствия значительны.

3. Сверить депозиты и внутренний реестр

Перед внесением депозита проверьте сеть, контракт токена, адрес, мемо или тег, минимальную сумму, правило подтверждения и политику зачисления. После этого сохраните идентификатор транзакции, сумму, комиссию, время, получателя и выписку по счету; сверьте окончательный on-chain перевод с зачисленной суммой. Адрес для депозита или мемо могут быть идентификатором учёта, а не отдельным кошельком. Внутренние сделки, переводы между клиентами, комиссии, вознаграждения и возвраты могут изменять записи в бухгалтерской книге без какой-либо конкретной транзакции on-chain для клиента.

4. Проверить обеспечение, обособление и обременения

Ищите доказательства, охватывающие правильное юридическое лицо, активы, обязательства перед клиентами, время оценки, контроль над кошельком, разделение активов, частоту сверок и ограничения, такие как залог, кредитование, обеспечение или другие обременения. Разграничивайте активы клиентов и собственные активы и определяйте омнибус-кошельки, банки, маркет-мейкеров и субкастодианов в цепочке. Резервный адрес доказывает лишь то, что кто-то, контролирующий его, мог подписать вызов; доказательство включения Merkle может показать, что один счет был включен в набор обязательств. Ни одно из них не доказывает, что были включены все обязательства, активы не были заимствованы, контроли были эффективны или что провайдер был платежеспособен до или после снимка.

5. Оценить управление ключами и безопасность аккаунта

Проверьте горячее, тёплое и холодное распределение у провайдера; дизайн HSM или MPC; порог подписания; разделение ролей; утверждения на вывод средств; резервное копирование и восстановление ключей; контроль изменений; ведение журналов; реагирование на инциденты; концентрацию поставщиков; и исключения по страховке. Для пользовательского аккаунта предпочтительно использовать аутентификацию, устойчивую к фишингу, отдельно защищать канал восстановления, при необходимости включать белые списки для вывода средств и задержки изменений, ограничивать ключи API только необходимыми правами и адресами, а также отслеживать каждый вход и вывод средств. Сильная аутентификация аккаунта не исправляет слабые меры хранения, а надёжное хранение не предотвращает подачу злоумышленником запроса, выглядящего как авторизованный, через скомпрометированный аккаунт.

6. Проверить весь путь вывода

Проверьте актив, сеть, контракт токена, получателя, мемо, сумму, указанную комиссию, минимум, суточный лимит, состояние проверки и ожидаемую политику объединения перед подтверждением. Проведите тестовое небольшое снятие на адрес, контроль над которым вы независимо подтвердили. Принятие провайдером не означает трансляцию в сеть, идентификатор транзакции не является окончательным расчетом, а внутренний статус не является доказательством получения. Проверьте фактическую транзакцию, контракт актива, сумму, получателя, подтверждения или окончательность и результатирующий доступный баланс вне провайдера.

7. Ограничить экспозицию и подготовить выход

Сохраняйте только ту сумму и срок, которые необходимы для цели услуги, с учетом рисков и затрат альтернатив. Устанавливайте лимиты подверженности по поставщику и взаимозависимостям, периодически проверяйте вывод средств, пересматривайте измененные условия и разрешения, а также сохраняйте выписки, записи транзакций, сообщения службы поддержки и налоговые документы. Диверсификация снижает концентрацию у одного поставщика, но не устраняет риски, связанные с общим банком, облаком, стейблкоином, юрисдикцией или рынком. Если доступ или вывод средств не удаются, прекратите увеличивать подверженность, используйте аутентифицированные каналы поддержки, сохраняйте доказательства и при необходимости обращайтесь к соответствующему органу или квалифицированному консультанту.

Рабочие примеры

Сверка депозита, внутренней сделки и вывода

Пользователь вносит 2 BTC, и провайдер зачисляет внутреннее обязательство 2 BTC после того, как будет выполнено его правило подтверждения. Пользователь продает 0.6 BTC внутри системы за 60,000 USDC/BTC, получая 36,000 USDC; запись в журнале BTC становится 2 - 0.6 = 1.4 BTC, хотя эта сделка не обязательно должна создавать перевод в блокчейн. Вывод средств списывает 1.2 BTC плюс комиссию провайдера 0.0005 BTC, оставляя 1.4 - 1.2 - 0.0005 = 0.1995 BTC во внутреннем журнале. Пользователь должен отдельно проверить, что внешнее адрес действительно получает 1.2 BTC; операции депозита и вывода сами по себе не доказывают внутреннюю продажу.

Валовые резервы и покрытие свободными от обременений активами

Отчет показывает 10,000 BTC контролируемых активов и 9,600 BTC обязательств перед клиентами, поэтому валовое покрытие составляет 10,000 / 9,600 = 104.1667%. Если 1,200 BTC заложено или иначе недоступно для клиентов, свободные от обременений активы составляют 10,000 - 1,200 = 8,800 BTC; эффективное покрытие составляет 8,800 / 9,600 = 91.6667%, с дефицитом в размере 800 BTC. Даже действительное подтверждение включения для одного счета не устанавливает, что сумма обязательств или цифра обременения является полной.

Очередь на вывод и доступная ликвидность

Клиенты подают заявки на вывод средств на сумму 180 BTC. У поставщика есть 60 BTC, сразу доступные в его горячем кошельке, и он может перевести не более 40 BTC/hour через утвержденный процесс пополнения. После обработки 60 BTC оставшиеся 180 - 60 = 120 BTC потребуют как минимум 120 / 40 = 3 hours в наилучшем случае. Это оценка ликвидности и процесса, а не доказательство платежеспособности или обещанное время завершения; обзоры, доступность подписантов, лимиты, инциденты и окончательность блокчейна могут увеличивать его.

Экспозиция из-за концентрации и взыскания

Удерживающий владеет 4 BTC: 1.5 BTC у хранителя A, 1 BTC у хранителя B и 1.5 BTC под самостоятельным управлением. Если A становится недоступным, немедленное воздействие составляет 1.5 / 4 = 37.5%, в то время как 2.5 / 4 = 62.5% остаётся доступным через другие соглашения. Если позже процесс вернёт 55% претензий A, восстановление составит 1.5 × 55% = 0.825 BTC, а невозвращённая сумма — 1.5 - 0.825 = 0.675 BTC, или 0.675 / 4 = 16.875% от первоначальных активов. Время, форма активов, расходы и юридический приоритет всё ещё могут изменить экономический результат.

Риски и ошибки при проверке

  • Неверный поставщик или юрлицо: Знакомый бренд может обслуживать счет через иную аффилированную компанию, юрисдикцию или субкастодиана, чем проверил пользователь.
  • Неверное понимание юридического права: Баланс реестра может означать имущество, хранимое для клиента, договорное требование передачи или иное отношение, режим которого зависит от договора и закона.
  • Ошибка омнибусного учета: Даже при наличии агрегированных ончейн-активов депозит, memo, внутренний перевод, форк или ручная корректировка могут быть отнесены не тому клиенту.
  • Несоответствие активов и обязательств: Кастодиан может держать иной актив, сетевое представление, срок или количество, чем должен клиентам.
  • Обременение или повторное использование: Кредитование, залог, стейкинг, обеспечение, зачет или перевод связанному лицу могут сделать номинальные активы недоступными для вывода.
  • Ограничения снимка: Разовая демонстрация резервов может не показать заимствование около даты снимка, последующие переводы или устойчивые недостатки контроля.
  • Неполные обязательства: Пропущенные счета, отрицательные балансы, внешние обязательства или нераскрытое юрлицо могут завысить коэффициент покрытия.
  • Несоответствие ликвидности: Активы могут существовать, но быть заблокированы, застейканы, одолжены, медленно возвращаться или быть недостаточными в горячем кошельке при всплеске выводов.
  • Компрометация ключей: Вредоносное ПО, дефектная генерация, раскрытие копии, сбой криптомодуля или компрометация подписанта могут разрешить несанкционированные переводы.
  • Злоупотребление инсайдера или восстановлением: Операторы с коррелированными одобрениями, аварийными полномочиями или правом сброса могут обойти предусмотренный порог подписи.
  • Концентрация зависимостей: Один облачный или HSM-провайдер, банк, стейблкоин, мост, субкастодиан или юрисдикция могут свести на нет видимую диверсификацию.
  • Захват аккаунта: Фишинг, credential stuffing, кража сессии, вредоносные разрешения OAuth, SIM-swapping или взлом почты могут авторизовать вывод.
  • Злоупотребление каналом восстановления: Слабая проверка личности или поддержка может позволить атакующему сбросить аутентификаторы и обойти обычную защиту входа.
  • Избыточные права API-ключа: Права торговли или вывода, отсутствие ограничений адреса и утечка секретов превращают автоматизацию в прямой путь к убытку.
  • Заморозка или смена политики: Комплаенс-проверки, санкционный скрининг, региональные ограничения, смена условий или спор могут задержать или запретить доступ.
  • Ошибка назначения или сети: Неверная сеть, контракт токена, адрес или memo могут вызвать позднее зачисление, невозможность восстановления или постоянную потерю.
  • Спор о сопутствующих правах: Поставщик может решать, получат ли клиенты награды за стейкинг, права управления, активы форка, airdrop или взысканные суммы.
  • Непрозрачность комиссий и пакетирования: Плата за вывод может отличаться от сетевой комиссии, а пакетирование скрывать сроки без изменения списания клиента.
  • Простой или сбой записей: Остановка сервиса, повреждение реестров, слабая сверка или недоступные выписки мешают и выводу, и предъявлению требований.
  • Несостоятельность и исполнение: Обособление, страхование, аудиторские формулировки или регулирование не гарантируют немедленный возврат, полное взыскание или трансграничное исполнение.

Распространённые заблуждения

Кастодиальный баланс равнозначен личному владению криптоактивами на адресе

Баланс является внутренней записью и связанным требованием. Активы поставщика на блокчейне и юридически исполнимые права пользователя должны оцениваться отдельно.

Уникальный депозитный адрес доказывает обособление активов

Поставщик может контролировать ключ и переводить депозит в омнибусный кошелек. Уникальность адреса может поддерживать атрибуцию без установления юридического или операционного разделения.

Доказательство резервов подтверждает платежеспособность

Доказательства резервов могут быть полезны в пределах заявленного объема, но платежеспособность также зависит от полноты обязательств, собственности, обременений, оценки, контроля и непрерывности. Проверка доказательств резервов не является автоматически аудитом финансовой отчетности.

Холодное хранение или MPC устраняет кастодиальный риск

Эти меры контроля могут снизить определённые риски извлечения ключей или риски подписанта. Они не устраняют риски, связанные с инсайдерами, управлением, счетами, ликвидностью, законодательством, операционной деятельностью или восстановлением.

Активная кнопка вывода гарантирует немедленный доступ

Поставщик может вводить проверки, лимиты, пакетную обработку, техническое обслуживание, заморозки или изменять правила, а блокчейн по-прежнему требует трансляции и завершения операций. Только завершённый внешний вывод восстанавливает независимый контроль.

Связанные темы

Источники

Навигация

Поиск по вики...