Blockchain-транзакция и фактический владелец

01 Что действительно доказывает blockchain

Распределенный реестр способен надежно фиксировать технические параметры операции:

• 01 существование транзакции;
• 02 последовательность изменения состояния;
• 03 адреса;
• 04 объем актива;
• 05 временную последовательность;
• 06 параметры комиссии;
• 07 вызовы смарт-контрактов;
• 08 состояние актива в соответствующей сети.

Но blockchain не устанавливает автоматически:

• 01 ФИО владельца;
• 02 его правоспособность;
• 03 волю;
• 04 основание сделки;
• 05 законность получения актива;
• 06 право распоряжения;
• 07 источник происхождения капитала;
• 08 конечного экономического бенефициара.

Поэтому:

Blockchain-запись ≠ юридическая атрибуция субъекта.

02 Псевдонимность адреса и пределы автоматической атрибуции

Для публичных blockchain-сетей точнее говорить не об «анонимности», а о псевдонимности.

Адрес видим.

Транзакции видимы.

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

Но субъект права за адресом непосредственно в реестре, как правило, не указан.

Следовательно, проблема состоит не в отсутствии цифрового следа.

Наоборот:

Цифровой след может быть очень подробным.

Проблема — в другом:

Как доказательно связать этот след с конкретным лицом?

Именно здесь начинается процессуальная атрибуция.

04 Три уровня контроля над криптоактивом

Бюро разделяет минимум три самостоятельных уровня.

Уровень 1. Криптографический контроль

Способность:

• 01 сформировать корректную подпись;
• 02 инициировать транзакцию;
• 03 выполнить необходимую часть multisig;
• 04 управлять smart account.

Этот уровень отвечает на вопрос:

Кто технически может распоряжаться?

Но не обязательно:

Кому актив принадлежит?

Уровень 2. Инфраструктурный контроль

Исследуются:

• 01 устройство;
• 02 программный кошелек;
• 03 hardware wallet;
• 04 сервер;
• 05 CEX-аккаунт;
• 06 2FA;
• 07 сессии;
• 08 RPC-инфраструктура;
• 09 учетная запись оператора.

Этот уровень отвечает на вопрос:

В какой технической среде формировалось действие?

Уровень 3. Экономический контроль

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

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

Именно здесь возникает вопрос:

Кто является фактическим владельцем или бенефициаром?

05 Кастодиальный и некастодиальный режим

Это разграничение принципиально.

Некастодиальный контур

Пользователь сам контролирует криптографический механизм:

• 01 private key;
• 02 seed;
• 03 hardware wallet;
• 04 multisig;
• 05 smart account.

Здесь on-chain адрес непосредственно связан с механизмом распоряжения активом.

Кастодиальный контур

На централизованной платформе пользователь может видеть баланс в учетной записи, но:

• 01 закрытые ключи on-chain инфраструктуры контролирует оператор;
• 02 внутренние переводы могут не отражаться отдельной blockchain-транзакцией;
• 03 пользователь взаимодействует прежде всего с учетной системой сервиса.

Поэтому:

Баланс на бирже ≠ прямой контроль конкретного on-chain адреса.

Правовой режим зависит от:

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

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

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

06 Текущий контроль ≠ историческая атрибуция

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

Это может подтвердить:

Контроль соответствующего криптографического механизма на момент проверки.

Но не автоматически:

Авторство исторической транзакции.

Ключ мог:

• 01 быть передан;
• 02 использоваться несколькими участниками;
• 03 храниться на общем сервере;
• 04 быть скомпрометирован;
• 05 участвовать в multisig;
• 06 применяться техническим оператором;
• 07 использоваться через автоматизированную систему.

Поэтому вопрос:

«кто контролирует ключ сейчас?»

и вопрос:

«кто совершил конкретное действие тогда?»

— два разных предмета доказывания.

07 Sign Message: доказательственное значение и пределы

Криптографическая подпись контрольного сообщения — один из наиболее прямых способов проверить наличие текущей способности удовлетворить соответствующее криптографическое условие без раскрытия секретного ключа.

Но сама процедура зависит от архитектуры конкретной сети и кошелька.

Bitcoin / UTXO-контур

Для Bitcoin одним из технических ориентиров является BIP 322 — Generic Signed Message Format.

Он позволяет строить проверяемые доказательства контроля в рамках Bitcoin-архитектуры, но не превращает текущую подпись в доказательство исторического авторства старой транзакции или юридического права собственности.

EVM-архитектуры

Для Ethereum и совместимых контрактных сред необходимо отдельно учитывать способ формирования и проверки сообщения.

В частности:

• 01 EIP-191 — стандарт формата подписанных данных Ethereum;
• 02 EIP-712 — typed structured data signing, позволяющий подписывать структурированные данные с определенным доменом и типами;
• 03 EIP-1271 — механизм проверки подписей для smart-contract accounts, где валидность определяется логикой самого контракта, а не обязательно одной обычной EOA-подписью приватным ключом.

Это особенно важно при исследовании:

• 01 multisig-кошельков;
• 02 Safe-подобных архитектур;
• 03 smart accounts;
• 04 корпоративных treasury-контуров;
• 05 DeFi-операций;
• 06 authorization flows.

Поэтому универсальной формулы:

«Один адрес → один private key → одна подпись»

не существует для всех blockchain-архитектур.

Доказательственное значение

Условная схема:

Контрольное сообщение → криптографическая / контрактная проверка → публичная верификация → подтверждение технического контроля в рамках конкретной архитектуры

Но:

Sign Message ≠ право собственности.

И:

Sign Message сегодня ≠ доказательство того, кто совершил старую транзакцию.

08 Теневые узлы крипто-атрибуции

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

Но ни один из них не должен превращаться в автоматическое доказательство личности.

След первоначального финансирования комиссии

В сетях, где для отправки операции необходим нативный актив на комиссию, источник первоначального funding может показать связь нового адреса:

• 01 с ранее используемым кошельком;
• 02 CEX-выводом;
• 03 treasury-адресом;
• 04 иной атрибутированной инфраструктурой.

Но:

Gas funding ≠ доказанная личность владельца.

UTXO-эвристики

В UTXO-сетях совместное использование входов может иметь значение для кластерного анализа.

Но вывод необходимо проверять с учетом:

• 01 CoinJoin;
• 02 coin selection;
• 03 custodial aggregation;
• 04 payout infrastructure;
• 05 dusting;
• 06 особенностей программного кошелька.

Поэтому:

Common Input ≠ безусловно один собственник.

RPC- и инфраструктурные журналы

Кошелек или dApp может обращаться к:

• 01 RPC-провайдеру;
• 02 node provider;
• 03 API;
• 04 бирже;
• 05 иной инфраструктуре.

У соответствующих операторов при определенных условиях могут существовать:

• 01 IP-данные;
• 02 временные метки;
• 03 идентификаторы сессии;
• 04 журналы технических запросов.

Но:

IP-адрес ≠ установленное физическое лицо.

Поведенческий профиль

Дополнительное значение могут иметь:

• 01 время активности;
• 02 регулярность;
• 03 последовательность approvals;
• 04 типичные DeFi-протоколы;
• 05 структура комиссий;
• 06 повторяющиеся паттерны взаимодействия.

Но:

Поведенческая корреляция ≠ доказанная идентификация.

Архитектура ключей и smart accounts

При наличии необходимых исходных данных могут исследоваться:

• 01 single-key architecture;
• 02 multisig;
• 03 smart account;
• 04 hardware-wallet architecture;
• 05 derivation scheme;
• 06 EIP-1271 verification;
• 07 конфигурация кошелька.

Но:

Одинаковый derivation path ≠ доказательство единой master-seed.

09 Процессуальная цепочка атрибуции

Надежная атрибуция строится не на одном эффектном техническом признаке.

Необходима взаимная проверка нескольких независимых слоев.

1. Реестр

Что произошло в blockchain.

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

Какой механизм подписи или контрактной авторизации действовал и кто мог удовлетворить соответствующее условие.

3. Инфраструктурный след

Где и через какую техническую среду формировалось действие.

4. On-Ramp / Off-Ramp

Как цифровой актив связан с:

• 01 банком;
• 02 биржей;
• 03 P2P;
• 04 обменом;
• 05 приобретением;
• 06 реализацией.

5. Документальное основание

• 01 договор;
• 02 переписка;
• 03 акт;
• 04 распоряжение;
• 05 корпоративное решение;
• 06 учетные документы.

6. Экономический интерес

Кто:

• 01 финансировал;
• 02 распоряжался;
• 03 определял стратегию;
• 04 получал конечную выгоду.

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

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

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

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

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

• Знание публичного адреса ≠ владение активом
• TXID ≠ воля конкретного человека
• Контроль ключа ≠ право собственности
• Sign Message ≠ юридическое владение
• Sign Message сегодня ≠ авторство старой транзакции
• Contract signature ≠ один физический подписант
• CEX-баланс ≠ прямой контроль on-chain адреса
• Один IP ≠ один пользователь
• Gas funding ≠ доказанная личность
• UTXO-кластер ≠ безусловно один собственник
• Derivation path ≠ доказанная единая seed-фраза
• Поведенческая корреляция ≠ установленная личность
• Совпадение суммы ≠ доказанная связь с конкретной сделкой

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

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

«Мы уже знаем, чей это кошелек».

Проверка идет последовательно.

1. Blockchain-факт

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

2. Модель криптографического контроля

• 01 Single key / EOA;
• 02 multisig;
• 03 smart account;
• 04 contract-account;
• 05 custodial control.

3. Механизм авторизации

При необходимости отдельно устанавливается, каким способом подтверждалось действие:

• 01 обычной криптографической подписью;
• 02 structured-data signature;
• 03 multisig-кворумом;
• 04 контрактной верификацией;
• 05 иной предусмотренной архитектурой процедурой.

4. Инфраструктура

• 01 устройство;
• 02 сервер;
• 03 аккаунт;
• 04 сессия;
• 05 CEX;
• 06 RPC;
• 07 иные подтвержденные технические данные.

5. Происхождение актива

• 01 fiat;
• 02 P2P;
• 03 CEX;
• 04 перевод;
• 05 хозяйственная операция.

6. Документальное основание

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

7. Экономический интерес

Кто финансировал, распоряжался и получил выгоду.

После этого строится:

Адрес → транзакция → механизм авторизации → криптографический / контрактный контроль → инфраструктурный след → происхождение актива → правовое основание → экономический интерес → процессуальная атрибуция.

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

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

• 01 внутренние алгоритмы кластерного и вероятностного сопоставления адресов Контура М4;
• 02 внутренние эвристики исследования change-адресов, UTXO-графов и иных структур связности;
• 03 методология исследования транзакций, прошедших через CoinJoin-механизмы, миксирующую инфраструктуру, privacy-протоколы и пулы ликвидности;
• 04 правила сопоставления blockchain-следа с RPC-, сессионными, кастодиальными и иными инфраструктурными данными;
• 05 внутренние процедуры исследования multisig, smart-account и архитектуры ключей;
• 06 внутренние правила сопоставления EOA-, structured-data- и contract-signature механизмов;
• 07 регламенты институционального взаимодействия с торговыми, кастодиальными и комплаенс-платформами;
• 08 шкалы значимости вероятностных моделей атрибуции;
• 09 внутренние протоколы межконтурной проверки и ранжирования доказательств.

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

Какие объекты и факторы подлежат проверке.

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

Как Бюро проверяет их происхождение, связность и доказательственное значение.

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

Не передавать приватный ключ или seed-фразу

Не вводить секретные данные в сторонние «сервисы проверки»

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

Не удалять кошелек, приложение или технические журналы до фиксации доказательств

Не менять объяснения относительно режима доступа к кошельку

Не выдавать вероятностный кластер за установленного владельца

Не приписывать действие человеку только по IP

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

Не смешивать технический доступ и юридическое право

Не переносить EOA-модель подписи на smart-contract wallet без проверки его архитектуры

Не передавать Бюро private keys, seed-фразы или полный контроль над активами

17 Пять этапов установления фактического владельца

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

Фиксируются:

• 01 TXID;
• 02 блок;
• 03 timestamp;
• 04 адреса;
• 05 актив;
• 06 сумма;
• 07 комиссия;
• 08 relevant smart-contract events.

Этап 2. Квалификация модели контроля

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

• 01 self-custody;
• 02 CEX;
• 03 EOA;
• 04 multisig;
• 05 smart account;
• 06 contract wallet;
• 07 иной кастодиальный или технический режим.

Этап 3. Криптографическая и инфраструктурная проверка

При наличии законного доступа анализируются:

• 01 тип механизма подписи;
• 02 EIP-191 / EIP-712, если релевантно;
• 03 contract verification по EIP-1271, если применимо;
• 04 устройства;
• 05 сессии;
• 06 серверные журналы;
• 07 wallet configuration;
• 08 RPC-данные;
• 09 CEX-профиль;
• 10 техническая хронология.

Этап 4. Экономическая и документальная сшивка

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

• 01 fiat;
• 02 P2P;
• 03 биржевые операции;
• 04 договоры;
• 05 переписка;
• 06 акты;
• 07 корпоративные решения;
• 08 фактическая выгода.

Этап 5. Доказательственный файл

Формируется конструкция:

Blockchain-факт → механизм авторизации → криптографический / контрактный контроль → инфраструктурная связь → экономический контекст → документальное основание → допустимый вывод об атрибуции.

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

На входе не требуется полный архив криптоопераций.

Работа начинается с целевых материалов:

• 01 публичных адресов;
• 02 спорных TXID;
• 03 документов по конкретной операции;
• 04 CEX/P2P-данных;
• 05 доступных журналов;
• 06 переписки;
• 07 договора или иного основания владения.

Клиент получает:

Карту blockchain-движения → карту модели криптографического контроля → карту механизма авторизации → кастодиальную / некастодиальную квалификацию → инфраструктурную хронологию → Fiat / P2P / CEX-сшивку → документальную карту → матрицу атрибуции → перечень доказанных и недоказанных связей → единый доказательственный файл.

Не:

«Список предположительно чьих-то адресов».

А:

Архитектуру доказательной атрибуции.

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

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

• 01 взломом кошельков;
• 02 подбором seed-фраз;
• 03 получением private keys;
• 04 обещаниями «деанонимизировать любого»;
• 05 обходом KYC/AML;
• 06 сокрытием происхождения криптоактивов;
• 07 выдачей вероятностной метки за доказанный факт.

Бюро делает другое.

Мы отделяем:

Blockchain-факт

от:

Механизма авторизации

от:

Криптографического контроля

от:

Факта действия конкретного лица

от:

Юридического права

от:

Экономической выгоды.

И только после этого проверяем, можно ли связать эти уровни в одну непротиворечивую доказательственную цепь.

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

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

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

Закон отдельно регулирует:

• 01 организации, осуществляющие обмен цифровых валют;
• 02 цифровые депозитарии;
• 03 цифровой учет;
• 04 договор цифрового учета;
• 05 договор предоставления доступа к адресу-идентификатору;
• 06 конфиденциальность соответствующей информации;
• 07 регулирование и надзор.

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

Это дополнительно показывает, почему технический адрес, право доступа и юридическая принадлежность актива нельзя механически объединять в одно понятие.

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

Прежняя ст. 14 «Оборот цифровой валюты» утратила силу с 1 сентября 2026 года в связи с реформой регулирования.

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

Постановление Конституционного Суда РФ от 20.01.2026 № 2-

П

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

BIP 322 — Generic Signed Message Format

Технический стандарт Bitcoin message signing.

Используется при оценке текущего криптографического контроля, но сам по себе не решает вопрос исторического авторства транзакции и юридического права на актив.

EIP-191 — Signed Data Standard

Базовая конструкция Ethereum для подписанных данных.

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

EIP-712 — Typed Structured Data Hashing and Signing

Стандарт структурированной подписи типизированных данных.

Особенно важен для:

• 01 DeFi;
• 02 permit-механизмов;
• 03 authorization flows;
• 04 корпоративных treasury;
• 05 off-chain approvals;
• 06 приложений, где пользователь подписывает не обычную транзакцию, а структурированное сообщение.

При форензик-анализе необходимо фиксировать не только саму подпись, но и:

• 01 domain separator;
• 02 структуру типов;
• 03 message payload;
• 04 контекст подписываемого действия.

EIP-1271 — Standard Signature Validation Method for Contracts

Имеет принципиальное значение для smart-contract wallets.

В такой архитектуре вопрос:

«кто владеет приватным ключом этого адреса?»

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

Поэтому при анализе multisig и smart-account необходимо исследовать:

• 01 код и конфигурацию контракта;
• 02 состав owners/signers;
• 03 threshold;
• 04 модули;
• 05 механизм подтверждения;
• 06 состояние контракта на релевантный момент времени.