«Мы децентрализованы, лицензия не нужна»: почему этот аргумент больше не работает

DeFi уже давно перестал быть нишевым экспериментом. Через децентрализованные протоколы проходят операции с цифровыми активами на миллионы долларов и строятся полноценные бизнес-модели. Поэтому важно не то, использует ли проект децентрализованную архитектуру, а то, какую функцию он выполняет для пользователей и рынка

В своей практике я все чаще слышу от фаундеров один и тот же аргумент: если проект построен как DEX или DeFi-протокол, значит, лицензия ему не требуется. Несколько лет назад такой аргумент мог казаться убедительным, но сегодня он уже не работает и вот почему.

Функциональный подход

Одну из базовых логик для регулирования криптопроектов сформулировала Группа разработки финансовых мер борьбы с отмыванием денег (ФАТФ). В ее подходе поставщик услуг в сфере виртуальных активов (VASP) определяется не через форму бизнеса или используемую технологию, а через выполняемую функцию. В периметр VASP могут попадать лица, которые как бизнес осуществляют или активно содействуют операциям с виртуальными активами от имени другого лица. Речь об обмене, переводе, хранении или администрировании активов, а также финансовых услугах, связанных с выпуском или продажей виртуального актива. Ключевыми становятся не централизация или децентрализация, а наличие услуги, бизнес-модели и экономической роли в операции.

Во многих юрисдикциях определения VASP воспроизводят или развивают логику Рекомендации 15 ФАТФ: регулирование строится вокруг видов деятельности, а не вокруг технологической формы проекта. При этом в таких определениях обычно нет деления на централизованные и децентрализованные модели. Поэтому хотя VASP на практике часто ассоциируется с биржей, кастодианом или брокером, это не означает, что децентрализованная или некастодиальная платформа автоматически находится вне регулирования.

Отдельная сложность возникает с DeFi-проектами, которые широко используются на рынке. Например, кредитные протоколы, где пользователи предоставляют ликвидность, занимают активы под обеспечение или получают доход от размещения цифровых активов, не всегда очевидно укладываются в классические категории обмена, перевода или хранения. Но это не делает их автоматически нерегулируемыми. В отдельных юрисдикциях такие модели уже учитываются в специальных режимах, например в DIFC (финансовой зоне Дубая).

При этом ФАТФ прямо отделяет программное обеспечение от лиц, которые могут стоять за ним. DeFi-приложение как программный код само по себе не является VASP. Однако создатели, владельцы, операторы или иные лица, которые сохраняют контроль или достаточное влияние над DeFi-моделью и при этом предоставляют или активно содействуют VASP-услугам, могут рассматриваться как регулируемые участники.

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

Граница между кодом и финансовой услугой

Функциональный подход не означает, что любой разработчик DeFi-инфраструктуры автоматически становится финансовым посредником. Важно различать публикацию программного кода и организацию финансовой услуги с использованием этого кода.

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

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

Ключевой вопрос звучит так: интерфейс только помогает пользователю технически оформить самостоятельное решение или фактически организует совершение сделки?

В Великобритании Управление по финансовому регулированию и надзору (FCA) смотрит на это через широкое понимание организации сделок с криптоактивами. Для регулятора важно не то, как сервис себя называет, а какую роль он выполняет в цепочке операции. Под периметр может попасть не только сервис, который сам исполняет сделку, но и сервис, который создает условия для ее совершения. Если сайт или приложение позволяет пользователю выбрать актив, направить распоряжение, разместить ордер, подключиться к торговой площадке или получить подтверждение операции, такой интерфейс может рассматриваться как часть сделки, а не как нейтральная технология. Общего исключения для «технических сервисов» в этой части FCA не предусматривает.

В США подход сформулирован иначе. Позиция Комиссии по ценным бумагам и биржам США (SEC) касается пользовательских интерфейсов, через которые могут подготавливаться операции с криптоактивами, квалифицируемыми как ценные бумаги. Такой интерфейс может оставаться вне регистрации в качестве брокера-дилера только при соблюдении строгих условий нейтральности. Пользователь должен сам принимать решение о сделке и определять ее основные параметры: актив, объем, цену и маршрут исполнения. Интерфейс может технически оформить это решение, но не должен подталкивать к конкретной операции, давать инвестиционные рекомендации, выбирать маршрут по субъективным критериям или представлять один вариант как «лучший» или «надежный».

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

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

Контроль как граница ответственности

Логика ФАТФ важна не только для вопроса лицензирования. Она показывает более общий подход: программный код сам по себе не является регулируемым участником, но лица, которые сохраняют контроль или достаточное влияние над DeFi-моделью, могут попасть в правовой периметр. Этот же вопрос возникает и в судебной практике: где заканчивается нейтральная технология и начинается ответственность тех, кто фактически может на нее влиять.

Показательный пример — американское дело Van Loon v Department of the Treasury, связанное с Tornado Cash. Tornado Cash — это криптомиксер, то есть протокол, который позволял разрывать очевидную связь между адресом отправителя и адресом получателя криптоактивов. В 2022 году Управление по контролю за иностранными активами Министерства финансов США (OFAC) включило Tornado Cash в список SDN, поскольку, по позиции OFAC, протокол использовался для отмывания денежных средств, полученных преступным путем.

В суде возник ключевой вопрос: можно ли применять санкционный режим к неизменяемым смарт-контрактам как к имуществу, если никто не может ими владеть, управлять или ограничить доступ к ним? Это было важно, потому что полномочия OFAC по International Emergency Economic Powers Act связаны с блокировкой имущества или имущественных интересов. Суд первой инстанции поддержал позицию OFAC и допустил, что смарт-контракты могут рассматриваться как имущество. Однако Апелляционный суд пятого округа США пришел к иному выводу в отношении неизменяемых смарт-контрактов.

По логике суда, базовый признак имущества — возможность владения и исключения других лиц из доступа к объекту. Если после размещения смарт-контракта в блокчейне никто, включая первоначальных разработчиков, не может изменить его код, удалить его из Сети, отключить его работу или запретить другим лицам взаимодействовать с ним, такой объект не поддается обычному имущественному контролю. Поэтому неизменяемый смарт-контракт не может быть «заблокирован» как имущество в смысле IEEPA.

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

Эту вторую сторону вопроса показывает английское дело Tulip Trading Ltd v Van der Laan. Если в Tornado Cash ключевым стало отсутствие контроля над неизменяемыми смарт-контрактами, то в Tulip Trading суд рассматривал обратную ситуацию: может ли группа разработчиков нести ответственность перед пользователями Сети, если у нее фактически есть возможность влиять на работу блокчейн-инфраструктуры.

Истец утверждал, что потерял доступ к значительному объему Bitcoin из-за утраты приватных ключей и пытался обязать разработчиков нескольких блокчейн-сетей изменить код так, чтобы активы были переведены на новый адрес. По сути, он просил признать, что разработчики не просто поддерживают программное обеспечение, а занимают особое положение по отношению к пользователям Сети. Суд первой инстанции отклонил иск. Однако Апелляционный суд Англии и Уэльса позволил делу двигаться дальше, указав, что вопрос о возможных обязанностях разработчиков требует анализа фактов.

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

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

Подводя итоги

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

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

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