Автор: @JayLovesPotato, Four Pillars
Перевод: AididiaoJP, Foresight News
Ключевые тезисы
Стандарты токенизированных активов в EVM не движутся к единой унифицированной спецификации, а скорее демонстрируют четкое разделение функций по назначению. Поэтому ERC-1450, ERC-3643 и ERC-7943 не следует рассматривать как конкурирующие стандарты, а как взаимодополняющие компоненты, отвечающие соответственно за эмиссию, идентификацию, исполнение и интеграцию.
Примечание: Стандарты токенизированных активов — это, говоря простым языком, технические спецификации, разработанные специально для «регулируемых токенов». Обычные токены (например, стандартные ERC-20) можно свободно передавать и владеть ими практически без ограничений. Но токенизированные активы (Regulated Token) иные — они обычно представляют собой регулируемые активы реального мира, такие как ценные бумаги, доли фондов, облигации, RWA (реальные мировые активы). Это технические правила, превращающие токен из «того, что можно свободно передавать кому угодно» в инструмент, соответствующий требованиям финансового регулирования.
Ключевое различие между блокчейнами заключается не в наличии или отсутствии функций соответствия, а в том, где эти функции реализованы и исполняются. EVM сохраняет высокую гибкость на уровне контракта отдельного актива; Solana и блокчейны на основе Move размещают больше функций в общих фреймворках токенов; Stellar и XRPL встраивают их непосредственно в реестр; Canton и Avalanche L1 идут еще дальше, расширяя их до уровня рынков и операций сети.
В будущем конкурентоспособность стандартов токенизированных активов, вероятно, будет зависеть больше от их гибкости в адаптации к изменениям в регулировании, чем от количества функций. Более практичным направлением является построение стека соответствия: стандартизация часто повторяющихся исполнительных функций, таких как замораживание, принудительный перевод, проверка перед переводом, при одновременном разделении специфичных для продукта политик (поставщики идентификации, правила юрисдикций, лимиты владения и т.д.) на заменяемые модули.
Даже в среде Ethereum EVM, наиболее знакомой институциональным игрокам, существует несколько ERC, решающих схожие задачи для токенизированных активов. Они обычно поддерживают ограничения на переводы, проверку квалификации инвесторов, заморозку, принудительный перевод и восстановление утерянных активов. Однако предполагаемые юридические структуры и операционные полномочия значительно различаются между стандартами.
За пределами EVM другие блокчейны также добавляют сравнимые функциональности на уровне программ токенов, реестра или сети, что расширяет пути реализации регулируемых активов.
Это в определенной степени отражает то, что стандарты токенизированных активов еще не обрели четкой структуры. Более фундаментальная причина заключается в том, что функции, требуемые для регулируемых активов, трудно уместить в единую спецификацию. Кто ведет юридический учет ценных бумаг, какое учреждение сертифицирует инвесторов, сколько контроля следует оставлять оператору в случае инцидента — эти вопросы различаются в зависимости от продукта и юрисдикции.
Таким образом, рынок движется к архитектуре, где эти функции распределены по нескольким уровням и комбинируются по мере необходимости, вместо того чтобы стремиться к единому самодостаточному стандарту.
Стандарты токенизированных активов в EVM
Ранние стандарты в основном пытались напрямую скопировать операционные структуры традиционных финансов в контракт токена. В рамках ERC-1450 зарегистрированный агент по переводу (Registered Transfer Agent) не только отвечает за эмиссию и погашение, но и исполняет каждую операцию перевода, в то время как обычным пользователям запрещено вызывать функции transfer и approve. Это четко определяет, кто ведет юридический учет и кто отвечает на судебные предписания или случаи утери ключей. Однако это одновременно отдаляет такие активы от предполагаемой традиционными DEX и кредитными протоколами безразрешительной передачи активов.
ERC-3643 распределяет функции соответствия между контрактом токена, реестром идентификации (Identity Registry), реестром доверенных эмитентов (Trusted Issuers Registry) и независимыми модулями соответствия, вместо того чтобы концентрировать их в едином органе власти. Переводы проверяются на соответствие утверждениям, подписанным доверенными организациями, включая статус KYC, место проживания и квалификацию инвестора; эмитент также может добавлять правила, такие как ограничение числа инвесторов или национальные лимиты владения. Сохранение базовой структуры ERC-20 с возможностью замены отдельных правил является значительным преимуществом. Ценой становится операционная нагрузка из-за необходимости координации нескольких контрактов, поставщиков идентификации и ролей с особыми полномочиями.
Более новый ERC-7943 пошел другим путем: он не определяет политики соответствия как таковые, а предоставляет набор универсальных интерфейсов, включая canSend, canReceive, canTransfer, функции запроса замороженного баланса и принудительного перевода. Это позволяет кошелькам, биржам, кастодианам и сервисам DeFi взаимодействовать с различными регулируемыми активами единообразным образом. Другими словами, ERC-3643 — это стек для создания токенизированных активов, а ERC-7943 больше похож на слой интеграции, соединяющий несколько стеков. Недавнее добавление поддержки ERC-7943 в реализацию CMTAT дополнительно показывает, что такой минималистичный интерфейс может быть наложен на существующие стандарты эмиссии.
ERC-7518 и ERC-8047 нацелены на более специфичные потребности. ERC-7518 применяет условия для различных классов акций, юрисдикций и периодов блокировки к отдельным разделам ERC-1155; ERC-8047 фиксирует происхождение активов при их движении, позволяя применять меры к конкретным потокам средств, а не ко всему счету. Первый делает более четким разделение прав внутри единого актива; второй позволяет более точно отслеживать и применять меры постфактум. Вероятнее всего, они будут использоваться как модули, дополняющие более широкий стек соответствия, а не как всеобъемлющие стандарты, заменяющие ERC-3643.
Где размещают функции соответствия другие блокчейны
Подход Solana характеризуется размещением часто повторяющихся функций токенов на более низком общем уровне. Такие функции, как Transfer Hook, Permanent Delegate и Confidential Transfer, предоставляются через общую библиотеку Token Extensions, а Solana Attestation Service позволяет приложениям повторно использовать информацию извне цепи, такую как статус KYC, геолокация и квалификация инвестора. Это сокращает необходимость для каждого эмитента самостоятельно пересоздавать и аудировать одинаковые функции. Однако интеграция все еще может быть затруднена, если кошелек или протокол не поддерживает конкретное расширение; кроме того, активы с настройками мощного контроля со стороны эмитента, такие как Permanent Delegate, должны рассматриваться DeFi-приложениями как дополнительный уровень контрагентского риска.
Stellar и XRPL представляют атрибуты авторизации, заморозки и возврата как свойства активов, нативных для реестра. Эти элементы контроля применяются единообразно в функциях перевода и нативных транзакций, приложениям не нужно переинтерпретировать пользовательскую логику для каждого контракта токена. Stellar расширяет возможности подключения нативных активов реестра к среде смарт-контрактов через Stellar Asset Contracts; XRPL, строящийся вокруг MPT, движется от разрешенного владения, заморозки и восстановления к функциям, связанным с конфиденциальностью. Однако, чем глубже правила встроены в реестр, тем больше их эволюция зависит от обновлений сети и консенсуса. Настройки контроля также могут более непосредственно ограничивать ликвидность и сферы использования активов.
Sui и Aptos находятся между контрактно-центрированной моделью EVM и моделью с нативными функциями в реестре. Sui фиксирует статус активов в черных списках и глобальные права на приостановку в Currency Registry; Aptos замораживает счета через TransferRef в рамках Fungible Asset или в обход этих ограничений через привилегированный перевод при необходимости. Часто повторяющиеся исполнительные функции, такие как блокировка адресов и экстренная приостановка, предоставляются фреймворком; более сложные политики, такие как классификация инвесторов и национальные лимиты владения, остаются на усмотрение независимых Move-модулей. В этом отношении их архитектура наиболее близка к модульному направлению, в котором движется сама экосистема EVM.
Canton расширяет сферу регулирования от токенов до операций всего рынка. CIP-56 стандартизирует не только перевод балансов, но и раскрытие информации определенным сторонам, одобрение получателя и атомарный расчет «поставка против платежа» (DvP); Token Standard V2 тестируется на независимом DevNet к 2026 году. Такой дизайн обеспечивает большую операционную согласованность и конфиденциальность, но также требует выделенной среды идентификации и разработки. Следовательно, существующая ликвидность и приложения публичных блокчейнов не могут быть просто перенесены сюда.
Avalanche L1 лучше понимать как вариант для построения самих регулируемых рынков, а не только для выпуска токенизированных активов. Оператор может ограничивать участников сделок и развертывателей контрактов с помощью белых списков, одновременно требуя от валидаторов соответствия условиям KYC, AML или наличия лицензий. Этот стек также может подключать таких поставщиков идентификации, как Jumio и Keyring, к txAllowlist, что идеально подходит для бирж или платежных сетей, предназначенных исключительно для институциональных клиентов. Ценой становятся операционные аспекты: валидаторы, обновления, мосты и ликвидность должны управляться независимо, что приводит к значительно более высоким затратам и фрагментации по сравнению с выпуском единичного токена в существующей сети EVM.
Разделение универсальных исполнительных функций и политик соответствия
В совокупности эти пути демонстрируют очевидные ограничения обеих крайностей: будь то встраивание всего стека соответствия в сеть или предоставление всех функций на усмотрение отдельного ERC. Универсальные исполнительные функции, которые регулярно требуются большинству регулируемых активов — проверка перед переводом, заморозка, принудительный перевод, экстренная приостановка, а также метаданные, раскрывающие права управления и связанные с ними риски — лучше размещать ближе к фреймворку токенов, реестру или минималистичному интерфейсу, подобному ERC-7943. Это снизит различия в реализации и затраты на аудит между эмитентами, одновременно позволяя кошелькам, биржам и кастодианам единообразно распознавать структуры контроля активов.
Напротив, решения о том, каким поставщикам идентификации доверять, какие юрисдикции разрешать, как рассчитывать лимиты владения и периоды блокировки для разных классов инвесторов, кто может исполнять юридические предписания — эти решения лучше оставлять на усмотрение специфичных для актива ERC или независимых модулей. Эти правила различаются в зависимости от продукта и юрисдикции и должны обновляться с изменениями в законодательстве. Их жесткое кодирование в базовые правила сети не только замедлит обновления, но и может превратить политические выборы конкретных финансовых рынков в настройки по умолчанию для универсального блокчейна.
Другими словами, рынок токенизированных активов, скорее всего, будет развиваться в форме стека соответствия, а не путем сходимости к единому стандарту. В этой модели заменяемые правила идентификации, юрисдикций и конкретных продуктов будут строиться поверх универсальных исполнительных функций. Ethereum и более широкая экосистема EVM сохраняют преимущество в гибкости политик и доступе к существующей ликвидности; блокчейны с нативными функциями в реестре сильнее в согласованности исполнения и операционной простоте; а специализированные сети, такие как Canton, выделяются в вопросах конфиденциальности и рабочих процессов для институциональных клиентов.
Следовательно, уровень принятия вряд ли будет определяться тем, у какого стандарта длиннее список функций. Более важно то, могут ли политики соответствия изменяться без необходимости перевыпуска активов и без принуждения кошельков, бирж и кастодианов к интеграции с нуля. Другой ключевой критерий: могут ли внешние участники четко идентифицировать, оценивать и управлять мощными элементами контроля, встроенными в актив.
