Autor: @JayLovesPotato, Four Pillars
Compilado por: AididiaoJP, Foresight News
Puntos Clave
Los estándares de tokens regulados en EVM no están convergiendo hacia una única norma unificada, sino que se están especializando según sus funciones. Por lo tanto, ERC-1450, ERC-3643 y ERC-7943 no deben verse como estándares en competencia, sino como componentes complementarios que se encargan respectivamente de la emisión, la identidad, la ejecución y la integración.
Nota: En pocas palabras, un estándar de token regulado es: una especificación técnica diseñada específicamente para "tokens regulados". Los tokens ordinarios (como un ERC-20 común) pueden transferirse y poseerse libremente, con pocas o ninguna restricción. Pero un token regulado (Regulated Token) es diferente; suele corresponder a activos del mundo real sujetos a regulación financiera, como valores, participaciones en fondos, bonos, RWA (Activos del Mundo Real), etc., transformando el token de "algo que cualquiera puede transferir libremente" en "algo que cumple con los requisitos regulatorios financieros" mediante reglas técnicas.
Las diferencias clave entre las cadenas no radican en si tienen o no capacidades regulatorias, sino en dónde se implementan y ejecutan estas funciones. EVM conserva un alto grado de flexibilidad a nivel de contrato de activo individual; Solana y las cadenas basadas en Move colocan más funcionalidad en marcos de tokens compartidos; Stellar y XRPL las incorporan directamente en el libro mayor; mientras que Canton y Avalanche L1 las extienden aún más, hasta la capa de operación del mercado y la red.
En el futuro, la competitividad de los estándares de tokens regulados probablemente dependerá más de su flexibilidad para adaptarse a cambios regulatorios que del número de funciones que ofrezcan. Una dirección más pragmática es construir una pila de cumplimiento (compliance stack): estandarizar funciones de ejecución recurrentes como congelación, transferencia forzosa, verificación previa a la transferencia, etc., al mismo tiempo que se desglosan políticas específicas del producto, como proveedores de identidad, reglas jurisdiccionales o límites de tenencia, en módulos reemplazables.
Incluso en el entorno EVM de Ethereum, el más familiar para las instituciones, hay múltiples ERC que abordan necesidades similares para tokens regulados. En general, admiten restricciones de transferencia, comprobaciones de elegibilidad del inversor, congelación, transferencia forzosa y recuperación de activos perdidos. Sin embargo, hay diferencias significativas en las estructuras legales y los permisos operativos que cada estándar asume.
Fuera de EVM, otras cadenas también han incorporado funcionalidades comparables a nivel de programa de token, libro mayor o red, ampliando aún más las rutas de implementación para activos regulados.
Esto refleja, en cierta medida, que los estándares de tokens regulados aún no han formado una estructura clara. La razón más fundamental es que las funciones requeridas por los activos regulados son difíciles de comprimir en una única especificación. ¿Quién mantiene el registro legal de los valores? ¿Qué institución certifica la elegibilidad de los inversores? ¿Cuánto control deben retener los operadores en caso de incidentes? Estas preguntas varían según el producto y la jurisdicción.
Por lo tanto, el mercado se está orientando hacia una arquitectura en la que estas funciones se distribuyen en múltiples capas y se combinan según sea necesario, en lugar de perseguir un estándar único y autosuficiente.
Estándares de Tokens Regulados en EVM
La mayoría de los primeros estándares intentaban replicar directamente las estructuras operativas de las finanzas tradicionales en el contrato del token. Bajo ERC-1450, el Agente de Transferencia Registrado (Registered Transfer Agent) no solo se encarga de la emisión y el reembolso, sino que también ejecuta cada transferencia, prohibiendo a los usuarios comunes llamar a `transfer` y `approve`. Esto aclara quién mantiene el registro legal y quién responde a órdenes judiciales o pérdidas de claves. Sin embargo, al mismo tiempo, se aleja del flujo de activos sin permiso que asumen los DEX y protocolos de préstamo tradicionales.
ERC-3643, por otro lado, dispersa las funciones regulatorias entre el contrato del token, un Registro de Identidad (Identity Registry), un Registro de Emisores Confiables (Trusted Issuers Registry) y módulos de cumplimiento independientes, en lugar de concentrarlas bajo una única autoridad. Las transferencias se validan comparándolas con declaraciones emitidas por entidades confiables, incluyendo estado de KYC, residencia y elegibilidad de inversor calificado; los emisores también pueden agregar reglas como límites en el número de inversores o límites de tenencia a nivel nacional. Conservar la estructura básica de ERC-20 mientras se pueden reemplazar reglas individuales es una ventaja significativa. El costo es la carga operativa de coordinar múltiples contratos, emisores de identidad y roles de administración de privilegios.
El más reciente ERC-7943 toma un camino diferente: no define las políticas regulatorias en sí mismas, sino que expone un conjunto de interfaces genéricas, que incluyen funciones como `canSend`, `canReceive`, `canTransfer`, consultas de saldos congelados y transferencia forzosa. Esto permite que carteras, exchanges, custodios y servicios DeFi interactúen de manera coherente con diferentes activos regulados. En otras palabras, ERC-3643 es una pila para crear tokens regulados, mientras que ERC-7943 se acerca más a una capa de integración que conecta múltiples pilas. La reciente implementación de CMTAT añadiendo soporte para ERC-7943 ilustra además que esta interfaz mínima puede superponerse a estándares de emisión existentes.
ERC-7518 y ERC-8047 abordan necesidades más especializadas. ERC-7518 aplica diferentes clases de acciones, jurisdicciones y condiciones de período de bloqueo a particiones individuales de ERC-1155; ERC-8047 registra el linaje de padre-hijo a medida que los activos fluyen, permitiendo que la ejecución se dirija a flujos de fondos específicos en lugar de a cuentas enteras. El primero permite una distinción más clara de derechos dentro de un solo activo; el segundo permite un seguimiento y ejecución más precisos a posteriori. Es más probable que funcionen como módulos que complementan una pila de cumplimiento más amplia, en lugar de reemplazar un estándar integral como ERC-3643.
¿Dónde colocan las funciones regulatorias otras cadenas?
El enfoque de Solana se caracteriza por colocar funciones de token recurrentes en una capa compartida más baja. Funciones como Transfer Hook, Permanent Delegate y Confidential Transfer se proporcionan a través de la biblioteca genérica Token Extensions, mientras que Solana Attestation Service permite que las aplicaciones reutilicen información fuera de la cadena, como estado de KYC, ubicación geográfica y elegibilidad de inversor. Esto reduce la necesidad de que cada emisor reconstruya y audite independientemente las mismas funciones. Sin embargo, cuando una cartera o protocolo no admite una extensión determinada, la integración aún puede romperse; además, los activos con controles de emisor potentes configurados, como Permanent Delegate, deben ser considerados por las aplicaciones DeFi como una capa adicional de riesgo de contraparte.
Stellar y XRPL exponen la autorización, congelación y recuperación como atributos de los activos nativos del libro mayor. Estos controles se activan de manera coherente en las funciones de transferencia y transacción nativa, por lo que las aplicaciones no necesitan reinterpretar lógica personalizada para cada contrato de token. Stellar está ampliando la conexión entre los activos del libro mayor y el entorno de contratos inteligentes a través de Stellar Asset Contracts; XRPL, construido alrededor de MPT, avanza desde la tenencia con permisos, congelación y recuperación hacia funciones relacionadas con la privacidad. Sin embargo, cuanto más profundamente integradas estén las reglas en el libro mayor, más dependerá su evolución de las actualizaciones de red y el consenso. La configuración de controles también puede restringir más directamente la liquidez y el ámbito de uso de un activo.
Sui y Aptos se sitúan entre el modelo centrado en contratos de EVM y el modelo nativo del libro mayor. Sui registra el estado de lista de rechazo y los permisos de suspensión global de activos regulados en el Currency Registry; Aptos, a través del marco Fungible Asset, congela cuentas mediante TransferRef o, cuando es necesario, omite estas restricciones mediante transferencias privilegiadas. Funciones de ejecución recurrentes como el bloqueo de direcciones y la suspensión de emergencia las proporciona el marco; políticas más complejas, como la clasificación de inversores o límites de tenencia específicos por país, se dejan para módulos Move independientes. En este sentido, su arquitectura se acerca más a la dirección modular hacia la que el propio ecosistema EVM está avanzando.
Canton extiende el ámbito regulatorio desde el token hasta la operación de todo el mercado. CIP-56 no solo estandariza la transferencia de saldos, sino también la divulgación de información a partes específicas, la aprobación del receptor y la entrega contra pago atómica (DvP); Token Standard V2 se está probando en un DevNet independiente previsto para 2026. Este diseño proporciona una mayor coherencia operativa y privacidad, pero también requiere entornos de desarrollo e identidad dedicados. Por lo tanto, no se puede migrar fácilmente la liquidez y las aplicaciones de las cadenas públicas existentes.
Avalanche L1 es mejor entendido como una opción para construir mercados regulatorios en sí mismos, no solo para emitir tokens regulados. Los operadores pueden usar listas blancas para restringir participantes en transacciones y despliegues de contratos, al tiempo que exigen a los validadores que cumplan condiciones de KYC, AML o licencias. Esta pila también puede conectar proveedores de identidad como Jumio y Keyring a txAllowlist, siendo muy adecuada para exchanges o redes de pago exclusivos para instituciones. El costo es a nivel operativo: validadores, actualizaciones, puentes entre cadenas y liquidez deben gestionarse de forma independiente, con un coste y un nivel de fragmentación mucho mayores que emitir un solo token en una red EVM existente.
Separar las funciones de ejecución genéricas de las políticas regulatorias
En conjunto, estos caminos muestran que ambos extremos tienen limitaciones evidentes: ya sea incrustar toda la pila regulatoria en la red o dejar todas las funciones a un único ERC. Las funciones de ejecución genéricas que aparecen de forma recurrente en la mayoría de los activos regulados —verificación previa a la transferencia, congelación, transferencia forzosa, suspensión de emergencia, así como metadatos que divulguen los permisos de administración y sus riesgos asociados— se ubican mejor cerca del marco del token, del libro mayor o de una interfaz mínima como ERC-7943. Esto reduce las diferencias de implementación y los costes de auditoría entre emisores, al tiempo que permite que carteras, exchanges y custodios identifiquen de manera coherente la estructura de control de un activo.
Por el contrario, decisiones sobre en qué proveedores de identidad confiar, qué jurisdicciones permitir, cómo calcular límites de tenencia y períodos de bloqueo según niveles de inversor, quién puede ejecutar órdenes legales —estas son más adecuadas para dejarlas a ERC específicos del activo o módulos independientes. Estas reglas varían según el producto y la jurisdicción, y deben actualizarse con los cambios legales. Si se codifican rígidamente en las reglas base de la red, no solo ralentizarán las actualizaciones, sino que podrían convertir las opciones de política de mercados financieros específicos en la configuración predeterminada para cadenas genéricas.
En otras palabras, es más probable que el mercado de tokens regulados evolucione en forma de una pila de cumplimiento, en lugar de converger hacia un único estándar. En este modelo, reglas reemplazables de identidad, jurisdicción y específicas del producto se construirían sobre funciones de ejecución genéricas. Ethereum y el ecosistema EVM en general aún tienen ventajas en flexibilidad de políticas y acceso a la liquidez existente; las cadenas con funciones nativas en el libro mayor son más fuertes en coherencia de ejecución y simplicidad operativa; mientras que redes dedicadas como Canton destacan más en privacidad y flujos de trabajo institucionales.
Por lo tanto, la adopción probablemente no esté determinada por qué estándar tenga la lista de funciones más larga. Lo más importante es si las políticas regulatorias pueden cambiar sin necesidad de reemitir el activo, ni obligar a carteras, exchanges y custodios a reconstruir sus integraciones desde cero. Otra prueba clave es: ¿pueden los participantes externos identificar, evaluar y gestionar claramente los potentes controles incorporados en un activo?
