Перейти к основному контенту

39 постов с тегом "Соответствие"

Нормативное соответствие и правовые рамки

Посмотреть все теги

xStocks на Solana: Полевое руководство разработчика по токенизированным акциям

· 7 мин чтения
Dora Noda
Software Engineer

xStocks — это токенизированные представления акций и ETF США в соотношении 1:1, выпущенные на Solana в виде SPL токенов. Они созданы для перемещения и компоновки, как и любой другой ончейн-актив, устраняя трения традиционных рынков акций и превращая их в примитив кошелька. Для разработчиков это открывает новые горизонты финансовых приложений.

Solana является идеальной платформой для этой инновации, прежде всего благодаря расширениям токенов (Token Extensions). Эти нативные функции протокола — такие как указатели метаданных, настраиваемые паузы, постоянные делегаты, хуки передачи и конфиденциальные балансы — предоставляют эмитентам необходимые рычаги для соблюдения нормативных требований, сохраняя при этом полную совместимость токенов с экосистемой DeFi. Это руководство содержит шаблоны и практические рекомендации, необходимые для интеграции xStocks в AMM, протоколы кредитования, структурированные продукты и кошельки, соблюдая при этом все необходимые юридические и комплаенс-ограничения.


Большая идея: Акции, которые ведут себя как токены

Для большей части мира владение акциями США сопряжено с посредниками, ограниченными часами работы рынка и длительными задержками расчетов. xStocks меняют это. Представьте, что вы покупаете долю AAPLx в полночь, видите, как она мгновенно оседает в вашем кошельке, а затем используете ее в качестве залога в протоколе DeFi — и все это в сети Solana с низкой задержкой и низкими комиссиями. Каждый токен xStock отслеживает реальную акцию, хранящуюся у регулируемого кастодиана. Корпоративные действия, такие как дивиденды и дробление акций, обрабатываются ончейн с помощью программируемых механизмов, а не бумажных процессов.

Вклад Solana здесь — это не просто дешевые и быстрые транзакции; это программируемый комплаенс. Стандарт расширений токенов добавляет нативные функции, которые ранее отсутствовали в традиционных токенах:

  • Хуки передачи (Transfer hooks) для контроля KYC.
  • Конфиденциальные балансы (Confidential balances) для конфиденциальности с возможностью аудита.
  • Постоянное делегирование (Permanent delegation) для действий по решению суда.
  • Настраиваемые паузы (Pausable configurations) для экстренных заморозок.

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


Как работают xStocks (и что это значит для вашего приложения)

Выпуск и обеспечение

Процесс прост: эмитент приобретает базовые акции (например, Tesla) и выпускает соответствующее количество токенов на Solana (1 акция TSLA ↔ 1 TSLAx). Данные о ценах и корпоративных действиях поступают от выделенных оракулов. В текущей схеме дивиденды автоматически реинвестируются, увеличивая балансы токенов для держателей.

Юридическая обертка

xStocks выпускаются в соответствии с базовым проспектом в качестве сертификатов (или трекеров) и были одобрены в Лихтенштейне FMA 8 мая 2025 года. Крайне важно понимать, что это не предложение ценных бумаг США, и распространение ограничено в зависимости от юрисдикции.

Что получают (и не получают) держатели

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

Где они торгуются

Хотя xStocks были запущены с централизованными партнерами, они быстро распространились по экосистеме DeFi Solana, появившись в AMM, агрегаторах, протоколах кредитования и кошельках. Правомочные пользователи могут самостоятельно хранить свои токены и перемещать их ончейн 24/7, в то время как централизованные площадки обычно предлагают доступ к книге ордеров 24/5.


Почему Solana необычайно практична для токенизированных акций

Инструментарий Solana для реальных активов (RWA), в частности расширения токенов, позволяет командам сочетать компонуемость DeFi с институциональным комплаенсом, не создавая изолированных, закрытых экосистем.

Расширения токенов = Выпуски с учетом комплаенса

  • Указатель метаданных (Metadata Pointer): Синхронизирует кошельки и эксплореры с актуальными метаданными эмитента.
  • Конфигурация масштабируемого количества для UI (Scaled UI Amount Config): Позволяет эмитентам выполнять дробление или выплату дивидендов с помощью простого множителя, который автоматически обновляет балансы, отображаемые в кошельках пользователей.
  • Настраиваемая пауза (Pausable Config): Предоставляет «аварийный выключатель» для заморозки переводов токенов во время инцидентов или регуляторных событий.
  • Постоянный делегат (Permanent Delegate): Позволяет уполномоченной стороне передавать или сжигать токены для выполнения юридических предписаний.
  • Хук передачи (Transfer Hook): Может использоваться для принудительного применения списков разрешений/запретов во время передачи, гарантируя, что только подходящие кошельки могут взаимодействовать с токеном.
  • Конфиденциальные балансы (Confidential Balances): Открывает путь для транзакций, сохраняющих конфиденциальность, которые остаются проверяемыми.

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


Шаблоны для разработчиков: Правильная интеграция xStocks

AMM и агрегаторы

  • Учитывайте состояния паузы: Если выпуск токена приостановлен, немедленно остановите свопы и операции LP и четко уведомите пользователей.
  • Используйте кривые, защищенные оракулами: Внедряйте кривые ценообразования, защищенные надежными оракулами, для управления волатильностью, особенно в часы закрытия базовой фондовой биржи. Эффективно управляйте проскальзыванием в эти нерабочие часы.
  • Показывайте происхождение ликвидности: Четко указывайте пользователям, откуда поступает ликвидность, будь то DEX, CEX или своп кошелька.

Протоколы кредитования и заимствования

  • Отслеживайте корпоративные действия: Используйте оракулы NAV эмитента или площадки и отслеживайте обновления Scaled UI Amount, чтобы избежать незаметного изменения стоимости залога после дробления акций или выплаты дивидендов.
  • Определите разумные дисконты: Установите соответствующие дисконты по залогу, учитывающие рыночное воздействие в нерабочие часы и различную ликвидность разных тикеров акций. Эти параметры риска отличаются от параметров для стейблкоинов.

Кошельки и портфельные приложения

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

Структурированные продукты

  • Создавайте новые инструменты: Комбинируйте xStocks с деривативами, такими как бессрочные контракты или опционы, для создания хеджированных корзин или структурированных доходных нот.
  • Будьте ясны в своей документации: Убедитесь, что ваша документация четко описывает юридическую природу базового актива (сертификата/трекера) и то, как обрабатываются корпоративные действия, такие как дивиденды.

Комплаенс, риски и проверка реальности

Ограничение по юрисдикции

Доступность xStocks геоограничена. Они не предлагаются лицам из США и недоступны в ряде других крупных юрисдикций. Ваше приложение не должно направлять неприемлемых пользователей в процессы, которые они не могут законно завершить.

Понимание инвесторами

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

Различия моделей

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


Мультичейн-контекст и центральная роль Solana

Хотя xStocks изначально появились на Solana, они расширились на другие чейны для удовлетворения спроса пользователей. Для разработчиков это создает проблемы, связанные с кроссчейн-UX и обеспечением единообразной семантики комплаенса для различных стандартов токенов (например, SPL против ERC-20). Тем не менее, субсекундная финализация Solana и нативные расширения токенов делают ее ведущей площадкой для ончейн-акций.


Чек-лист разработчика

  • Интроспекция токена: Считывайте полный набор расширений выпуска (указатель метаданных, пауза, постоянный делегат и т. д.) и подписывайтесь на события паузы для безопасного отказа.
  • Цена и действия: Получайте цены от надежных оракулов и отслеживайте обновления scaled-amount для корректной обработки дивидендов и дробления.
  • Ясность UX: Четко отображайте требования к участию и ограничения прав (например, отсутствие голосования). Ссылайтесь на официальную документацию эмитента в вашем приложении.
  • Лимиты риска: Применяйте соответствующие дисконты LTV, внедряйте меры защиты ликвидности в нерабочие часы и создавайте автоматические выключатели, привязанные к состоянию паузы выпуска.
  • Соответствие комплаенсу: Если и когда хуки передачи включены, убедитесь, что ваш протокол применяет списки разрешений/запретов на уровне передачи. До этого момента ограничивайте пользовательские потоки на уровне приложения.

Почему это важно сейчас

Ранний интерес к xStocks демонстрирует подлинный спрос, с широким листингом на биржах, немедленными интеграциями DeFi и измеримыми ончейн-объемами. Хотя это все еще крошечная часть мирового рынка акций объемом в 120 триллионов долларов, сигнал для разработчиков ясен: примитивы здесь, инфраструктура готова, и поле для деятельности широко открыто.

Кастодиальное хранение цифровых активов для безопасного исполнения сделок с низкой задержкой в масштабе

· 11 мин чтения
Dora Noda
Software Engineer

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


Краткий обзор

Хранение и трейдинг больше не могут существовать в разных мирах. На современных рынках цифровых активов безопасное хранение клиентских активов — это лишь половина дела. Если вы не можете исполнять сделки за миллисекунды при изменении цен, вы теряете доходность и подвергаете клиентов неоправданным рискам, таким как максимальная извлекаемая стоимость (MEV), отказы контрагентов и операционные заторы. Современный стек кастодиального хранения и исполнения должен сочетать передовую безопасность с высокопроизводительной инженерией. Это означает интеграцию таких технологий, как многосторонние вычисления (MPC) и аппаратные модули безопасности (HSM) для подписания, использование механизмов политик и приватной маршрутизации транзакций для предотвращения опережающих сделок (front-running), а также использование инфраструктуры в режиме active/active с внебиржевыми расчетами для снижения рисков площадок и повышения эффективности капитала. Важно, что комплаенс не может быть надстройкой; такие функции, как потоки данных Travel Rule, неизменяемые журналы аудита и контроли, соответствующие стандартам вроде SOC 2, должны быть встроены непосредственно в конвейер транзакций.


Почему «скорость хранения» важна сейчас

Исторически кастодианы цифровых активов оптимизировались для одной основной цели: не потерять ключи. Хотя это остается фундаментальным требованием, запросы эволюционировали. Сегодня лучшее исполнение и целостность рынка стали столь же обязательными. Когда ваши сделки проходят через публичные мемпулы, искушенные участники могут видеть их, изменять их порядок или проводить «сендвич-атаки», чтобы извлечь прибыль за ваш счет. Это MEV в действии, и это напрямую влияет на качество исполнения. Скрытие конфиденциальных потоков ордеров от публичного просмотра с помощью приватных реле транзакций — мощный способ снизить это влияние.

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

Регуляторы также устраняют пробелы. Внедрение правила Travel Rule Группы разработки финансовых мер борьбы с отмыванием денег (FATF) и рекомендации таких органов, как IOSCO и Совет по финансовой стабильности, подталкивают рынки цифровых активов к принципу «те же риски — те же правила». Это означает, что кастодиальные платформы должны с самого начала строиться с учетом комплаенс-потоков данных и проверяемых механизмов контроля.


Цели проектирования (Как выглядит «хороший» результат)

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

  • Задержка, которую можно планировать: Каждая миллисекунда от намерения клиента до трансляции в сеть должна измеряться, управляться и контролироваться с соблюдением строгих целевых уровней обслуживания (SLO).
  • Исполнение, устойчивое к MEV: Конфиденциальные ордера должны по умолчанию маршрутизироваться через приватные каналы. Попадание в публичный мемпул должно быть осознанным выбором, а не неизбежностью.
  • Ключевой материал с реальными гарантиями: Закрытые ключи никогда не должны покидать свои защищенные границы, независимо от того, распределены ли они по сегментам MPC, хранятся в HSM или изолированы в доверенных средах исполнения (TEE). Ротация ключей, обеспечение кворума и надежные процедуры восстановления являются обязательными условиями.
  • Надежность в режиме active/active: Система должна быть устойчивой к сбоям. Это требует резервирования в нескольких регионах и у нескольких провайдеров как для RPC-узлов, так и для подписантов, дополненного автоматическими прерывателями (circuit breakers) и аварийными выключателями на случай инцидентов на площадках или в сети.
  • Compliance-by-construction (Соответствие по построению): Комплаенс не может быть второстепенной задачей. Архитектура должна иметь встроенные инструменты для данных Travel Rule, проверок AML/KYT и неизменяемых журналов аудита, при этом все средства контроля должны напрямую соответствовать признанным стандартам, таким как SOC 2 Trust Services Criteria.

Эталонная архитектура

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

graph LR A[Клиент / Приложение] --> B[API намерений] B --> C[Движок политик и рисков] C --> D[Оркестратор подписантов] C --> E[Сервисы комплаенса - Travel Rule, KYT, белые списки]

subgraph "Подписание" D --> S1[MPC-кластер - t-of-n] D --> S2[HSM] D --> S3[TEE - аттестовано] D --> S4[Управление ключами - стандарт FIPS] end

D --> R[Маршрутизатор исполнения] R --> PR[Приватные реле транзакций / Билдеры] R --> P1[Основной RPC] R --> P2[Резервный RPC] P1 --> N[Сеть / Валидаторы] P2 --> N

subgraph "Наблюдаемость" O1[Подписки на мемпул и блоки] O2[Пост-трейд сверка] O3[Неизменяемый лог аудита / SIEM / Отчетность] end

N --> O1 R --> O2 D --> O3 C --> O3

  • Движок политик и рисков является центральным привратником для каждой инструкции. Он оценивает всё — полезную нагрузку Travel Rule, лимиты скорости, оценки рисков адресов и требования к кворуму подписантов — перед доступом к любому ключевому материалу.
  • Оркестратор подписантов интеллектуально направляет запросы на подпись в наиболее подходящую плоскость управления для конкретного актива и политики. Это может быть:
    • MPC (Multi-Party Computation) с использованием схем пороговой подписи (таких как t-of-n ECDSA/EdDSA) для распределения доверия между несколькими сторонами или устройствами.
    • HSM (Hardware Security Modules) для аппаратного хранения ключей с детерминированными политиками резервного копирования и ротации.
    • Trusted Execution Environments (например, AWS Nitro Enclaves) для изоляции кода подписания и привязки ключей непосредственно к аттестованному, проверенному программному обеспечению.
  • Маршрутизатор исполнения отправляет транзакции по оптимальному пути. Он отдает предпочтение приватной отправке транзакций для крупных или чувствительных к информации ордеров, чтобы избежать опережающих сделок. Он переключается на публичную отправку при необходимости, используя отказоустойчивость RPC с несколькими провайдерами для поддержания высокой доступности даже во время перебоев в работе сети.
  • Слой наблюдаемости обеспечивает представление о состоянии системы в реальном времени. Он отслеживает мемпул и новые блоки через подписки, сверяет исполненные сделки с внутренними записями и фиксирует неизменяемые записи аудита для каждого решения, подписи и трансляции.

Компоненты безопасности (и почему они важны)

  • Пороговые подписи (MPC): Эта технология распределяет контроль над закрытым ключом таким образом, что ни одна машина — или человек — не может в одностороннем порядке переместить средства. Современные протоколы MPC позволяют реализовать быстрое и защищенное от вредоносных действий подписание, которое подходит для бюджетов задержек в промышленной эксплуатации.
  • HSM и соответствие стандартам FIPS: HSM обеспечивают защиту ключей с помощью аппаратного обеспечения с защитой от вскрытия и задокументированных политик безопасности. Соответствие таким стандартам, как FIPS 140-3 и NIST SP 800-57, предоставляет проверяемые и общепринятые гарантии безопасности.
  • Аттестованные TEE: Доверенные среды исполнения (Trusted Execution Environments) привязывают ключи к конкретному, верифицированному коду, работающему в изолированных анклавах. Используя службу управления ключами (KMS), вы можете создавать политики, которые передают ключевой материал только этим аттестованным рабочим нагрузкам, гарантируя, что подписывать может только одобренный код.
  • Приватные реле для защиты от MEV: Эти сервисы позволяют отправлять конфиденциальные транзакции напрямую билдерам блоков или валидаторам, минуя публичный мемпул. Это значительно снижает риск фронтраннинга и других форм MEV.
  • Внебиржевые расчеты (Off-Exchange Settlement): Эта модель позволяет хранить залог в сегрегированном хранилище, одновременно торгуя на централизованных площадках. Это ограничивает риск контрагента, ускоряет взаимозачет и высвобождает капитал.
  • Контроли, сопоставленные с SOC 2 / ISO: Документирование и тестирование операционных контролей на соответствие признанным фреймворкам позволяет клиентам, аудиторам и партнерам доверять вашей безопасности и комплаенсу, а также независимо проверять их.

Стратегия минимизации задержек: куда уходят миллисекунды

Для достижения низкого времени исполнения транзакций необходимо оптимизировать каждый этап их жизненного цикла:

  • Интент → Решение по политике: Держите логику оценки политик «горячей» в оперативной памяти. Кэшируйте данные KYT (Know-Your-Transaction) и белых списков с короткими ограниченными значениями времени жизни (TTL) и, по возможности, заранее вычисляйте кворумы подписантов.
  • Подписание: Используйте постоянные сессии MPC и дескрипторы ключей HSM, чтобы избежать задержек на холодный старт. Для TEE закрепляйте анклавы, прогревайте пути аттестации и повторно используйте сессионные ключи там, где это безопасно.
  • Трансляция: Отдавайте предпочтение постоянным соединениям WebSocket с RPC-узлами вместо HTTP. Размещайте свои сервисы исполнения в тех же регионах, где находятся ваши основные RPC-провайдеры. При скачках задержки делайте идемпотентные повторные попытки и дублируйте трансляцию через нескольких провайдеров.
  • Подтверждение: Вместо постоянного опроса статуса транзакции подпишитесь на квитанции (receipts) и события напрямую из сети. Направляйте эти изменения состояния в конвейер сверки для немедленной обратной связи с пользователем и внутреннего учета.

Установите строгие SLO для каждого этапа (например, проверка политики < 20 мс, подписание < 50–100 мс, трансляция < 50 мс при нормальной нагрузке) и обеспечивайте их соблюдение с помощью бюджетов ошибок и автоматического переключения при деградации задержек p95 или p99.


Риск и комплаенс на этапе проектирования

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

  • Оркестрация Travel Rule: Генерируйте и проверяйте данные отправителя и получателя в режиме реального времени при каждой инструкции по переводу. Автоматически блокируйте или перенаправляйте транзакции с участием неизвестных поставщиков услуг виртуальных активов (VASP) и регистрируйте криптографические подтверждения каждого обмена данными для целей аудита.
  • Риск адресов и белые списки: Интегрируйте ончейн-аналитику и списки санкционных проверок напрямую в механизм политик. Применяйте принцип «запрет по умолчанию», когда переводы разрешены только на адреса из белых списков или в рамках конкретных исключений из политик.
  • Неизменяемый аудит: Хешируйте каждый запрос, одобрение, подпись и трансляцию в журнал, работающий только на добавление. Это создает защищенный от несанкционированного доступа аудиторский след, который можно передавать в SIEM для обнаружения угроз в реальном времени и предоставлять аудиторам для тестирования контролей.
  • Структура контроля: Сопоставьте каждый технический и операционный контроль с критериями доверия SOC 2 (безопасность, доступность, целостность обработки, конфиденциальность и приватность) и внедрите программу непрерывного тестирования и валидации.

Внебиржевые расчеты: безопасное взаимодействие с площадками

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

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


Контрольный список (скопируйте в свой регламент)

  • Кастодиальное хранение ключей
    • Использование MPC с порогом t-of-n в независимых доменах доверия (например, мультиоблако, локальные серверы, HSM).
    • Использование модулей, прошедших валидацию FIPS, где это возможно; наличие планов ежеквартальной ротации ключей и перевыпуска ключей в случае инцидентов.
  • Политики и утверждения
    • Внедрение динамического механизма политик с лимитами оборота, поведенческой эвристикой и ограничениями по рабочему времени.
    • Требование подтверждения по принципу «четырех глаз» для высокорискованных операций.
    • Применение белых списков адресов и проверок Travel Rule перед любой операцией подписания.
  • Усиление исполнения
    • Использование приватных реле транзакций по умолчанию для крупных или чувствительных ордеров.
    • Использование двух RPC-провайдеров с балансировкой на основе их состояния и надежной защитой от повторного воспроизведения.
  • Мониторинг и реагирование
    • Внедрение обнаружения аномалий в режиме реального времени для частоты интентов, отклонений цен на газ и неудачных включений транзакций.
    • Наличие функции экстренного отключения (kill-switch) одним кликом для заморозки всех подписантов для конкретного актива или площадки.
  • Комплаенс и аудит
    • Ведение неизменяемого журнала событий для всех действий в системе.
    • Проведение непрерывного тестирования контролей в соответствии с SOC 2.
    • Обеспечение надежного хранения всех доказательств соблюдения Travel Rule.

Примечания по внедрению

  • Люди и процессы превыше всего: Технологии не могут исправить неопределенные политики авторизации или неясную ответственность за дежурство (on-call). Четко определите, кто уполномочен изменять политику, обновлять код подписанта (signer code), проводить ротацию ключей и одобрять исключения.
  • Минимизируйте сложность там, где это возможно: Каждая новая интеграция блокчейна, моста или площадки (venue) добавляет нелинейный операционный риск. Добавляйте их обдуманно, с четким тестовым покрытием, мониторингом и планами отката.
  • Тестируйте как злоумышленник: Регулярно проводите учения по хаос-инжинирингу. Симулируйте потерю подписанта, сбои аттестации анклава, зависание мемпулов, ограничение API площадок и некорректные данные Travel Rule, чтобы убедиться в устойчивости вашей системы.
  • Докажите это: Отслеживайте KPI, которые действительно важны для ваших клиентов:
    • Время до трансляции (time-to-broadcast) и время до первого подтверждения (p95/p99).
    • Процент транзакций, отправленных через MEV-безопасные маршруты, по сравнению с публичным мемпулом.
    • Использование площадок и повышение эффективности обеспечения за счет использования внебиржевых расчетов (off-exchange settlement).
    • Метрики эффективности контроля, такие как процент переводов с полными данными Travel Rule и скорость закрытия результатов аудита.

Итог

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

Кратковременное хранение, долгосрочное соответствие: Руководство для основателей криптоплатежных сервисов

· 7 мин чтения
Dora Noda
Software Engineer

Если вы создаете платформу для криптоплатежей, возможно, вы говорили себе: «Моя платформа касается средств клиентов всего на несколько секунд. Это ведь не считается хранением, верно?» Это опасное предположение. Для финансовых регуляторов по всему миру даже кратковременный контроль над средствами клиентов делает вас финансовым посредником. Это краткое касание — даже на несколько секунд — влечет за собой долгосрочное бремя соблюдения требований. Для основателей понимание сути регулирования, а не только технической реализации вашего кода, имеет решающее значение для выживания.

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

1. Почему «всего несколько секунд» по-прежнему запускают правила денежных переводов

Суть проблемы заключается в том, как регуляторы определяют контроль. Сеть по борьбе с финансовыми преступлениями США (FinCEN) недвусмысленна: любой, кто «принимает и передает конвертируемую виртуальную валюту», классифицируется как оператор денежных переводов, независимо от того, как долго хранятся средства.

Этот стандарт был подтвержден в руководстве FinCEN по CVC 2019 года и снова в оценке рисков DeFi 2023 года.

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

  • Федеральная регистрация MSB: Регистрация в качестве предприятия по оказанию денежных услуг (Money Services Business) в Министерстве финансов США.
  • Письменная программа AML: Создание и поддержание комплексной программы по борьбе с отмыванием денег.
  • Подача CTR/SAR: Подача отчетов о валютных операциях (CTR) и отчетов о подозрительной деятельности (SAR).
  • Обмен данными по Правилу путешествий: Обмен информацией об отправителе и получателе для определенных переводов.
  • Постоянная проверка OFAC: Непрерывная проверка пользователей на соответствие санкционным спискам.

2. Смарт-контракты ≠ Иммунитет

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

Целевая группа по финансовым мероприятиям (FATF) ясно заявила об этом в своем целевом обновлении 2023 года, указав, что «маркетинговые термины или самоидентификация как DeFi не являются определяющими» для регуляторного статуса.

Если вы (или мультиподпись, которую вы контролируете) можете выполнять любое из следующих действий, вы являетесь хранителем:

  • Обновить контракт с помощью административного ключа.
  • Приостановить или заморозить средства.
  • Перемещать средства через контракт пакетного расчета.

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

3. Обзор лицензирования

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

РегионТекущий регуляторПрактические трудности
СШАFinCEN + лицензии штатов MTMAДвухуровневая система, дорогостоящие поручительства и аудиты. На данный момент 31 штат принял Закон о модернизации денежных переводов (MTMA).
ЕС (сегодня)Национальные реестры VASPМинимальные требования к капиталу, но права на «паспортизацию» ограничены до полной реализации MiCA.
ЕС (2026)Лицензия MiCA CASPТребование к капиталу в размере €125 тыс. – €150 тыс., но предлагает единый режим «паспортизации» для всех 27 рынков ЕС.
ВеликобританияРеестр криптоактивов FCAТребует полной программы AML и интерфейса, соответствующего Правилу путешествий.
Сингапур / ГонконгPSA (MAS) / Постановление VASPТребует разделения хранения и правила 90% холодных кошельков для активов клиентов.

4. Кейс-стади: Путь BoomFi к VASP в Польше

Стратегия BoomFi представляет собой отличную модель для стартапов, ориентированных на ЕС. Компания зарегистрировалась в Министерстве финансов Польши в ноябре 2023 года, получив регистрацию VASP.

Почему это работает:

  • Быстро и недорого: Процесс утверждения занял менее 60 дней и не имел жесткого минимального порога капитала.
  • Повышает доверие: Регистрация свидетельствует о соблюдении требований и является ключевым требованием для европейских продавцов, которым необходимо работать с зарегистрированным VASP.
  • Плавный переход к MiCA: Эту регистрацию VASP можно обновить до полной лицензии MiCA CASP на месте, сохраняя существующую клиентскую базу.

Этот облегченный подход позволил BoomFi получить ранний доступ к рынку и подтвердить свой продукт, одновременно готовясь к более строгой системе MiCA и будущему выходу на рынок США.

5. Модели снижения рисков для разработчиков

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

Архитектура кошелька

  • Потоки с подписью пользователя и пересылкой через контракт: Используйте такие паттерны, как ERC-4337 Paymasters или Permit2, чтобы гарантировать, что все перемещения средств явно подписаны и инициированы пользователем.
  • Самоуничтожение административных ключей с временной блокировкой: После аудита и развертывания контракта используйте временную блокировку, чтобы навсегда отказаться от административных привилегий, доказывая, что вы больше не имеете контроля.
  • Раздельное хранение с лицензированными партнерами: Для пакетных расчетов сотрудничайте с лицензированным хранителем для агрегации и выплаты средств.

Операционный стек

  • Предтранзакционная проверка: Используйте API-шлюз, который внедряет оценки OFAC и анализа цепочки для проверки адресов до обработки транзакции.
  • Мессенджер Правила путешествий: Для меж-VASP переводов на сумму $1 000 или более интегрируйте решение, такое как TRP или Notabene, для обработки необходимого обмена данными.
  • Сначала KYB, затем KYC: Проверяйте продавца (Know Your Business), прежде чем подключать его пользователей (Know Your Customer).

Последовательность расширения

  1. Европа через VASP: Начните в Европе с национальной регистрации VASP (например, в Польше) или регистрации в FCA Великобритании, чтобы доказать соответствие продукта рынку.
  2. США через партнеров: Пока ожидаются лицензии штатов, выходите на рынок США, сотрудничая с лицензированным банком-спонсором или кастодиальным учреждением.
  3. MiCA CASP: Обновите до лицензии MiCA CASP, чтобы закрепить «паспорт ЕС» для 27 рынков.
  4. Азиатско-Тихоокеанский регион: Получите лицензию в Сингапуре (MAS) или Гонконге (Постановление VASP), если объем и стратегические цели оправдывают дополнительные капиталовложения.

Ключевые выводы

Для каждого основателя в сфере криптоплатежей помните эти основные принципы:

  1. Контроль важнее кода: Регуляторы смотрят на то, кто может перемещать деньги, а не на то, как структурирован код.
  2. Лицензирование — это стратегия: Легкая регистрация VASP в ЕС может открыть двери, пока вы готовитесь к юрисдикциям с более высокими капитальными затратами.
  3. Разрабатывайте с учетом соответствия требованиям с самого начала: Контракты без административных ключей и API, учитывающие санкции, дают вам время и доверие инвесторов.

Стройте так, как будто однажды вас проверят — потому что, если вы перемещаете средства клиентов, вас проверят.