---
title: "Кастодиальные кошельки: контроль, требования и риск вывода"
description: "Узнайте, как кастодиальные кошельки разделяют контроль подписания в блокчейне и право владельца на учетную запись, а также как оценивать поддержку, разделение, безопасность и вывод средств."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Кастодиальные кошельки: контроль, требования и риск вывода
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Прямой ответ
Кастодиальный кошелек — это аккаунт или сервис, при котором провайдер или порог подписи, контролируемый провайдером, может разрешать перемещение криптоактивов, тогда как пользователь не может самостоятельно создать требуемое авторизованное действие в блокчейне. Пользователь аутентифицируется у провайдера и подает инструкцию; провайдер решает, принимать ее или нет, и, при необходимости, подписывает или выполняет транзакцию в блокчейне. Решающее значение имеет фактический контроль, а не то, называется ли продукт кошельком.
Баланс, показанный на кастодиальном счете, обычно является записью во внутреннем реестре провайдера, представляющей право в соответствии с соглашением по счету. Сам по себе он не является неизрасходованным выходом транзакции, балансом счета или назначением токена, зарегистрированным для этого пользователя в блокчейне. Точная юридическая природа, статус владения, приоритет и возможность исполнения права на снятие зависят от договора, структуры кастодиального обслуживания, организации, актива и применимого законодательства; один только экранный баланс не отвечает на эти вопросы.
Хранитель может использовать общие адреса, отдельные адреса, горячее или холодное хранение, аппаратные модули безопасности или `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 устраняет кастодиальный риск
Эти меры контроля могут снизить определённые риски извлечения ключей или риски подписанта. Они не устраняют риски, связанные с инсайдерами, управлением, счетами, ликвидностью, законодательством, операционной деятельностью или восстановлением.
### Активная кнопка вывода гарантирует немедленный доступ
Поставщик может вводить проверки, лимиты, пакетную обработку, техническое обслуживание, заморозки или изменять правила, а блокчейн по-прежнему требует трансляции и завершения операций. Только завершённый внешний вывод восстанавливает независимый контроль.
## Связанные темы
- [Централизованная биржа](/ru/crypto/cex/)
- [Тест вывода с биржи](/ru/crypto/exchange-withdrawal-test/)
- [Доказательство резервов](/ru/crypto/proof-of-reserves/)
- [Публичные и приватные ключи](/ru/crypto/public-private-key/)
- [Криптовалютный кошелек](/ru/crypto/wallet/)
## Источники
- [Обзор технологии блокчейн](https://doi.org/10.6028/NIST.IR.8202) - NIST (доступ: 2026-08-19)
- [Рекомендация по управлению ключами: Часть 1 - Общие положения](https://doi.org/10.6028/NIST.SP.800-57pt1r5) - NIST (доступ: 2026-08-19)
- [Руководство по цифровой идентичности: аутентификация и управление аутентификаторами](https://doi.org/10.6028/NIST.SP.800-63b-4) - NIST (доступ: 2026-08-19)
- [Рекомендации по политике для рынков криптовалют и цифровых активов](https://www.iosco.org/library/pubdocs/pdf/IOSCOPD734.pdf) - IOSCO (доступ: 2026-08-19)
- [Рекомендации высокого уровня по деятельности и рынкам с криптоактивами](https://www.fsb.org/2023/07/high-level-recommendations-for-the-regulation-supervision-and-oversight-of-crypto-asset-activities-and-markets-final-report/) - Financial Stability Board (доступ: 2026-08-19)
- [Будьте осторожны с проверкой сторонними организациями или отчетами о резерве](https://pcaobus.org/resources/information-for-investors/investor-advisories/investor-advisory-exercise-caution-with-third-party-verification-proof-of-reserve-reports) - PCAOB (доступ: 2026-08-19)
- [Криптоактивные биржевые продукты](https://www.sec.gov/newsroom/speeches-statements/cf-crypto-asset-exchange-traded-products-070125) - U.S. SEC (доступ: 2026-08-19)
- [Криптоактивы объяснены: что MiCA означает для вас как для потребителя](https://www.eba.europa.eu/assets/Updated%20Joint%20ESAs%20Factsheet%20on%20crypto-assets/Updated%20Joint%20ESAs%20Factsheet%20on%20crypto-assets_EN.pdf) - European Supervisory Authorities (доступ: 2026-08-19)
Source: https://wiki.fcontext.com/ru/crypto/custodial-wallet/index.mdx