Tokens de seguridad y cumplimiento en mercados cripto

Los tokens de seguridad son representaciones en blockchain de valores regulados, por lo que su propiedad y transferencia deben seguir las mismas restricciones legales que los instrumentos tradicionales.

"Cumplimiento por código" es el patrón de diseño donde esas restricciones se hacen cumplir de manera determinista en el momento en que ocurre una acción del token, utilizando verificaciones de contratos inteligentes, datos de identidad y controles administrativos.

Puntos Clave

• Un token de seguridad representa un valor o contrato de inversión y está sujeto a las mismas reglas que los instrumentos financieros tradicionales bajo las leyes federales de valores de EE. UU.
• Cumplimiento por códigolos sistemas crypto aplican decisiones de permitir o denegar en el momento de acuñar, transferir, quemar o aprobar, a menudo devolviendo códigos de estado estandarizados en lugar de etiquetas vagas de “KYC’d”.
• Los estándares de restricción a nivel de token se centran en controles programables y controles administrativos como congelar y revocar, mientras que la autorización a nivel de cadena o cuenta determina quién puede incluso tocar el asentamiento.
• Las propuestas de interoperabilidad impulsan el cumplimiento hacia identidades portátiles y objetos de datos para que los mismos reguladosactivopuede ser expuesto a través de múltiples interfaces sin perder la transparencia de restricciones.

Tokens de seguridad y cumplimiento por código

Los activos regulados no se vuelven “menos regulados” porque la tabla de capital sea un smart contract. El documento arquitectónico presentado por Prometheum ante la SEC es explícito en que los valores en blockchain representan un contrato de seguridad o inversión y siguen sujetos a las mismas reglas y regulaciones que los instrumentos financieros tradicionales en los Estados Unidos, lo que significa que las leyes federales de valores aún se aplican. Ese marco es el punto de partida para explicar los tokens de seguridad: el token es un envoltorio alrededor de un ciclo de vida regulado, no un pase libre alrededor de él.

El cumplimiento por código se entiende mejor como un motor de riesgo de lugar. Cada acción que cambia la propiedad o el control se fuerza a través de una puerta que devuelve una decisión de permitir o denegar, idealmente con una razón legible por máquina.

La elección de diseño que importa es dónde vive esa puerta: dentro del contrato del token, dentro de los objetos de datos de identidad compartida y cumplimiento, o dentro de un entorno de liquidación con permiso que solo admite cuentas aprobadas.

Por eso “tokens de seguridad vs utility tokens” no es un debate cosmético sobre metadatos. Un token de utilidad a menudo puede tratar la transferencia como un derecho por defecto. Un token de seguridad generalmente no puede, porque la elegibilidad, la jurisdicción y el estado legal pueden cambiar con el tiempo. Esa es también la razón por la que las discusiones sobre tokenization que se quedan en la capa de marketing pierden el punto operativo.

Cualquiera que busque qué es la tokenización generalmente está buscando la mecánica de convertir un reclamo legal en un estado programable. Los tokens de seguridad son el caso donde ese estado debe ser defendible ante un regulador y funcional para intermediarios como un transfer agent..

Cómo funcionan las restricciones de transferencia en la cadena

ERC-1462 trata el cumplimiento como una verificación determinista que se ejecuta antes de que el token realice cualquier acción irreversible. Agrega funciones de verificación explícitas para las acciones principales que importan: checkTransferAllowed, checkTransferFromAllowed, checkMintAllowed y checkBurnAllowed.

Se espera que los métodos de ERC-20 consulten esas verificaciones al sobrescribir transfer, transferFrom y approve, y luego hagan cumplir el resultado.

El detalle importante es que ERC-1462 no reduce la decisión a un booleano. Las funciones de verificación devuelven códigos de estado estandarizados a través de ERC-1066, con 0x11 significando Permitido y 0x10 significando No permitido, además de espacio para códigos específicos del emisor. Eso suena como una cortesía para desarrolladores hasta que afecta el flujo de trabajo de un usuario.

Un sistema de billetera, corredor o agente de transferencia puede mostrar “no permitido porque falta KYC” frente a “no permitido porque hay un bloqueo de jurisdicción” frente a “fallo fuera de la cadena”, en lugar de un revert genérico que obliga a tickets de soporte y triaje manual.

ERC-1462 también deja espacio para la parte complicada que siempre tienen los mercados regulados: disputas y documentación. La EIP nombra KYC y AML como requisitos e incluye explícitamente la capacidad de bloquear tokens para una cuenta y restringir transferencias debido a una disputa legal.

También define ganchos de documentos opcionales, attachDocument y lookupDocument, que hacen referencia a documentos legales fuera de la cadena por URI y hash de contenido. Esa es la postura de cumplimiento por código en su forma más honesta: aplicación en la cadena más un puente deliberado a la realidad legal fuera de la cadena.

Controles de cumplimiento comunes en estándares de tokens

ERC-1404 es un estándar de token restringido construido en torno a los controles que los emisores y lugares siguen pidiendo cuando intentan ejecutar flujos regulados en rieles públicos. El sitio enfatiza conocer a los titulares de tokens y mantener una lista blanca de direcciones de inversores, que es el significado operativo detrás de un token de lista blancay la idea más amplia de untoken con permisos..

También menciona restricciones complejas que aparecen en hojas de términos y memorandos legales, como bloquear transferencias entre jurisdicciones específicas y hacer cumplir límites máximos de propiedad.

La parte más reveladora es la caja de herramientas administrativa. ERC-1404 enumera características comúnmente implementadas, incluyendo la capacidad de congelar un token, revocar y reasignar, crear múltiples listas y aprobar o rechazar una transacción. No son casos extremos. Son palancas de remediación.

Si más tarde se encuentra que una transferencia viola una restricción, o si unadirecciónse convierte en sancionada, o si llega una orden judicial, un token de seguridad de grado de producción necesita una forma de detener, deshacer o rehacer el estado.

ERC-1404 también describe la separación de roles, con ejemplos como Propietario o Emisor, un Administrador que puede ser un agente de transferencia o un lugar de negociación, y un rol de Inversor que puede enviar y recibir. Ese modelo de rol es donde 'cumplimiento por código' deja de ser un eslogan y se convierte en un sistema operativo.

Alguien tiene que estar autorizado para congelar, revocar y reasignar, y el contrato del token se convierte en el punto de aplicación de esos permisos.

Aquí es también donde los estándares de tokens de seguridad divergen en filosofía. ERC-1462 aboga por una base estrecha que los emisores extienden con su propia lógica. ERC-1404 se inclina hacia un conjunto de herramientas restringido más completo en características. Ambos están tratando de resolver el mismo problema a nivel de pantalla: cuando un usuario hace clic en enviar, el token se liquida o no, y el sistema necesita explicar por qué.

Identidad, custodia y flujos de trabajo regulados

Un contrato de token puede bloquear transferencias, pero no puede incorporar a un humano. Por eso, el cumplimiento por código a menudo abarca identidad, custodia y flujos de trabajo de lugares que giran en torno al token.

La arquitectura de Prometheum es un ejemplo claro de permisos a nivel de cadena o cuenta: describe un modelo de cadena Core y Utility dividido, con actividades reguladas en una cadena Core utilizando un modelo de cuentas con permisos y disponibilidad de modelo abierto en la cadena Utility.

El mecanismo de control no es sutil. Prometheum afirma que las partes que interactúan con su cadena Core deben poder crear una cuenta con un Broker-Dealer y cumplir con los requisitos de debida diligencia y AML/KYC. Eso es KYC en cadena como una elección de diseño del sistema, no solo una casilla de verificación.

Empuja la aplicación hacia la izquierda, de modo que el entorno de liquidación en sí mismo está autorizado antes de que se intente siquiera una transferencia de token.

Prometheum también define un Token de Seguridad Inteligente como un valor registrado en EE. UU. que también puede usarse como un token en aplicaciones distribuidas en blockchain, y describe mecanismos para mover estos tokens entre billeteras 'Maestras' y 'Personales'. El punto es la custodia y el mantenimiento de registros.

La arquitectura describe Billeteras Maestras utilizadas por firmas de compensación para la contabilidad en la cadena Core y Billeteras Personales que se comportan más como billeteras de cadena pública en la cadena Utility. Los servicios de agente de transferencia se describen como el mantenimiento de un registro completo de propiedad al combinar datos de blockchain pública con datos de titulares de cuentas privadas de broker-dealers.

Esta es la comparación clave: las verificaciones a nivel de token intentan hacer que el activo sea portátil a través de entornos, mientras que los entornos de liquidación autorizados intentan hacer que el propio entorno sea el perímetro de cumplimiento. Ambos pueden producir una experiencia de token autorizado. Simplemente colocan la puerta en diferentes lugares.

Interoperabilidad y capas de datos en evolución

El trabajo de interoperabilidad intenta evitar que cada emisor reinvente la misma pila de cumplimiento dentro de cada contrato de token.

El apéndice de interoperabilidad EIP-7208 describe a ERC-1400 como un proveedor de interfaces para emitir y canjear tokens de seguridad, gestionar la propiedad y las restricciones de transferencia, y dar a los titulares de tokens transparencia sobre cómo se comportan subconjuntos de saldos con respecto a restricciones, derechos y obligaciones.

Esa 'transparencia de subconjuntos' es importante porque los tokens regulados a menudo tienen tramos, bloqueos o restricciones específicas de categoría que un solo número de saldo no puede expresar.

El mismo apéndice argumenta que los objetos de datos pueden almacenar y modificar datos en cadena para tokens de seguridad, como información de cumplimiento o detalles de propiedad, y que la lógica de gestión de identidad personalizada puede integrarse al integrarse con estándares de tokens de seguridad.

Este es el cambio arquitectónico: en lugar de codificar cada regla en un contrato de token, el estado de cumplimiento y la lógica de identidad pueden vivir en una capa de datos compartida que múltiples interfaces pueden leer.

Ahí es donde erc 3643 y erc 1400 aparecen como objetivos de integración prácticos. El apéndice menciona explícitamente envolver activos emitidos bajo ERC-1400 en un objeto de datos de bóveda y exponerlos a través de interfaces de gestión de datos, incluyendo ERC-3643.

También afirma que la separación de almacenamiento permite nuevas funcionalidades que no formaban parte de la interfaz original, incluyendo control de acceso basado en roles y recuperación basada en identidad. Para los constructores, este es el puente hacia las conversaciones de 'erc 3643 vs erc 1400 explicado': la interfaz que un lugar desea y el estado de cumplimiento que un emisor necesita no tienen que estar soldados juntos para siempre.

La misma dirección aparece en los primitivos de identidad utilizados por pilas de tokens autorizados, como onchainid, donde la identidad y las reclamaciones pueden ser referenciadas en cadena para apoyar la lógica de elegibilidad. El objetivo común es la composabilidad sin perder claridad en las restricciones, para que las billeteras y los lugares puedan predecir si una transferencia se liquidará antes de enviarla.

Límites y compensaciones del cumplimiento codificado

La primera compensación es determinismo versus discreción. ERC-1462 permite lógica definida por el emisor dentro de las funciones de verificación e incluso permite consultas fuera de la cadena a través de un oráculo. Eso significa que 'cumplimiento por código' aún puede depender de la verificación de identidad fuera de la cadena, la revisión de sanciones y determinaciones legales.

El código puede hacer cumplir la decisión en el momento de la acción, pero no puede eliminar la necesidad de un proceso legal que decida cuál debería ser la política.

La segunda compensación es la portabilidad frente al control del perímetro. Las restricciones a nivel de token, como las verificaciones estilo ERC-1462 o las transferencias restringidas estilo ERC-1404, maximizan las probabilidades de que un token de seguridad pueda moverse entre billeteras y lugares mientras lleva consigo su libro de reglas.

El permiso a nivel de cadena o cuenta, como el modelo de cadena Core de Prometheum, maximiza el control al restringir quién puede participar en la liquidación regulada. Eso se asemeja más a la infraestructura de mercado tradicional, pero reduce la composabilidad abierta porque el entorno no es sin permisos.

La tercera compensación es la experiencia del usuario en caso de fallo. Un revert es un instrumento contundente. El enfoque de código de estado de ERC-1462 a través de ERC-1066 es un intento directo de hacer que los fallos sean legibles para que un usuario pueda corregir lo correcto, ya sea la falta de KYC, un bloqueo de jurisdicción o un fallo fuera de la cadena.

Los sistemas que solo implementan una verificación de token en lista blanca sin códigos de razón tienden a trasladar el costo al soporte y al manejo manual de excepciones.

Finalmente, el cumplimiento codificado crea un poder administrativo que debe ser gobernado. Las funciones de congelar, revocar y reasignar de ERC-1404, los permisos de lista múltiple y los controles de aprobación o rechazo están diseñados para la remediación regulada. También significan que el emisor o administrador puede intervenir en los saldos.

Eso no es un error en los mercados regulados, pero es una restricción de diseño que debe ser explícita en las divulgaciones y en cómo las integraciones tratan el activo.

La Conclusión

He visto equipos presentar un token de seguridad como "ERC-20 más KYC" y luego sorprenderse en el primer día operativo difícil: una transferencia disputada, un cambio de jurisdicción o un lugar que pide un código de razón limpio en lugar de un revert genérico. La insistencia de ERC-1462 en funciones de verificación explícitas y códigos de estado de ERC-1066 es lo más parecido en este stack a un motor de riesgo de grado de lugar. Si el sistema no puede explicar por qué bloqueó una transferencia, no está listo para el flujo regulado.

El modelo mental más claro es elegir la ubicación de la puerta temprano y asumir las consecuencias. Las verificaciones a nivel de token mantienen el activo portátil. El permiso a nivel de cadena o cuenta, como el de la cadena Core de Prometheum, mantiene el perímetro ajustado.

El error costoso es mezclar los dos sin una fuente clara de verdad para la identidad y las restricciones, y luego descubrir que cada billetera e integración ve una versión diferente de "permitido."

Fuentes

• Propuestas de Mejora de Ethereum
• ERC-1404
• Comisión de Bolsa y Valores de EE. UU.
• Propuestas de Mejora de Ethereum