Estándar de tokens regulados en EVM: ERC-1450 se encarga de la emisión, ERC-3643 de la conformidad de la identidad y ERC-7943 de la integración.
Escrito por: @JayLovesPotato, Four Pillars
Compilado por: AididiaoJP, Foresight News
Puntos clave
El estándar de tokens regulados en EVM no ha evolucionado hacia una única especificación unificada; más bien, se ha dividido claramente por funciones. Por eso, ERC-1450, ERC-3643 y ERC-7943 no deberían considerarse estándares en competencia entre sí, sino como componentes complementarios que, respectivamente, se encargan de la emisión, la identidad, la ejecución y la integración.
Nota: en pocas palabras, el estándar de tokens regulados es una especificación técnica diseñada específicamente para “tokens regulados”. Los tokens comunes (por ejemplo, un ERC-20 estándar) se pueden transferir y mantener libremente, con casi ninguna restricción. Pero los tokens regulados (Regulated Token) son diferentes: normalmente corresponden a activos regulados del mundo real, como valores, participaciones de fondos, bonos y RWA (activos del mundo real). Así, el token deja de ser algo que “cualquiera puede transferir sin más” y pasa a regirse por reglas técnicas que “cumplen los requisitos de la regulación financiera”.
Las diferencias clave entre cadenas no radican en si cuentan o no con funciones de regulación, sino en dónde se implementan y ejecutan esas funciones. En EVM, la flexibilidad se mantiene a nivel de contrato por activo; las cadenas Solana y basadas en Move ponen más funcionalidad en marcos compartidos de tokens; Stellar y XRPL incrustan directamente la funcionalidad en el libro mayor; y Canton y Avalanche L1 extienden aún más hacia las capas de operación del mercado y la red.
La competitividad de los estándares de tokens regulados, en el futuro, probablemente dependerá más de qué tan flexibles sean para adaptarse a cambios regulatorios que del número de funciones que incluyan. Un enfoque más pragmático es construir un stack de cumplimiento: estandarizar funciones de ejecución recurrentes como congelación, transferencias forzadas y validación previa a la transferencia, y descomponer políticas específicas del producto —por ejemplo, proveedores de identidad, reglas de jurisdicción y topes de tenencia— en módulos intercambiables.
Incluso dentro del entorno EVM de Ethereum que más conocen las instituciones, hay múltiples ERC que atienden necesidades similares relacionadas con tokens de tipo regulado. En general, admiten límites de transferencias, verificación de elegibilidad de los inversores, congelación, transferencias forzadas y recuperación de activos perdidos. Sin embargo, las estructuras legales asumidas y los permisos operativos que contempla cada estándar difieren de forma significativa.
Más allá de EVM, otras cadenas también incorporan funcionalidades comparables en el nivel de programas de tokens, del libro mayor o de la capa de red, ampliando aún más las rutas de implementación para activos regulados.
Esto refleja, en parte, que aún no se ha formado una estructura clara para los estándares de tokens regulados. La causa más fundamental es que las funciones necesarias para los activos regulados son difíciles de encajar en una única norma. ¿Quién mantiene el registro legal de los valores? ¿Qué institución certifica la elegibilidad de los inversores? ¿Cuánta autoridad de control debe conservar el operador cuando ocurre un incidente? Estas cuestiones varían según el producto y la jurisdicción.
Por lo tanto, el mercado se dirige hacia una arquitectura: estas funciones se distribuyen en múltiples niveles y se combinan según se necesiten, en lugar de buscar un único estándar completamente autosuficiente.
Estándares de tokens regulados en EVM
Los estándares tempranos intentaron en su mayoría copiar directamente la estructura operativa de las finanzas tradicionales en contratos de tokens. En ERC-1450, el agente de transferencias registrado (Registered Transfer Agent) no solo gestiona la emisión y el reembolso, sino que también ejecuta cada transferencia; los usuarios comunes tienen prohibido llamar a transfer y approve. Esto deja claro quién mantiene el registro legal y quién debe responder a órdenes judiciales o a la recuperación de claves perdidas. Pero, al mismo tiempo, se aleja del flujo de activos sin permisos que asumen los DEX y los protocolos de préstamos tradicionales.
ERC-3643 distribuye las funciones de regulación en contratos de token, en un Identity Registry, en un Trusted Issuers Registry y en módulos independientes de cumplimiento, en lugar de concentrarlo bajo una única autoridad. Las transferencias se verifican contra declaraciones emitidas por entidades confiables, incluidas información de estado KYC, residencia y elegibilidad de inversor calificado; el emisor también puede añadir reglas como el número de inversores y topes de tenencia a nivel nacional. Manteniendo la estructura básica de ERC-20, poder sustituir reglas individuales es una ventaja significativa. El costo es la carga operativa derivada de coordinar múltiples contratos, emisores de identidad y roles de gestión privilegiada.
ERC-7943, más cercano en el tiempo, sigue un camino diferente: no define la política regulatoria en sí, sino que expone un conjunto de interfaces generales, incluyendo canSend, canReceive, canTransfer, consultas de saldo congelado y funciones de transferencia forzada. Esto permite que carteras, exchanges, custodios y servicios DeFi interactúen con diferentes activos regulados de manera consistente. En otras palabras, ERC-3643 es un stack para crear tokens regulados, mientras que ERC-7943 se parece más a una capa de integración que conecta varios stacks. Recientemente, CMTAT ha implementado soporte para ERC-7943, lo que refuerza la idea de que esta interfaz mínima se puede superponer sobre los estándares de emisión existentes.
ERC-7518 y ERC-8047 se orientan a necesidades más especializadas. ERC-7518 aplica diferentes categorías de acciones, jurisdicciones y condiciones de periodo de bloqueo en una sola partición ERC-1155; ERC-8047, por su parte, registra la genealogía entre padre e hijo cuando los activos fluyen, para que la ejecución pueda enfocarse en flujos de fondos específicos y no en la cuenta completa. El primero hace que la distinción de derechos dentro de un único activo sea más clara; el segundo permite un seguimiento posterior y una ejecución más precisos. Es más probable que funcionen como módulos complementarios de un stack de cumplimiento más amplio, en lugar de sustituir el estándar integral de ERC-3643.
¿Dónde colocan las otras cadenas las funciones de regulación?
El enfoque de Solana se caracteriza por colocar las funciones de tokens recurrentes en una capa compartida más subyacente. Funciones como Transfer Hook, Permanent Delegate y Confidential Transfer se ofrecen mediante la biblioteca Token Extensions genérica, y Solana Attestation Service permite que las aplicaciones reutilicen información fuera de la cadena, como el estado KYC, la ubicación geográfica y la elegibilidad del inversor. Esto reduce la necesidad de que cada emisor reconstruya y audite de forma independiente las mismas funciones. Sin embargo, cuando una cartera o un protocolo no admite una extensión concreta, la integración aún podría romperse; además, para los activos configurados con controles fuertes de emisores como Permanent Delegate, las aplicaciones DeFi deben tratarlos como una capa adicional de riesgo de contraparte.
Stellar y XRPL exponen autorizaciones, congelaciones y recuperación como atributos nativos de los activos en el libro mayor. Estos controles se aplican de forma coherente tanto en la transferencia como en la funcionalidad nativa de transacción, por lo que las aplicaciones no necesitan reinterpretar una lógica personalizada para cada contrato de token. Stellar está ampliando la conexión entre activos del libro mayor y el entorno de contratos inteligentes mediante Stellar Asset Contracts; XRPL, en cambio, se construye alrededor de MPT y avanza desde la tenencia con licencia, congelación y recuperación hacia funciones relacionadas con privacidad. Sin embargo, cuanto más se incrustan las reglas en el libro mayor, más depende su evolución de actualizaciones de red y consenso. La configuración de control también puede restringir de forma más directa la liquidez y el alcance de uso de los activos.
Sui y Aptos están entre el modelo centrado en contratos de EVM y el modelo nativo del libro mayor. Sui registra en Currency Registry el estado de listas de rechazo de activos regulados y los permisos globales de pausa; Aptos congela cuentas mediante el marco Fungible Asset con TransferRef, o cuando es necesario, elude esas restricciones mediante transferencias privilegiadas. Funciones recurrentes de ejecución como bloqueo de direcciones y pausas de emergencia las proporciona el marco; políticas más complejas, como clasificación de inversores y topes de tenencia específicos por país, se dejan para módulos Move independientes. En este punto, su arquitectura se parece más a la dirección modular hacia la que el propio ecosistema EVM está avanzando.
Canton amplía el alcance de la regulación desde el token hasta la operación de todo el mercado. CIP-56 no solo estandariza transferencias de saldo, sino que también incluye divulgación de información de partes específicas, aprobación del destinatario y entrega contra pago atómica (DvP); Token Standard V2 se está probando en el DevNet independiente de 2026. Este diseño ofrece una mayor consistencia operativa y privacidad, pero también requiere identidades dedicadas y entornos de desarrollo. Por ello, la liquidez y las aplicaciones existentes en cadenas públicas no pueden migrarse simplemente.
Avalanche L1 es más adecuado para interpretarse como una opción para construir el propio mercado regulado, y no solo para emitir tokens regulados. Los operadores pueden usar listas blancas para limitar a los participantes en la negociación y a quienes despliegan contratos, al mismo tiempo que exigen que los validadores cumplan condiciones de KYC, AML o licenciamiento. Este stack también puede conectar proveedores de identidad como Jumio y Keyring al txAllowlist, algo muy adecuado para exchanges o redes de pago exclusivamente institucionales. El costo está en la capa operativa: validadores, actualizaciones, puentes entre cadenas y liquidez deben gestionarse de forma independiente; el costo y la fragmentación son mucho mayores que al emitir un único token en redes EVM existentes.
Separar las funciones de ejecución genéricas de las políticas de regulación
En conjunto, estas rutas muestran que ambos extremos tienen limitaciones claras: ya sea incrustar todo el stack regulado dentro de la red, o dejar todas las funcionalidades a un único ERC. Las funciones de ejecución genéricas que probablemente se repitan en la mayoría de los activos regulados —validación antes de transferir, congelación, transferencias forzadas, pausas de emergencia y metadatos que revelan permisos de gestión y riesgos asociados— se colocan mejor en un punto cercano al marco del token, al libro mayor o en una interfaz mínima como ERC-7943. Así se reducen las diferencias de implementación entre emisores y los costos de auditoría, y a la vez permite que carteras, exchanges y custodios identifiquen de forma uniforme la estructura de control del activo.
En cambio, decisiones como a qué proveedores de identidad confiar, qué jurisdicciones permitir, cómo calcular el tope de tenencia y el periodo de bloqueo del nivel de inversor, y quién puede ejecutar órdenes legales, encajan mejor en un ERC específico del activo o en módulos independientes. Estas reglas varían según el producto y la jurisdicción, y deben actualizarse conforme cambie la legislación. Si se codifican de forma rígida en reglas base de la red, no solo se ralentizarían las actualizaciones, sino que también se convertirían en la configuración predeterminada de la cadena para políticas de un mercado financiero específico.
Dicho de otro modo, es más probable que el mercado de tokens regulados evolucione en forma de stacks de cumplimiento, en lugar de converger hacia un único estándar. En este modelo, identidades intercambiables, jurisdicciones y reglas específicas del producto se construirán sobre funciones de ejecución genéricas. Ethereum y, en general, el ecosistema EVM aún conservan ventajas en flexibilidad de políticas y acceso a liquidez existente; las cadenas nativas del libro mayor son más fuertes en consistencia de ejecución y simplicidad operativa; y redes especializadas como Canton destacan especialmente en privacidad y flujos de trabajo institucionales.
Por lo tanto, la adopción no es probable que dependa de qué lista de funciones de un estándar sea la más larga. Lo más importante es si la política regulatoria puede cambiar sin necesidad de volver a emitir activos y sin obligar a que carteras, exchanges y custodios reconstruyan desde cero la integración. Otra prueba clave es: si los participantes externos pueden identificar con claridad, evaluar y gestionar el poderoso control incrustado en los activos.