Cómo funciona el KYC y la lista blanca en tokens permitidos
Cómo funciona el KYC y la lista blanca en la cadena se reduce a un movimiento: convertir una decisión de KYC/AML fuera de la cadena en elegibilidad verificable por máquina en la cadena que los contratos inteligentes pueden hacer cumplir en el momento de la transferencia o acceso.
La elección de diseño no es “KYC o no KYC”, sino dónde se encuentra la puerta en la pila y si las reglas viven dentro del token o en módulos de cumplimiento actualizables.
Puntos clave
- Las verificaciones de KYC/AML generalmente ocurren fuera de la cadena con proveedores regulados, mientras que la capa en la cadena almacena un resultado verificable de “elegible/no elegible + atributos” como reclamaciones vinculadas a una identidad en la cadena.
- ERC-3643hace que el cumplimiento sea una primitiva de transferencia: el token verifica un Registro de Identidad y un Módulo de Cumplimiento, y la transacción se revierte si alguna de las verificaciones falla.
- La lista blanca se puede hacer cumplir en múltiples capas más allá del contrato del token, incluyendo puente, RPC y consenso, con un claro intercambio entre control y apertura.
- El plano de control operativo es típicamente el Registro de Identidad más el Módulo de Cumplimiento, que concentra el riesgo de actualización y clave de administrador en esos contratos.
Dónde encaja el KYC en la cadena en cripto
Las cadenas sin permisos permiten que cualquierdirección recibir y enviar activos, que es exactamente lo que los emisores regulados no pueden permitir para muchos valores tokenizados y otros instrumentos restringidos. La restricción no es filosófica. Es mecánica: si un activo debe ser mantenido solo por inversores elegibles, el sistema necesita una forma de detener una transferencia antes de que se complete en la cadena.
Ahí es donde aparece “cumplimiento por código”. La frase en cadena kyc se malinterpreta como “poner documentos de identidad en Ethereum.” La arquitectura común en las fuentes es la opuesta. Las verificaciones de KYC y AML aún ocurren fuera de la cadena con proveedores regulados, mientras que la cadena mantiene el mínimo necesario para hacer que la elegibilidad sea verificable por máquina en el momento de la transacción.
La descripción de ONINO es explícita: el resultado de la verificación fuera de la cadena se representa en la cadena como reclamos criptográficos almacenados en el ONCHAINID y luego leer durante las transferencias.
La inclusión en la lista blanca es la regla de aplicación que consume esas reclamaciones. Una lista blanca de tokens puede ser tan simple como un mapeo de direcciones aprobadas, pero los diseños modernos tratan “quién está permitido” como una cuestión de identidad, no como una cuestión de dirección.
Esa es la diferencia entre un modelo de billetera con permisos (esta dirección está permitida) y un modelo vinculado a la identidad (esta dirección está vinculada a una identidad elegible). En el enfoque vinculado a la identidad, una dirección puede rotar mientras que la elegibilidad permanece adjunta al registro de identidad.
El otro término que importa es dirección bloqueada. En estos sistemas, una dirección bloqueada no es una etiqueta social. Es una dirección que no pasa las verificaciones de elegibilidad, por lo que las transferencias a ella se revierten, o se le niega el acceso en alguna otra puerta de la pila.
El mecanismo central detrás de la inclusión en la lista blanca
Dos palancas impulsan todo el sistema, y la mayoría de las explicaciones las mezclan.
La primera palanca es la representación de identidad y elegibilidad. Las fuentes describen ONCHAINID como la capa de identidad en cadena utilizada con ERC-3643, con reclamaciones o credenciales emitidas por partes de confianza o autorizadas. AI CERTs destaca el patrón de privacidad: los datos sensibles permanecen fuera de la cadena, mientras que las firmas o reclamaciones se mantienen en la cadena. Esa división es el punto.
La cadena no necesita un escaneo de pasaporte. Necesita una declaración verificable como “KYC aprobado” o “jurisdicción = UE”, firmada por un emisor en el que el sistema confía.
La segunda palanca es la aplicación de reglas. Una vez que la elegibilidad está representada en la cadena, algo aún tiene que hacerla cumplir. La aplicación puede vivir dentro de un contrato de token, dentro de una aplicación, o más arriba en la pila. A nivel de token, la aplicación significa que el token se niega a moverse a menos que ambas partes sean elegibles y la transferencia satisfaga la lógica de las reglas. Ahí es donde laidea del token de lista blancase vuelve concreta: el token en sí se convierte en la puerta.
Un flujo genérico se ve así:
1. El proveedor fuera de la cadena verifica a un usuario y decide qué atributos tiene (KYC aprobado, acreditación, jurisdicción). 2. Un emisor de confianza escribe esos atributos en la cadena como reclamaciones vinculadas a una identidad en la cadena. 3. Un registrovinculauna o más direcciones de billetera a esa identidad y responde “¿es esta dirección elegible en este momento?” 4.
Un token o aplicación verifica el registro y cualquier motor de reglas durante una transacción. 5. Si una verificación falla, la transacción se revierte, por lo que el estado no cambia y la transferencia no se completa.
La salida no es “KYC en la cadena.” La salida es un sí/no determinista en el momento de la transferencia, más unrastro de auditoríade lo que los contratos hicieron cumplir.
Cómo ERC-3643 hace cumplir KYC en las transferencias
ERC-3643 se posiciona en su documentación como un conjunto de contratos inteligentes de código abierto para emitir, gestionar y transferir tokens con permiso, con un marco de identidad descentralizado incorporado para que solo los usuarios elegibles puedan convertirse en titulares de tokens en blockchains sin permiso.
También traza una línea clara frente a ERC-20: ERC-3643 verifica la identidad y la elegibilidad antes de permitir transferencias, apoyando requisitos de cumplimiento como KYC y AML.
La arquitectura ERC-3643/T-REX de ONINO descompone el sistema en cuatro componentes conectados: identidades en la cadena, un registro de identidad, módulos de cumplimiento enchufables y el contrato del token. Esa descomposición es importante porque muestra dónde los equipos operan realmente el sistema día a día.
El árbol de decisiones de transferencia descrito por ONINO es simple y brutal, por eso funciona:
1. Se inicia una transferencia en el contrato del token. 2. El token verifica el Registro de Identidad para la verificación del remitente y el receptor. 3. El token verifica un Módulo de Cumplimiento por violaciones de reglas. 4. Si alguna verificación falla, la transacción se revierte. Si ambas pasan, la transferencia se ejecuta.
Esta es la clave práctica que supera a las listas blancas ad-hoc. Un token con permisos construido sobre erc 3643 no "hace su mejor esfuerzo" y reconcilia después. La cadena acepta la transferencia bajo las reglas o no lo hace.
El Módulo de Cumplimiento es donde la aplicación de reglas se vuelve modular. ONINO enumera ejemplos que pueden ser codificados allí: límites de inversores, restricciones jurisdiccionales, períodos de bloqueo y límites de tenedores. ONINO también afirma que las reglas pueden ser actualizadas sin redeplegar el token porque la lógica de cumplimiento está separada del contrato del token. Esa separación es el desbloqueo operativo, y también es donde se concentra el riesgo de gobernanza y actualización.
En los mercados tradicionales, un agente de transferencia es la parte que mantiene el registro oficial de propiedad y procesa ciertos eventos del ciclo de vida. Las pilas al estilo ERC-3643 son un intento de codificar partes de esa función en contratos y roles de agente, para que el propio token pueda hacer cumplir quién puede poseer y transferir.
Otros lugares donde se puede hacer cumplir KYC
La guía de DeFi con permisos de Conduit enmarca "dónde se restringe" como una elección de pila, no como una elección de estándar de token. Describe cuatro capas de infraestructura donde se puede implementar la autorización, clasificadas de menos a más impactantes en la apertura y descentralización de una cadena: protocolo, puente, RPC y consenso.
La restricción a nivel de protocolo es la más específica. El ejemplo de Conduit es la inclusión en la lista blanca por activo, señalando estándares de token como ERC-3643 que pueden hacer cumplir quién puede poseer y transferir un token. Aquí es donde un token con permisos puede prevenir transferencias secundarias a tenedores no elegibles porque el propio token se niega a moverse.
La restricción a nivel de puente es control de perímetro. Conduit describe la restricción KYC a nivel de puente como una forma de decidir quién puede ingresar a un ecosistema. Esto puede evitar que billeteras no verificadas traigan activos a una cadena, pero no detiene automáticamente las transferencias dentro del ecosistema a menos que los activos mismos también tengan permisos.
La restricción a nivel de RPC da forma a la ruta predeterminada del usuario. Conduit da ejemplos como restricciones geográficas o flujos de aprobación de transacciones en puntos finales RPC oficiales. Estos controles pueden ser actualizados como política, y pueden ser eludidos por usuarios que ejecutan sus propios nodos en muchas redes. Eso hace que la restricción RPC sea útil para la postura de cumplimiento, pero más débil como garantía sólida.
El control a nivel de consenso es el más fuerte y el más invasivo. Conduit lo describe como establecer políticas de inclusión de transacciones a nivel del secuenciador o del conjunto de validadores. Proporciona la aplicación más profunda porque cada transacción está sujeta a la regla, y también tiene el mayor impacto en la apertura.
La implicación de diseño es sencilla: la aplicación a nivel de token se trata de controlar la tenencia y transferencia de un activo específico, mientras que los controles de puente y RPC se centran en controlar las rutas de entrada y acceso.
Compromisos prácticos y modos de fallo
El primer compromiso es el control operativo frente al riesgo de actualización. El marco modular de cumplimiento de ONINO es atractivo porque las reglas pueden cambiar sin necesidad de redeplegar el token. El costo es que el Módulo de Cumplimiento y el Registro de Identidad se convierten en el plano de control.
Las claves de administrador, los permisos de actualización y el alcance de auditoría se agrupan allí, no en la superficie similar a ERC-20 del token.
El segundo compromiso es la experiencia del usuario. La aplicación se presenta a los usuarios como transacciones revertidas, no como una advertencia cortés. Si un receptor no es elegible, la transferencia falla y aún se gastan gas. Los sistemas que no proporcionan verificaciones previas claras y razones de fallo legibles convierten el cumplimiento en tickets de soporte.
El tercer compromiso es lo que realmente significa “lista blanca”. Una lista de direcciones estáticas es frágil porque las direcciones rotan, las configuraciones de custodia cambian y las instituciones utilizan múltiples billeteras. Los modelos vinculados a la identidad reducen esa fragilidad, pero introducen dependencias en registros e emisores de confianza.
El cuarto compromiso es la postura de descentralización. La clasificación por capas de Conduit es un modelo mental útil: el control de protocolo es estrecho y componible, mientras que el control de consenso es amplio y coercitivo. Los equipos que afirman tener “cumplimiento descentralizado” sin nombrar dónde se encuentra la aplicación suelen estar ocultando el verdadero punto de control.
Los modos de fallo siguen la arquitectura. Si el Registro de Identidad está equivocado, los usuarios elegibles son tratados como una dirección bloqueada. Si el Módulo de Cumplimiento está mal configurado, las transferencias que deberían liquidarse se revierten. Si la gobernanza en torno a las actualizaciones es descuidada, las reglas pueden cambiar más rápido de lo que las contrapartes esperan.
Por eso el cumplimiento por código no es solo una historia legal. Es una historia de diseño de sistemas con puntos de estrangulamiento muy específicos.
Fuentes
Frequently Asked Questions
¿Significa que el KYC en la cadena implica que los pasaportes o datos personales se almacenan en la cadena?
No. El patrón común es que los datos sensibles permanecen fuera de la cadena, mientras que la cadena almacena reclamos o firmas verificables que representan la elegibilidad. Esos reclamos pueden ser verificados por contratos inteligentes durante transferencias o verificaciones de acceso.
¿Cuál es la diferencia entre una lista blanca de tokens y una lista blanca basada en identidad?
Una lista blanca de tokens simple suele ser una lista de direcciones de billetera aprobadas. Los diseños basados en identidad vinculan billeteras a una identidad en la cadena y verifican la elegibilidad a través de un registro más lógica de reglas, por lo que el sistema no está limitado a una lista de direcciones estática.
¿Cómo bloquea ERC-3643 las transferencias a una billetera no elegible?
Los tokens estilo ERC-3643 verifican un Registro de Identidad para la verificación del remitente y receptor y luego verifican un Módulo de Cumplimiento por violaciones de reglas. Si alguna de las verificaciones falla, la transacción se revierte, por lo que la transferencia no se ejecuta.
¿Dónde más se puede hacer cumplir el KYC y la lista blanca además del contrato de token?
La autorización se puede implementar en la capa de protocolo, capa de puente, capa de RPC o capa de consenso. Los controles de puente y RPC pueden restringir el acceso y los caminos de acceso predeterminados, mientras que las políticas de consenso pueden hacer cumplir reglas sobre la inclusión de transacciones a nivel de red.
¿Por qué los equipos utilizan módulos de cumplimiento modulares en lugar de codificar reglas directamente en el token?
Separar el contrato de token de los módulos de cumplimiento enchufables permite que reglas como límites, restricciones de jurisdicción, bloqueos y límites de tenedores se actualicen sin redeplegar el token. La compensación es que el control de actualización y administración se concentra en la capa de cumplimiento.
