La identidad a nivel de protocolo es clave para entender cómo Concordium (CCD) se distingue de otras blockchains públicas. Mientras que la mayoría de las cadenas igualan “dirección” e “identidad”, delegando el KYC a plataformas centralizadas, Concordium integra el vínculo entre entidades verificadas y cuentas directamente en el protocolo, asegurando que todas las transacciones, registros de Agentes y verificaciones de atributos se basen en una única base de responsabilidad.
Una pregunta habitual es: Si el cumplimiento es obligatorio, ¿por qué no subir los resultados de KYC directamente on-chain? Concordium responde que la cadena requiere autorizaciones y conclusiones de atributos verificables, pero no la exposición permanente de datos sensibles. Las pruebas de conocimiento cero (ZKP) son el puente entre estas necesidades.
¿Qué problemas resuelve la identidad a nivel de protocolo? ¿Cómo se diferencia del “anonimato de dirección”?
El modelo habitual de blockchain pública es la seudonimia: las direcciones pueden rastrearse, pero no están necesariamente vinculadas a entidades responsables. Para transferencias básicas esto es suficiente; para la firma de Agentes, el acceso a servicios según calificaciones o PayFi empresarial, las contrapartes necesitan saber “quién responde” y “si se cumplen las condiciones de cumplimiento”, sin acceder a todos los datos personales.
| Modelo |
Ubicación de la identidad |
Limitación típica |
| Anonimato de dirección |
Sin vínculo a nivel de protocolo |
Difícil atribución de responsabilidad; el cumplimiento depende de plataformas off-chain |
| Marcado KYC en plataforma |
Base de datos centralizada |
Datos aislados, reconocimiento entre aplicaciones limitado |
| Identidad a nivel de protocolo |
Vinculada en la creación de cuenta |
Requiere soporte del ecosistema de emisores de identidad |
En Concordium, la identidad a nivel de protocolo implica que cada cuenta está asociada a una persona o entidad verificada por un Emisor de Identidad, y esta relación es obligatoria según las reglas de la red, no un complemento opcional de una DApp. Esto permite que el registro y verificación en Agent Registry rastree a los Agentes hasta partes autorizadas y verificadas.
¿Cómo se vinculan las cuentas de Concordium a personas o entidades reales?
El proceso se divide en dos fases: verificación off-chain y referencia on-chain. El usuario envía la documentación requerida a un Emisor de Identidad reconocido por Concordium; tras superar el KYC o KYB, el emisor concede un objeto de identidad a la cuenta. Lo visible on-chain es la referencia de identidad y la estructura criptográfica asociada, no los documentos originales.
El objeto de identidad otorga a la cuenta un “origen verificado”: cualquier acción firmada por la cuenta—como crear un Agente, iniciar una transacción o presentar una prueba de atributos—puede vincularse a una entidad respaldada por el emisor. La revocación, las actualizaciones y la expiración se gestionan conjuntamente entre el protocolo y las políticas del emisor, según los parámetros vigentes de la red.
Esto difiere de “abrir una cuenta en un CEX y luego retirar on-chain”: el KYC del CEX es interno y la dirección on-chain permanece anónima. Concordium busca que las cuentas on-chain cuenten desde el inicio con una cadena de responsabilidad verificable.
¿Cómo funcionan las pruebas de conocimiento cero? ¿Qué atributos pueden demostrar?
Las pruebas de conocimiento cero permiten que un probador demuestre a un verificador que “una afirmación es verdadera” sin revelar información adicional. En Concordium, estas pruebas suelen basarse en atributos: si el usuario es mayor de 18 años, si reside en un país concreto, si es inversor acreditado o si cumple un límite de gasto autorizado.
El proceso tiene cuatro pasos: el Emisor de Identidad verifica la documentación off-chain y escribe las credenciales en el objeto de identidad; el usuario genera localmente la ZKP cuando la necesita; el verificador (contrato on-chain, app o Agente) solo comprueba la validez de la prueba; el resultado se devuelve como sí/no o umbral, y el contenido original nunca entra en la cadena.
| Tipo de prueba |
Qué recibe el verificador |
Qué es visible on-chain/capa pública |
| Umbral de edad |
“≥18” es verdadero |
No se revela la fecha de nacimiento |
| Residencia |
“Ubicado en jurisdicción” es verdadero |
No se revela dirección |
| Calificación |
“Nivel de inversión válido” es verdadero |
No se revelan ingresos ni activos |
El producto Verify and Access integra estas comprobaciones en interfaces que pueden llamar las aplicaciones, permitiendo que Agentes o frontends obtengan señales claras de autorización antes de acceder a servicios restringidos. En el debate Concordium vs Worldcoin: World ID se centra en “humano único”, mientras que la ZKP de Concordium verifica si una cuenta cumple requisitos de cumplimiento o negocio concretos.
Para empresas, esto significa que el onboarding puede requerir “cuenta verificada más prueba de atributo” sin construir un data lake KYC completo. Para frameworks de Agentes, las comprobaciones de autorización pueden insertarse antes de llamadas a herramientas, impidiendo que Agentes no verificados accedan a API restringidas. El ciclo de vida del objeto de identidad incluye actualizaciones y revocaciones: si cambia el estado de identidad del usuario o la política del emisor, las credenciales pueden necesitar ser renovadas o invalidadas, permitiendo que la responsabilidad evolucione según el cumplimiento.
Figura 1. Flujo de prueba de atributo de conocimiento cero en Concordium: desde el objeto de identidad hasta el resultado de verificación, la información personal original nunca entra en la cadena.
¿En qué se diferencia la identidad a nivel de protocolo del KYC tradicional on-chain?
El “KYC on-chain” suele malinterpretarse como almacenar nombres y números de identificación en los bloques. Concordium evita esto: on-chain solo se almacena el vínculo de identidad y la capacidad de verificar pruebas, no un repositorio de PII. Así se comparan los modelos:
| Dimensión |
KYC tradicional on-chain (malinterpretado) |
Identidad a nivel de protocolo en Concordium |
| Datos on-chain |
Puede incluir PII en texto claro o hasheada |
Objeto de identidad + resultado de prueba |
| Privacidad |
Difícil de eliminar una vez público |
ZKP permite divulgación selectiva |
| Interoperabilidad |
KYC repetido entre plataformas |
Pruebas reutilizables para la misma cuenta |
| Responsabilidad |
Depende de la plataforma |
Cadena de autorización a nivel de cuenta |
Para RegTech y ecosistemas de Agentes, la diferencia es que las contrapartes verifican conclusiones criptográficas y avales del emisor, no campos de formularios centralizados. PayFi, emisión de stablecoins y fondos tokenizados suelen requerir confirmar la elegibilidad del inversor o jurisdicción sin exponer perfiles completos: la identidad a nivel de protocolo + ZKP permite “verificación con divulgación mínima”.
Desde el punto de vista del desarrollador, las aplicaciones no gestionan paquetes KYC sin procesar; llaman a Verify and Access o a interfaces de generación de pruebas desde la billetera para obtener resultados booleanos o enumerados, y decidir si permiten transacciones, llamadas de Agente o acceso a contenido. Esto reduce la carga de cumplimiento para frontends y contratos inteligentes, pero requiere lógica clara sobre qué acciones requieren qué pruebas.
¿Cuáles son las ventajas y limitaciones de la identidad a nivel de protocolo?
Ventajas: traslada los controles de cumplimiento al protocolo, reduce la integración repetida de módulos de identidad en aplicaciones, la ZKP separa la “prueba de cumplimiento” de la “exposición de datos” y las cuentas verificadas ofrecen una raíz de autorización unificada para el Agent Registry. En escenarios empresariales, las auditorías pueden centrarse en cuentas y eventos de prueba, sin distribuir paquetes KYC sin procesar.
Limitaciones: la calidad depende de la cobertura y estándares de los Emisores de Identidad, y las diferencias jurisdiccionales generan atributos variables. Los usuarios deben saber que la generación de ZKP depende de la billetera local y el estado de las credenciales, por lo que las operaciones son más complejas que con direcciones anónimas. Si expiran emisores o credenciales, las pruebas deben actualizarse. La identidad a nivel de protocolo no resuelve todo el fraude off-chain: aborda “atributos verificables y responsabilidad para interacciones on-chain”.
Además, la identidad a nivel de protocolo no elimina la necesidad de auditorías off-chain: reguladores o socios pueden solicitar registros a los emisores, pero estos no deben ser públicos de forma permanente en el libro mayor global por una sola interacción on-chain. Los proyectos deben explicar de forma transparente el producto para equilibrar privacidad y cumplimiento, evitando la confusión de que ZKP implica “totalmente inrastreadable”.
Resumen
La identidad a nivel de protocolo de Concordium integra “entidades verificadas” en el modelo de cuentas y las pruebas de conocimiento cero permiten la verificación de atributos sin exponer los datos originales. Comprender esta combinación es esencial para explorar Agent Registry, Verify and Access y escenarios PayFi.
Preguntas frecuentes
¿Qué es la identidad a nivel de protocolo de Concordium?
La identidad a nivel de protocolo significa que las cuentas de Concordium están vinculadas a una persona o entidad verificada por un Emisor de Identidad al crearse. La cadena guarda objetos de identidad y referencias criptográficas, no información personal en texto claro. Así, las cuentas cuentan con fuentes de autorización responsables y pueden presentar pruebas de atributos mediante ZKP.
¿Cómo verifica Concordium la identidad?
La verificación tiene dos capas: off-chain, el Emisor de Identidad completa el KYC/KYB y emite el objeto de identidad; on-chain, o mediante interfaces como Verify and Access, se validan las pruebas de conocimiento cero generadas por el usuario. Los verificadores reciben solo la conclusión sobre el atributo, no el contenido original del certificado.
¿Cómo protegen la privacidad las pruebas de conocimiento cero?
Las pruebas de conocimiento cero permiten que el probador demuestre que “se cumple una condición” sin revelar detalles sensibles. Por ejemplo, probar que es mayor de edad sin revelar la fecha de nacimiento. Concordium utiliza esto para minimizar la exposición de PII on-chain en contextos de cumplimiento.
¿Cuál es la relación entre la identidad a nivel de protocolo y los Agentes?
Agent Registry vincula Agentes a cuentas de Concordium verificadas. La identidad a nivel de protocolo es la raíz de la cadena de responsabilidad del Agente: las contrapartes pueden rastrear hasta una parte autorizada avalada por el Emisor de Identidad. Sin esta capa, la identidad on-chain del Agente no puede conectarse de forma fiable a partes responsables reales.
¿Cuáles son las limitaciones de la identidad a nivel de protocolo?
Las limitaciones incluyen la cobertura de Emisores de Identidad, diferencias regionales de cumplimiento, gestión de actualizaciones y expiración de credenciales, y la curva de aprendizaje para operar ZKP desde la billetera. La identidad a nivel de protocolo se centra en la responsabilidad y prueba de atributos on-chain, pero no sustituye los controles de riesgo off-chain ni todos los procesos antifraude.
