Многие основатели криптокомпаний выходят на рынок ЕС с мыслью, что сначала им нужно выяснить, существует ли отдельная «лицензия на стейкинг». Обычно это неправильная отправная точка. В рамках MiCA реальная проблема заключается не в названии продукта, а в юридической природе услуги. Режим применяется к поставщикам услуг, связанных с криптоактивами, с 30 декабря 2024 года, при этом переходные положения могут позволить некоторым уже действовавшим провайдерам продолжать работу до 1 июля 2026 года или до принятия решения по авторизации — в зависимости от того, что наступит раньше.
Поэтому правильнее задавать другой вопрос: вы просто даёте пользователям доступ к протоколу или фактически предоставляете регулируемую услугу, связанную с клиентскими активами, контролем, хранением или обязательством возврата? Именно в этой точке MiCA начинает действительно иметь значение.
ЕС не выдаёт отдельную «лицензию на стейкинг»
MiCA не создаёт отдельную категорию лицензии под названием staking. Такой аккуратной фантазийной папки просто не существует. Но опубликованные Q&A ESMA дают реальному бизнесу гораздо более понятную позицию: если провайдер предлагает услуги стейкинга и при этом держит криптоактивы клиента или приватные ключи, дающие доступ к ним, такая услуга рассматривается как вспомогательная по отношению к хранению и администрированию криптоактивов от имени клиентов. ESMA указывает, что такие staking services, соответственно, требуют авторизации MiCA на хранение и администрирование.
Это означает, что юридический анализ строится вокруг контроля, а не вокруг брендинга. Страница с надписью «получайте вознаграждения» не превращает кастодиальную модель магическим образом в нейтральный программный инструмент. Регуляторы будут смотреть, кто фактически контролирует среду кошельков, кто может перемещать активы, кто управляет логикой валидаторов и кто остаётся ответственным, если что-то пойдёт не так.
Почему кастодиальный стейкинг обычно попадает в периметр CASP
Правила MiCA о хранении — это не расплывчатые обои на стене. Регламент требует, чтобы провайдеры, предлагающие хранение и администрирование от имени клиентов, вели реестры позиций, устанавливали политику хранения, отделяли клиентские активы, обеспечивали процедуры возврата и несли ответственность за убытки, которые могут быть им вменены. Это не декоративные элементы compliance; это операционные обязанности, привязанные к регулируемой услуге.
Именно поэтому staking-as-a-service обычно становится вопросом CASP, если провайдер:
- принимает клиентские активы на кошельки, которые он контролирует;
- удерживает приватные ключи или иную форму фактического контроля;
- управляет процессом стейкинга от имени клиента;
- или по договору обязуется вернуть активы после оказания услуги.
В этот момент модель уже не является просто «доступом к сетевым вознаграждениям». Она начинает выглядеть как бизнес, основанный на хранении, с дополнительными операционными и юридическими последствиями.
Yield-сервисы шире — и опаснее при ленивой классификации
Слово yield намного более messy, чем staking. Некоторые yield-продукты по сути являются кастодиальным стейкингом в более красивой упаковке. Другие опираются на lending, управление treasury, повторное использование активов, залоговые стратегии или смесь нескольких источников дохода, спрятанных за одной кнопкой в приложении.
Это различие важно, потому что совместный отчёт EBA и ESMA от января 2025 года анализирует staking, lending и borrowing как отдельные криптобизнес-модели с разными рисками. Отчёт носит аналитический характер и не является новым сводом правил, но он усиливает ключевую мысль: не каждый продукт, который маркетируется как «yield», аккуратно помещается в одну коробку MiCA, а lending-структуры поднимают другой набор юридических и пруденциальных вопросов.
Поэтому когда компания говорит, что предлагает «yield», само по себе это почти ничего полезного не говорит регулятору. Настоящие вопросы неудобнее и важнее:
- Откуда берётся доходность?
- Кто несёт риск контрагента?
- Клиентские активы стейкаются, выдаются в займ, объединяются в пул, закладываются или используются внутри компании?
- Кто принимает на себя убытки, если стратегия проваливается?
- И на что именно согласился клиент?
Это и есть разница между анализом регулируемого продукта и маркетинговым слоганом в пиджаке.
Четыре модели, которые часто смешивают между собой
1. Прямой кастодиальный стейкинг
Это самый понятный случай. Клиент переводит криптоактивы на платформу, платформа стейкает их, а вознаграждения распределяются согласно условиям платформы. Если провайдер сохраняет хранение или контролирует доступ, позиция ESMA явно указывает на необходимость авторизации CASP для хранения и администрирования.
2. Ассистированный или делегированный стейкинг с ограниченным контролем
Некоторые компании предоставляют только маршрутизацию, интерфейс, инструменты выбора валидатора или вспомогательные слои, в то время как клиент сохраняет прямой контроль над активами. Такие модели требуют более детального анализа периметра регулирования, потому что ответ зависит от фактического контроля, а не от того, насколько «non-custodial» выглядит главная страница сайта.
3. Доходность, генерируемая через lending или дальнейшее размещение активов
Как только доходность начинает происходить из lending, внутренних treasury-стратегий, цепочек обеспечения или экспозиции к третьим сторонам, анализ становится сложнее. Отчёт EBA и ESMA 2025 года прямо рассматривает crypto lending, borrowing и staking как разные виды деятельности и подчёркивает различия в их риск-профилях.
4. Структурированные продукты доходности
Иногда платформа упаковывает несколько механизмов в один yield-продукт и представляет его как простую функцию в стиле сберегательного продукта. С юридической точки зрения именно там начинаются проблемы. Чем больше слоёв экспозиции, дискреции и встроенных прав содержит продукт, тем менее полезно называть его «просто yield».
Что на самом деле будет интересовать регуляторов
Лицензионную проверку staking или yield-сервисов нельзя выиграть, просто посыпав схему юридическими buzzwords и надеясь, что файл станет величественным. Органы будут хотеть точного объяснения того, как модель работает на практике.
Это означает, что заявка или юридический анализ должны ясно показывать:
- как принимаются клиентские активы;
- объединяются ли активы в пул или хранятся отдельно;
- кто контролирует ключи или учётные данные доступа;
- как генерируются вознаграждения;
- возможны ли убытки, например slashing;
- подвергаются ли активы когда-либо риску третьих сторон;
- как активы возвращаются;
- и на что клиент прямо согласился.
Эти пункты — не абстрактная теория. Режим MiCA по хранению прямо требует механизмов защиты клиентов, таких как сегрегация активов, процедуры возврата, политики хранения и стандарты ответственности за убытки, которые могут быть отнесены к провайдеру.
Почему основатели так часто ошибаются
Обычная ошибка — не в недостатке энтузиазма. Она в отсутствии декомпозиции продукта.
Компания создаёт один кошелёк. Внутри этого кошелька она объединяет staking rewards, внутреннее размещение активов, экспозицию к третьим сторонам, маржу на комиссиях и, возможно, какой-то lending. Затем всё это называется «earn». С точки зрения продаж звучит гладко. С точки зрения регулирования это клоунская машина, набитая классификационными проблемами.
Другая частая ошибка — считать, что техническая архитектура автоматически отвечает на юридический вопрос. Не отвечает. Ключевой вопрос не в том, использует ли система smart contracts, валидаторы, dashboard’ы или красивые диаграммы со стрелочками. Вопрос в том, кто что контролирует, кто что должен клиенту и какая регулируемая услуга фактически предоставляется.
Практический вывод
Для бизнеса, который планирует предлагать стейкинг в ЕС, самая безопасная исходная презумпция такова: если вы держите клиентские активы или контролируете средства доступа к ним, одновременно предоставляя стейкинг для клиентов, вы, скорее всего, смотрите в сторону авторизации CASP на хранение и администрирование в рамках MiCA. Q&A ESMA по этому вопросу достаточно прямое.
Для yield-сервисов ответ менее аккуратный. Некоторые продукты — это просто стейкинг в более красивой одежде. Другие — частично staking, частично lending, частично treasury management и частично будущая головная боль. Такие модели нужно картировать услуга за услугой, поток за потоком, риск за риском. Иначе юридический анализ в итоге строится на тумане, а туман — ужасный фундамент для регулируемого бизнеса.
Заключение
Стратегия CASP для staking или yield-сервисов должна начинаться с сути модели, а не с ярлыков. MiCA не выдаёт отдельную лицензию на staking, но охватывает кастодиальные staking-модели через правила о хранении и администрировании криптоактивов от имени клиентов. В то же время более широкая категория «yield» может включать очень разные структуры, некоторые из которых выходят далеко за рамки простого анализа staking.
Поэтому умный ход — не спрашивать: «Можем ли мы назвать это staking-продуктом?» Правильный вопрос: «Что именно мы делаем с клиентскими активами и какой объём авторизации это запускает?» Один вопрос ведёт к лицензионной стратегии. Другой — к дорогим сюрпризам.
FAQ
Существует ли отдельная лицензия на staking в рамках MiCA?
Нет. MiCA не создаёт самостоятельную staking-лицензию. Согласно опубликованной позиции ESMA, если провайдер стейкает клиентские активы и при этом держит сами активы или приватные ключи, услуга требует авторизации на хранение и администрирование криптоактивов от имени клиентов.
Требует ли каждый yield-продукт лицензии CASP?
Не автоматически. «Yield» — это широкий коммерческий ярлык, который может охватывать staking, lending, borrowing или более сложные структуры. Юридический анализ зависит от того, как создаётся доходность и какой контроль или экспозиция лежит под продуктом.
Когда MiCA начала применяться к CASP?
MiCA применяется к CASP с 30 декабря 2024 года, с переходными положениями для некоторых провайдеров, которые уже работали в соответствии с применимым национальным законодательством до этой даты.
Когда MiCA начала применяться к CASP?
MiCA применяется к CASP с 30 декабря 2024 года, с переходными положениями для некоторых провайдеров, которые уже работали в соответствии с применимым национальным законодательством до этой даты.
Что нужно проверить перед запуском?
Перед запуском продукта нужно проверить потоки активов, контроль кошельков, настройку валидаторов, структуру клиентского договора, механизм доходности, логику сегрегации и любое использование lending или экспозиции к третьим сторонам. Эти пункты определяют, насколько комфортно модель вписывается в предполагаемый объём авторизации.
Получить поддержку по MiCA-лицензии
