Биржа, обменный сервис и противоречивые данные

01 On-Chain Settlement и Internal Ledger

Централизованная платформа одновременно работает в двух учетных контурах.

On-chain

Публичная сеть фиксирует:

• 01 transfers;
• 02 balances;
• 03 token events;
• 04 smart-contract calls;
• 05 состояние транзакции.

Off-chain

Платформа ведет собственный учет:

• 01 UID;
• 02 balance;
• 03 position;
• 04 order;
• 05 fee;
• 06 internal transfer;
• 07 liquidation;
• 08 withdrawal request.

После поступления актива в кастодиальную инфраструктуру пользователь обычно не управляет соответствующими private keys.

Его позиция отражается во внутреннем учете оператора.

Поэтому:

On-chain control платформы ≠ Internal entitlement конкретного клиента.

Для разрешения спора эти два слоя должны быть сопоставлены.

03 Депозит: Memo, Sweep и Omnibus

Условная архитектура CEX:

Client → Deposit address / Memo → Deposit Detection → Internal Credit → Sweep → Hot / Omnibus / Cold infrastructure

Здесь возможны несколько разных разрывов.

Memo / Tag

В отдельных сетях идентификация клиента может зависеть не только от общего адреса, но и от дополнительного Memo / Tag.

Blockchain способен подтвердить поступление актива на адрес платформы, но автоматическая система может не определить конкретного клиента.

Sweep

После приема актива CEX может переместить его с депозитного адреса в агрегированный wallet.

Для token transfer в некоторых сетях исходящему адресу необходим нативный ресурс для комиссии.

Поэтому задержка Sweep может быть связана с:

• 01 fee management;
• 02 congestion;
• 03 treasury limits;
• 04 manual review;
• 05 техническим сбоем.

Но:

Нет Sweep ≠ доказанное умышленное Gas starvation.

Форензик не придумывает мотив.

Он устанавливает:

Когда актив попал под контроль платформы

и:

Почему это не соответствует Internal Ledger.

Omnibus

После агрегации невозможно механически утверждать:

«вот эти конкретные монеты внутри общего кошелька принадлежат клиенту X».

Нужно восстанавливать связь через:

• 01 deposit assignment;
• 02 UID;
• 03 Internal Ledger;
• 04 timestamps;
• 05 withdrawal records.

04 Smart Accounts и ERC-4337

Современная EVM-операция не всегда выглядит как классическая:

EOA → EOA.

ERC-4337 использует:

• 01 UserOperation ;
• 02 bundler;
• 03 EntryPoint;
• 04 HandleOps ;
• 05 при необходимости paymaster.

Bundler объединяет UserOperations и направляет обычную on-chain транзакцию к EntryPoint.

Следовательно:

UserOp ≠ классическая EOA-транзакция,

но:

ERC-4337 ≠ «невидимая blockchain-операция».

Финальное исполнение оставляет on-chain след.

При спорном депозите проверяются:

• 01 sender ;
• 02 EntryPoint;
• 03 HandleOps ;
• 04 token events;
• 05 internal execution;
• 06 destination.

Проблема может находиться не в blockchain, а в депозитном parser CEX, который некорректно интерпретирует конкретный execution path.

05 Internal Transfer и blockchain finality

Обменный сервис может показать клиенту:

• 01 Internal Transfer ID;
• 02 Pay ID;
• 03 Withdrawal ID;
• 04 статус Completed .

Но это еще не отвечает на вопрос:

Произошло ли внешнее blockchain-исполнение?

Internal transfer может быть всего лишь изменением записей внутри базы одной платформы.

Поэтому:

Internal ID ≠ TXID.

При споре устанавливаются:

• 01 тип операции;
• 02 Beneficiary UID;
• 03 внешний TXID, если он должен существовать;
• 04 возможность отмены внутренней записи;
• 05 фактический переход on-chain контроля.

06 Типология ограничений

Статус Frozen сам по себе почти ничего не объясняет.

Бюро разделяет минимум пять причин.

1. Technical / Security

• 01 2FA;
• 02 новое устройство;
• 03 security hold;
• 04 maintenance;
• 05 parser error.

2. AML / Sanctions / Risk

• 01 Source of Funds;
• 02 Risk Score;
• 03 sanctions screening;
• 04 KYC discrepancy.

3. Contractual

Ограничение применяется на основании Terms of Use.

4. Law Enforcement / regulatory

Платформа реагирует на запрос или обязательный акт государственного органа.

5. Insolvency / Liquidity

Ограничение связано с финансовым состоянием самого оператора.

Поэтому:

Один UI-статус ≠ одно правовое основание.

07 API, торговый движок и ликвидации

Другой класс конфликтов возникает не при депозите, а при торговле.

Например:

• 01 интерфейс недоступен;
• 02 REST API отвечает с ошибкой;
• 03 WebSocket завис;
• 04 закрыть позицию невозможно;
• 05 позиция ликвидируется.

Необходимо разделить:

Market data

Order Submission

Matching

Mark / index Price

Liquidation.

Time-Series Audit

Сопоставляются:

• 01 client request timestamps;
• 02 API responses;
• 03 WebSocket feed;
• 04 order acknowledgements;
• 05 mark/index price;
• 06 liquidation record;
• 07 независимые market data.

Внешняя биржа или oracle может использоваться как контрольный источник.

Но:

Цена на другой площадке ≠ автоматически правильная Mark Price спорной CEX.

Нужно учитывать правила самого инструмента.

B-Book / Internal Market Making

Если предполагается конфликт интересов между клиентом и оператором, необходимо доказать саму архитектуру исполнения.

Нельзя автоматически утверждать:

«биржа специально ликвидировала прибыльного клиента».

Проверяется:

• 01 order record;
• 02 execution price;
• 03 mark/index methodology;
• 04 timestamps;
• 05 Terms;
• 06 доступные сведения о matching model.

Форензик устанавливает расхождение исполнения, а не придумывает мотив оператора.

08 MPC и кастодиальная инфраструктура

Кастодиальная архитектура может включать:

• 01 HSM;
• 02 multisig;
• 03 MPC;
• 04 threshold signing;
• 05 policy engine;
• 06 approval quorum.

Сбой одного слоя способен задержать withdrawal.

Но:

Нет исходящего TXID ≠ доказанный MPC key-share failure.

Для вывода необходимы дополнительные признаки:

• 01 withdrawal request;
• 02 platform notices;
• 03 timing;
• 04 SLA;
• 05 массовый характер сбоя;
• 06 иные технические данные.

Предмет проверки:

Когда возникла обязанность исполнить вывод

и:

Что фактически произошло после этого.

09 Bridges, wrapped assets и резервы

Межсетевой контур может выглядеть так:

Native Asset → Lock / custody → Wrapped / synthetic Asset → Burn → Release

При споре нужно разделить:

• 01 исходный актив;
• 02 synthetic representation;
• 03 reserve;
• 04 bridge contract;
• 05 custodian;
• 06 validator / technical operator.

Проверяются:

• 01 mint;
• 02 burn;
• 03 reserve mechanism;
• 04 smart contract;
• 05 contractual responsibility.

Но:

Proof of Reserves ≠ полный аудит платежеспособности.

И:

De-peg ≠ автоматически вина технического валидатора.

10 Insolvency и сегрегация

При дефолте CEX вопрос меняется.

Главное уже не:

«Куда ушли мои монеты?»

а:

«Какова правовая природа моего требования?»

Значение имеют:

• 01 Terms;
• 02 custody agreement;
• 03 applicable law;
• 04 segregation;
• 05 omnibus structure;
• 06 insolvency regime.

Для подпадающих под MiCA кастодиальных CASP предусмотрены требования к учету клиентских позиций и отделению клиентских crypto-assets от собственных активов поставщика.

Но:

Forensic Tracing ≠ автоматическое исключение имущества из конкурсной массы.

Форензик устанавливает фактическую траекторию и entitlement.

Юридическая судьба имущества определяется применимым insolvency law.

11 Law Enforcement и Preservation

Не каждое ограничение со словами Law Enforcement является судебным арестом.

В разных юрисдикциях могут использоваться:

• 01 court order;
• 02 freezing order;
• 03 seizure warrant;
• 04 subpoena;
• 05 preservation request;
• 06 law-enforcement inquiry;
• 07 иные процедуры.

Нужно установить:

Nature of restraint.

Разделяются:

Formal restraint

Существует обязательное юридическое предписание.

Internal / Preservation hold

Платформа временно сохраняет статус-кво в рамках своего compliance-процесса или взаимодействия с государственным органом.

Поэтому:

Нет court Order ≠ автоматически незаконное удержание

и:

«Law Enforcement» в письме ≠ доказанный судебный арест.

12 Юрисдикция и регуляторная эскалация

Перед любой трансграничной претензией строится:

Entity Map.

Необходимо установить:

какое юридическое лицо оказало услугу

↓ какая версия Terms действовала

↓ какое право применимо

↓ какой forum / arbitration указан

↓ какая лицензия охватывает услугу

↓ какой регулятор действительно компетентен.

Наличие бренда Binance, OKX, Bybit или иной глобальной группы в определенной стране не означает автоматически, что спор относится к лицензированному юрлицу этой страны.

Поэтому:

Лицензия бренда ≠ компетенция регулятора по любому аккаунту бренда.

Институциональная эскалация

Вместо эмоционального тикета формируется:

• 01 Statement of Facts;
• 02 chronology;
• 03 TXID / ledger reconciliation;
• 04 Source of Funds;
• 05 contractual basis;
• 06 contested decision;
• 07 requested remedy;
• 08 exhibits.

Регуляторная жалоба применяется тогда, когда установлено:

• 01 лицензированное лицо;
• 02 соответствующая услуга;
• 03 компетентный орган;
• 04 конкретное предполагаемое нарушение.

Она:

Не гарантирует разблокировку,

но может быть самостоятельным законным каналом проверки действий оператора.

13 Анатомия ситуации

14 Проверьте свой сценарий

Это не автоматическая квалификация нарушения платформы. Значение имеет совокупность blockchain-данных, внутреннего учета, договора и применимой процедуры.

16 Что нельзя считать доказанным автоматически

• TXID Success ≠ Internal Credit
• Internal ID ≠ blockchain TXID
• CEX Balance ≠ private-key control
• Sweep ≠ новая сделка клиента
• Нет Sweep ≠ доказанное Gas starvation
• ERC-4337 ≠ «невидимая» blockchain-операция
• API outage ≠ доказанная манипуляция
• Внешняя цена ≠ автоматически Mark Price спорной CEX
• Нет Withdrawal TX ≠ доказанный MPC failure
• Law-enforcement reference ≠ court seizure
• Нет court Order ≠ автоматически незаконный hold
• Asset Tracing ≠ автоматическое исключение из Insolvency Estate
• Proof of Reserves ≠ полный аудит платежеспособности
• Офшорная юрисдикция ≠ отсутствие правовых средств
• Лицензия группы ≠ компетенция регулятора по любому спору

17 Форензик-контур Бюро

Бюро не начинает с утверждения:

«Биржа виновата».

Сначала разделяются восемь уровней.

1. Blockchain

Что произошло в сети.

2. Deposit Architecture

Как платформа должна была обнаружить депозит.

3. Custody

Когда платформа получила фактический контроль.

4. Internal Ledger

Как событие отражено внутри аккаунта.

5. Restriction

Почему ограничено распоряжение.

6. Economic Basis

На каком основании клиент получил актив.

7. Entity / jurisdiction

Какое лицо является стороной договора и какое право применимо.

8. Evidentiary Status

Отдельно фиксируется:

Что установлено

Что заявлено платформой

Что требует внутренних данных

Что является юридической квалификацией.

Формула:

Blockchain → Deposit → custody → Ledger → Restriction → contract → jurisdiction → Evidence File.

18 Что остается закрытым

На публичной странице не раскрываются:

• 01 алгоритмы сопоставления депозитной инфраструктуры CEX с blockchain-движением Контура М4;
• 02 правила reconstruction Omnibus / Hot / Warm / Cold архитектур;
• 03 внутренние методы анализа Internal Netting;
• 04 модели server/API time-series reconstruction;
• 05 правила сопоставления Order Book / Mark Price / Liquidation;
• 06 внутренние процедуры анализа MPC / custody;
• 07 bridge reserve reconciliation;
• 08 Entity Mapping международных платформ;
• 09 карты лицензируемого периметра;
• 10 внутренние модели определения Nature of Restraint;
• 11 эскалационные протоколы;
• 12 шаблоны Institutional Dossier;
• 13 веса;
• 14 пороги;
• 15 матрицы;
• 16 критерии достаточности доказательственного файла.

Публичный слой показывает:

Что подлежит установлению.

Закрытый слой определяет:

Как Бюро сшивает blockchain, кастодиальный контур, Internal Ledger, договор и юрисдикцию.

19 Чего нельзя делать

Не отправлять дополнительные активы на проблемную платформу до установления причины

Не создавать десятки одинаковых тикетов

Не удалять исходную переписку и уведомления

Не подделывать выписки, ордера или Source of Funds

Не передавать private keys, seed-фразы или API-ключи с правом вывода

Не признавать нарушение только ради ускорения review

Не объявлять техническую задержку мошенничеством без доказательств

Не угрожать иностранному регулятору до установления contracting entity

Не платить неизвестным посредникам за «внутреннюю разблокировку»

Не пытаться самостоятельно воздействовать на чужие stablecoin-адреса

Tether / Circle: Blacklist / Blocklist

Централизованные stablecoin-эмитенты действительно могут обладать техническими механизмами ограничения token transfers.

Для USDT Tether предусматривает возможность blacklisting адресов и freezing определенных Tether Tokens в рамках собственных Terms, применимого законодательства и взаимодействия с государственными, регуляторными и правоохранительными органами.

Для USDC Circle также предусматривает Blocked Addresses / blocklisting и возможность freezing при наличии предусмотренных политикой или правом оснований.

Но:

Техническая возможность эмитента ≠ частное право клиента по своему усмотрению «заморозить чужой кошелек».

Вопрос о такой мере решает сам эмитент в пределах:

• 01 своей политики;
• 02 применимого законодательства;
• 03 санкционного режима;
• 04 запроса или акта компетентного органа;
• 05 иных предусмотренных им оснований.

20 Пять этапов разрешения спора

Этап 1. Фиксация

Сохраняются:

• 01 blockchain;
• 02 UI;
• 03 UID;
• 04 tickets;
• 05 email;
• 06 timestamps;
• 07 Terms;
• 08 statuses.

Этап 2. Reconciliation

Строится:

TXID → Deposit Architecture → Platform control → Internal Ledger.

Этап 3. Классификация причины

Определяется:

Technical

или:

AML / Sanctions

или:

Contractual

или:

Law Enforcement

или:

Insolvency / Liquidity.

Этап 4. Entity + Procedure

Устанавливаются:

• 01 contracting entity;
• 02 Terms version;
• 03 governing law;
• 04 forum / arbitration;
• 05 regulatory perimeter;
• 06 complaint route.

Этап 5. Evidence Dossier

Формируется адресное требование:

Credit the Deposit

или:

Correct the Internal Record

или:

Return the Asset

или:

Disclose the Basis of restraint to the extent legally permitted

или иной вывод, соответствующий установленным фактам.

21 Что получает корпоративный клиент

Для первичного разбора не требуется весь архив аккаунта.

Достаточно:

• 01 спорного TXID;
• 02 UID;
• 03 уведомления платформы;
• 04 истории депозита / вывода;
• 05 относящихся к спору Terms;
• 06 документов по конкретному активу.

Результат:

On-chain Fact Map → Deposit Architecture → Platform control Map → Internal Ledger Reconciliation → Restriction classification → Source of Funds File → Contracting Entity Map → jurisdiction / License Perimeter → Evidence Matrix → Institutional Dossier.

Не:

«Письмо в поддержку, что мы хорошие».

А:

Доказательная карта того, что произошло между blockchain и внутренней системой платформы.

22 Принципиальная позиция Бюро

Бюро не занимается:

• 01 обходом KYC/AML;
• 02 обходом санкций;
• 03 вмешательством в чужие аккаунты;
• 04 подделкой Source of Funds;
• 05 получением private keys;
• 06 «решаловом» через знакомых;
• 07 незаконной заморозкой чужих stablecoins.

Бюро также не начинает с презумпции:

«Платформа виновата».

Но не принимает и обратную:

«Если CEX так написала — значит это доказано».

Мы разделяем:

Blockchain-исполнение

от:

Кастодиального контроля

от:

Internal Ledger

от:

Trading Engine

от:

Compliance Decision

от:

Внешнего правового ограничения.

И проверяем каждую точку перехода.

23 Официальные и технические источники

Федеральный закон от 04.08.2026 № 282-ФЗ

С 1 сентября 2026 года формирует специальный российский контур регулирования цифровых валют, организаций обмена, цифровых депозитариев и цифрового учета.

MiCA — Regulation (EU) 2023/1114

Для соответствующих CASP европейский режим устанавливает требования к:

• 01 custody;
• 02 учету клиентских позиций;
• 03 movements;
• 04 custody policy;
• 05 отделению клиентских crypto-assets;
• 06 защите клиентских активов при insolvency.

ERC-4337 — Account Abstraction

Стандарт определяет:

• 01 UserOperation;
• 02 bundler;
• 03 EntryPoint;
• 04 HandleOps ;
• 05 paymaster.

Он имеет значение при исследовании депозитов, сформированных через smart-account architecture.

Tether — USD₮ / Legal Terms

Tether предусматривает в своих действующих юридических условиях возможность:

• 01 blacklisting digital-token addresses;
• 02 Freezing Tether Tokens;
• 03 применения ограничений при подозрении на Prohibited Use;
• 04 взаимодействия с государственными и правоохранительными органами.

В опубликованном Tether в 2026 году Relevant Information Document также прямо указано, что в определенных случаях и по обращениям law-enforcement, regulatory или government agencies Tether может предпринимать действия для freezing USDT во внешних кошельках, private keys которых Tether не контролирует.

Это подтверждает:

USDT smart-contract control

и:

Контроль private key пользователя

— разные уровни технической архитектуры.

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

Circle — USDC Terms

Circle предусматривает:

• 01 Blocked Addresses;
• 02 blocklisting;
• 03 freezing в предусмотренных условиях;
• 04 выполнение действительного legal order компетентного государственного органа.

Следовательно, и для USDC необходимо различать:

On-chain finality самой транзакции

и:

Последующие administrative functions эмитента token contract.

Гражданский кодекс РФ

При применимости российского права могут иметь значение общие нормы:

• 01 о надлежащем исполнении обязательства;
• 02 одностороннем отказе;
• 03 убытках;
• 04 договорной ответственности.

Но иностранный CEX нельзя автоматически квалифицировать как российский банк или хранителя без анализа договора и применимого права.