Подтверждение резервов криптобиржи: дерево Меркла, обязательства и ограничения

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

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

Рекомендация Управления по защите инвесторов Совета по надзору за бухгалтерским учетом публичных компаний США (PCAOB) предупреждает о существенных ограничениях отчетов о резервах. В ней выражено мнение сотрудников этого управления, которое не обязательно отражает позицию Совета или других сотрудников PCAOB; это не правило, политика или заявление Совета. В рекомендации говорится, что такие процедуры не являются аудитом по стандартам PCAOB и могут не охватывать обязательства, права клиентов, заемные активы, средства контроля или события после снимка данных. Считайте это предупреждение границей того, какие выводы поддерживают свидетельства, а не утверждением, что все процессы PoR одинаковы.

Коэффициент покрытия обычно рассчитывают, разделив указанную сумму активов на указанную сумму обязательств перед клиентами. Если в отчете указано 1 020 BTC активов в пределах охвата против 1 000 BTC включенных клиентских остатков, простой коэффициент составляет 102%. Такая арифметика имеет смысл лишь после определения числителя и знаменателя. Выражены ли обе величины в BTC? Измерены ли они одновременно? Включены ли в активы только адреса, которыми организация может управлять? Учитывает ли показатель клиентских остатков все счета, продукты и требования, которые организация должна удовлетворить?

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

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

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

В RFC 9162 IETF определены доказательства включения для журналов Certificate Transparency: если восстановленный хеш дерева совпадает с опубликованным корнем, доказательство устанавливает, что предоставленный лист присутствует в зафиксированном дереве. Биржи используют собственные форматы данных и системы доказательств, поэтому RFC служит общим объяснением криптографического принципа, а не спецификацией PoR каждой биржи.

Например, Binance описывает дерево Меркла и процесс zk-SNARK как способы проверить, что записи аккаунтов включены в опубликованный итог, не раскрывая при этом данные других аккаунтов. Kraken описывает включение балансов аккаунтов и доказательства контроля адресов в собственной процедуре PoR. Это описания конкретных поставщиков. Главное общее ограничение остается тем же: проверка вашего листа доказывает его включение в набор данных, для которого зафиксирован корень. Она не доказывает, что оператор изначально составил полный и точный список всех обязательств перед клиентами.

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

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

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

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

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

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

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

Предположим, в условном отчете указано 1 020 BTC активов и 1 000 BTC обязательств перед включенными клиентами. Показанный коэффициент равен 1 020 ÷ 1 000 = 102%. Теперь предположим, что в набор данных не попали требования клиентов на 50 BTC. Полный объем обязательств перед клиентами составил бы 1 050 BTC, а покрытие — 1 020 ÷ 1 050 = 97,14%. Дефицит составил бы 30 BTC — еще до учета других долгов или изменения оценки активов.

В этом примере сумма активов не изменилась. Вывод стал другим из-за изменения состава обязательств. Доказательство Меркла конкретного клиента все еще может быть корректным, если его лист включен; оно не выявит, что требование другого клиента отсутствует в дереве. Поэтому доказательство включения и проверка полноты — отдельные процедуры.

Второй условный пример показывает, почему заемные активы должны сопровождаться учетом соответствующего обязательства. Представим, что у компании есть собственные необремененные активы на 980 000 долларов, а еще 200 000 долларов она заняла и оставила на своих кошельках на момент снимка. В видимых кошельках находится 1,18 млн долларов. Если требования клиентов составляют 1 млн долларов, а обязательство по займу в 200 000 долларов в отчете не учтено, опубликованное сравнение показывает 118%. Если добавить требование кредитора на 200 000 долларов, общий объем обязательств составит 1,2 млн долларов; 1,18 млн долларов, разделенные на 1,2 млн долларов, равны 98,33%, то есть дефициту в 20 000 долларов. Пример предполагает сопоставимые значения на один момент и не учитывает другие активы, сборы и юридические детали. Он показывает, почему снимок активов сам по себе не решает вопрос об обязательствах.

В январе 2026 года Binance объявила об изменении представления PoR, сообщив, что прежний охват чистых балансов аккаунтов не учитывал активы платформы и приводил к завышенному коэффициенту резервов. Это заявление касается собственной методики Binance и ее обновления, а не доказывает, что все биржи считали так же. Это практическое напоминание о том, что нужно читать состав опубликованного коэффициента и проверять, менялась ли методика между отчетами.

Слово «аудит» может встречаться в маркетинговых материалах платформы или в названии отчета, но важны фактический охват и применяемые стандарты задания. В рекомендации сотрудников PCAOB говорится, что задания PoR не выполняются по стандартам аудита PCAOB и не подпадают под инспекции этого органа. Там также отмечается, что поставщики используют разные процедуры и стандарты, а в некоторых заданиях руководство компании может выбирать согласованные процедуры.

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

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

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

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

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

Наконец, подумайте о событиях между снимками. Проверка на конкретный момент не может постоянно отслеживать займы, движения кошельков, изменения аккаунтов, решения руководства или операционные сбои после установленного времени. Наряду с PoR читайте условия вывода, правила хранения, раскрытие сведений о юридическом лице и более широкую финансовую отчетность. С обзором различий между хранением и торговой площадкой можно ознакомиться в руководстве по бессрочным контрактам на CEX и DEX. Различия между собственными ключами и кошельком у посредника описаны в руководстве по восстановлению криптокошелька.

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

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

Корректный вывод должен быть узким и привязанным к дате: «Этот отчет показывает такие-то активы и такие-то включенные балансы по указанной методике на момент снимка, а запись моего аккаунта включена». Если отчет не позволяет уверенно подтвердить даже это, громкого коэффициента недостаточно, чтобы заполнить пробелы. Это руководство объясняет свидетельства и механику хранения активов; оно не рекомендует биржу и не указывает, где кому-либо следует хранить активы.