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

Такой анализ необходим. Но он неполный — даже если протокол функционирует автономно, фронтенд может создавать отдельный класс регуляторных рисков. В некоторых ситуациях он и вовсе рассматривается как самостоятельный сервис.

В новом материале для ForkLog криптоюрист и партнер Aurum Сергей Островский рассказывает о том, в каких случаях DeFi-фронтенд может регулироваться как самостоятельный продукт, и о стратегиях снижения связанных рисков.

Интерфейс — это сервис

Фронтенды могут существенно различаться по уровню юридической сложности и рискам. Блокчейн-эксплорер или read-only-интерфейс — это одна история. Приложение, которое помогает пользователям выбирать финансовые продукты, инициирует транзакции и получает вознаграждение за совершаемые через него операции, — уже совсем иная.

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

Юридическая сложность также возрастает, если фронтенд обеспечивает доступ к ценным бумагам (в том числе токенизированным), деривативам или регулируемым инструментам. В этом случае может применяться уже не крипторегулирование, а традиционное финансовое законодательство.

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

Четыре зоны риска

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

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

Архитектура продукта

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

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

Комиссии

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

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

Доступ

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

Регуляторный статус фронтенда во многом определяется тем, в каких странах он доступен и где находится оператор. Например, европейское регулирование не будет применяться, если он не обслуживает пользователей из ЕС/ЕЭЗ и оператор находится за пределами Евросоюза. Нужно также помнить, что существуют санкционные ограничения и AML-риски.

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

Коммуникация

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

Четыре перечисленных фактора встречаются практически во всех подходах регуляторов, хотя конкретные требования отличаются в разных странах.

Что видно по юрисдикциям

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

MiCA в Евросоюзе регулирует поставщиков услуг, связанных с криптоактивами. Перечень таких услуг исчерпывающий, он закреплен в пункте 16 части 1 статьи 3 регламента. Если фронтенд используется для предоставления одной из таких услуг пользователям в ЕС/ЕЭЗ, необходимо получить CASP авторизацию в одной из стран Евросоюза.

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

В марте 2026 CFTC опубликовала письмо (no-action letter) в отношении Phantom. Комиссия подтвердила, что компания может предоставлять доступ к регулируемым деривативам через собственный интерфейс – некастодиальный кошелек – и такая деятельность не требует авторизации (лицензии), если выполняется ряд условий, среди которых: отказ от хранения средств клиентов; надлежащее раскрытие рисков; соблюдение стандартов в отношении публичной коммуникации и маркетинга.

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

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

Чек-лист для фаундера

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

Практический минимум:

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

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

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

Главный риск — несогласованность

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

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

Read the article at Forklog