Одна страница Proof of Reserves содержит четыре разных утверждения
Слово reserves часто используется как единая оценка надёжности, хотя опубликованный пакет может состоять из несвязанных частей. Биржа показывает пользовательский snapshot, общий commitment к обязательствам, список контролируемых адресов и иногда отчёт третьей стороны. Проверка одной части не переносит доверие на остальные: корректный Merkle path не доказывает владение каждым резервным адресом, а крупный on-chain баланс не доказывает полноту клиентских обязательств.
| Слой | Проверяемый вопрос | Положительный результат | Чего он не доказывает |
|---|---|---|---|
| Ваш leaf / account record | Включён ли конкретный баланс в опубликованный commitment | Локальная проверка строит тот же root | Что учтены все другие клиенты и все долги компании |
| Дерево или ZK-proof обязательств | Соответствуют ли заявленные записи агрегированному commitment | Проверка суммы и заданных ограничений проходит | Что исходная база пользователей полная и не содержит исключений |
| Резервные адреса | Контролирует ли сервис указанные on-chain активы на snapshot | Подпись/транзакция связывает адрес с заявителем, баланс читается в сети | Что актив не заёмный, не заложен и останется доступен |
| Отчёт проверяющей стороны | Какие процедуры кто выполнил и на какую дату | Получены результаты в точных границах задания | Полноценный аудит, если документ прямо им не является |
- Слой
- Ваш leaf / account record
- Проверяемый вопрос
- Включён ли конкретный баланс в опубликованный commitment
- Положительный результат
- Локальная проверка строит тот же root
- Чего он не доказывает
- Что учтены все другие клиенты и все долги компании
- Слой
- Дерево или ZK-proof обязательств
- Проверяемый вопрос
- Соответствуют ли заявленные записи агрегированному commitment
- Положительный результат
- Проверка суммы и заданных ограничений проходит
- Чего он не доказывает
- Что исходная база пользователей полная и не содержит исключений
- Слой
- Резервные адреса
- Проверяемый вопрос
- Контролирует ли сервис указанные on-chain активы на snapshot
- Положительный результат
- Подпись/транзакция связывает адрес с заявителем, баланс читается в сети
- Чего он не доказывает
- Что актив не заёмный, не заложен и останется доступен
- Слой
- Отчёт проверяющей стороны
- Проверяемый вопрос
- Какие процедуры кто выполнил и на какую дату
- Положительный результат
- Получены результаты в точных границах задания
- Чего он не доказывает
- Полноценный аудит, если документ прямо им не является
Начните с паспорта снимка, а не с зелёного процента
Поля, которые нужно выписать до проверки
- Юридическое лицо или группа, к которой относится отчёт, и точное название сервиса.
- Дата и время snapshot с часовым поясом, дата публикации и версия методики.
- Перечень активов и сетей: BTC, ETH, конкретные stablecoins и формы wrapped/staked assets.
- Что считается обязательством: spot, funding, margin, earn, collateral, отрицательные балансы и займы.
- Как подтверждается контроль адресов и какие off-chain активы допускаются в числителе.
- Кто выполнил проверку, по какому стандарту и какие оговорки указаны в отчёте.
Snapshot — фотография конкретного момента, а не подтверждение текущей доступности активов. OKX указывает, что последующие транзакции и токены вне scope не включены. Поэтому сохраняйте дату: фраза «биржа прошла PoR» без неё быстро теряет смысл.
Отдельно проверьте, что перед вами резервы кастодиального сервиса, а не резервы эмитента стейблкоина. Эмитент объясняет обеспечение выпущенного токена, а биржа — покрытие клиентских записей у себя. Материал о стейблкоинах показывает, почему даже одинаковое слово reserve относится к разным обязательствам.
Проверьте включение своего баланса в commitment
Сервис обычно выдаёт идентификатор записи, значения баланса на snapshot, salt или hash и соседние узлы Merkle path. Из leaf и соседних hashes официальный инструмент либо локальный verifier последовательно вычисляет root. Совпадение с опубликованным root означает: предоставленные вам данные входят в этот commitment по указанному пути. Оно не раскрывает чужие балансы и не должно требовать пароль, seed-фразу или код 2FA.
| Действие | Что сверить | Ожидаемый результат | Ошибка и реакция |
|---|---|---|---|
| Открыть PoR внутри аккаунта | Домен, snapshot date, asset и account scope | Доступна запись именно вашего аккаунта | Ссылка пришла в сообщении — закрыть и открыть сервис самостоятельно |
| Скачать или скопировать proof | Leaf/account hash, balances, salt/nonce, Merkle path, root | Данные относятся к одной версии snapshot | Поля разных дат — не смешивать, запросить корректный набор |
| Запустить официальный или open-source verifier | Версия инструмента, checksum/release и ожидаемый root | Calculated root равен опубликованному | Mismatch — повторить на чистом наборе и сохранить ошибку |
| Сверить баланс snapshot | Актив, единица, знак, режим аккаунта и время | Запись объяснимо совпадает с историческим балансом | Необъяснимое отличие — открыть тикет с ID, не публикуя секретные поля |
- Действие
- Открыть PoR внутри аккаунта
- Что сверить
- Домен, snapshot date, asset и account scope
- Ожидаемый результат
- Доступна запись именно вашего аккаунта
- Ошибка и реакция
- Ссылка пришла в сообщении — закрыть и открыть сервис самостоятельно
- Действие
- Скачать или скопировать proof
- Что сверить
- Leaf/account hash, balances, salt/nonce, Merkle path, root
- Ожидаемый результат
- Данные относятся к одной версии snapshot
- Ошибка и реакция
- Поля разных дат — не смешивать, запросить корректный набор
- Действие
- Запустить официальный или open-source verifier
- Что сверить
- Версия инструмента, checksum/release и ожидаемый root
- Ожидаемый результат
- Calculated root равен опубликованному
- Ошибка и реакция
- Mismatch — повторить на чистом наборе и сохранить ошибку
- Действие
- Сверить баланс snapshot
- Что сверить
- Актив, единица, знак, режим аккаунта и время
- Ожидаемый результат
- Запись объяснимо совпадает с историческим балансом
- Ошибка и реакция
- Необъяснимое отличие — открыть тикет с ID, не публикуя секретные поля
Убедитесь, что доказательство учитывает обязательства, а не только красивый набор leaf
Merkle root коммитит к тем записям, которые в него включили. Криптография не обнаруживает клиента, которого оператор исключил до построения дерева. Поэтому важны правила формирования исходной базы, охват продуктов и независимая процедура полноты. Если proof охватывает только spot balances, нельзя распространять вывод на margin loans, earn products или обязательства другой компании группы.
Отрицательные балансы требуют отдельной проверки. Наивная система могла бы уменьшить общую сумму обязательств, добавив аккаунты с большим минусом. Некоторые схемы публикуют non-negative constraints или ZK-proof, подтверждающий правила суммирования без раскрытия пользователей. Успешная математическая проверка говорит о соблюдении заданных ограничений данными, но не подтверждает полноту первичного учёта.
| Вопрос | Зачем | Приемлемое доказательство | Слабый ответ |
|---|---|---|---|
| Какие продукты включены? | Определить границу обязательств | Явный список account types и исключений | «Все средства пользователей» без методики |
| Как обработаны долги и collateral? | Не допустить искусственного уменьшения liabilities | Описанная формула и проверяемые constraints | Только итоговый процент |
| Как установлена полнота базы? | Merkle tree не находит пропущенные записи | Процедуры reconciliation с учётной системой | Заявление самой биржи без процедуры |
| В одной ли единице сравнивают стороны? | Цена может менять ratio | Покрытие по каждому активу или раскрытая valuation policy | Общий долларовый показатель без цен и времени |
- Вопрос
- Какие продукты включены?
- Зачем
- Определить границу обязательств
- Приемлемое доказательство
- Явный список account types и исключений
- Слабый ответ
- «Все средства пользователей» без методики
- Вопрос
- Как обработаны долги и collateral?
- Зачем
- Не допустить искусственного уменьшения liabilities
- Приемлемое доказательство
- Описанная формула и проверяемые constraints
- Слабый ответ
- Только итоговый процент
- Вопрос
- Как установлена полнота базы?
- Зачем
- Merkle tree не находит пропущенные записи
- Приемлемое доказательство
- Процедуры reconciliation с учётной системой
- Слабый ответ
- Заявление самой биржи без процедуры
- Вопрос
- В одной ли единице сравнивают стороны?
- Зачем
- Цена может менять ratio
- Приемлемое доказательство
- Покрытие по каждому активу или раскрытая valuation policy
- Слабый ответ
- Общий долларовый показатель без цен и времени
Проверьте активы: адрес, контроль, баланс и ограничения
Публичный адрес позволяет независимо прочитать баланс и движения, но не имя владельца. Сервис должен связать себя с адресом: например, подписать заранее определённое сообщение ключом, выполнить проверяемую транзакцию или предоставить подтверждение в процедуре третьей стороны. Простого списка адресов на собственном сайте недостаточно, потому что любой может скопировать адрес крупного кошелька.
Даже доказанный контроль не показывает все права третьих лиц. Актив мог быть предоставлен взаймы к моменту snapshot, заложен, находиться под договорным ограничением или стать недоступным после даты проверки. PCAOB отдельно предупреждает, что PoR-report может не раскрывать заёмный характер активов, права клиентов, внутренние контроли и последующее использование резервов.
Проверяя опубликованный адрес, применяйте те же границы, что и к любому публичному кошельку: блокчейн показывает транзакции и токены, но не договорные обязательства и личность. Это подробно разобрано в материале о том, что видно по публичному адресу криптокошелька.
Читайте отчёт как описание процедур, а не как знак качества
Пять строк, которые важнее логотипа проверяющей компании
- Engaging party и responsible party: кто заказал работу и кто подготовил исходные данные.
- As-of date: на какой момент выполнялись процедуры и не смешана ли она с датой публикации.
- Scope: юридические лица, активы, сети, account types и исключения.
- Nature of engagement: audit, attestation, agreed-upon procedures или иная проверка.
- Findings and limitations: что проверяющий увидел, что не проверял и выражал ли assurance opinion.
Agreed-upon procedures сообщают результаты перечисленных действий, а не мнение о платёжеспособности. PCAOB подчёркивает, что PoR reports не эквивалентны аудиту финансовой отчётности и могут находиться вне его надзорного периметра.
Если verification не прошёл, сохраните воспроизводимую ошибку
| Несоответствие | Безопасное действие | Что приложить | Когда остановиться |
|---|---|---|---|
| Calculated root не совпал | Повторно скачать proof той же версии и запустить актуальный официальный verifier | Snapshot ID, tool version, expected/calculated root и точный error | Инструмент просит пароль, seed или remote access |
| Баланс leaf не совпадает | Сверить часовой пояс, account type, asset и операции вокруг snapshot | Историю баланса и user record ID без публикации секретов | Поддержка предлагает вручную изменить proof-файл |
| Адрес резерва не подтверждён | Найти метод доказательства контроля и первичную публикацию адреса | Адрес, сеть, сообщение/подпись и дату | Единственное доказательство — чужой explorer label |
| Отчёт устарел или исчез | Зафиксировать последнюю доступную версию и не переносить её вывод на сегодня | URL, файл, hash файла и дату доступа | Сервис предлагает считать dashboard заменой отчёта без методики |
- Несоответствие
- Calculated root не совпал
- Безопасное действие
- Повторно скачать proof той же версии и запустить актуальный официальный verifier
- Что приложить
- Snapshot ID, tool version, expected/calculated root и точный error
- Когда остановиться
- Инструмент просит пароль, seed или remote access
- Несоответствие
- Баланс leaf не совпадает
- Безопасное действие
- Сверить часовой пояс, account type, asset и операции вокруг snapshot
- Что приложить
- Историю баланса и user record ID без публикации секретов
- Когда остановиться
- Поддержка предлагает вручную изменить proof-файл
- Несоответствие
- Адрес резерва не подтверждён
- Безопасное действие
- Найти метод доказательства контроля и первичную публикацию адреса
- Что приложить
- Адрес, сеть, сообщение/подпись и дату
- Когда остановиться
- Единственное доказательство — чужой explorer label
- Несоответствие
- Отчёт устарел или исчез
- Безопасное действие
- Зафиксировать последнюю доступную версию и не переносить её вывод на сегодня
- Что приложить
- URL, файл, hash файла и дату доступа
- Когда остановиться
- Сервис предлагает считать dashboard заменой отчёта без методики
Если спор касается конкретного движения резервного адреса, сохраните transaction hash и проверьте его в правильной сети. Инструкция о проверке транзакции поможет отделить реальный on-chain перевод от обновления интерфейса. Но отдельный hash всё равно не объясняет договорную причину движения активов.
Используйте PoR как один сигнал решения о хранении
Сильный PoR-пакет даёт пользователю проверяемый leaf, описанный liability scope, доказанный контроль адресов, воспроизводимый инструмент и отчёт с ясными ограничениями. Это лучше непрозрачного обещания, но не отменяет оценку лицензии, договорной стороны, истории вывода, custody model и собственного риска концентрации.
Если активы нужны для частых операций, определите рабочий остаток и не принимайте proof как обещание мгновенного вывода. Для долгого самостоятельного хранения сравните custody models в гайде о выборе криптокошелька: переход в self-custody убирает кредитный риск биржевого баланса, но переносит на владельца ответственность за ключи и backup.
Вопросы о Proof of Reserves
Если мой Merkle proof прошёл, значит ли это, что биржа учла всех клиентов?
Нет. Он подтверждает включение вашей записи и корректность пути к root. Полнота всей клиентской базы требует отдельных процедур reconciliation и контроля исходных данных.
Reserve ratio выше 100% гарантирует вывод?
Нет. Ratio относится к указанному snapshot и scope. Он может не отражать off-chain долги, залоги, ограничения доступа, внутренние контроли и изменения после даты снимка.
PoR — это аудит?
Не обязательно. Нужно читать engagement type и текст заключения. Agreed-upon procedures, attestation и аудит финансовой отчётности имеют разные цели и уровень assurance.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- PCAOB — caution with Proof of Reserve reports Проверено 10 августа 2026 г.
- Kraken — Proof of Reserves Проверено 10 августа 2026 г.
- OKX — Proof of Reserves and verification files Проверено 10 августа 2026 г.
- Binance — Proof of Reserves methodology and verification Проверено 10 августа 2026 г.
- CoinEx — verify account inclusion with Merkle proof Проверено 10 августа 2026 г.