#dusk $DUSK Hace un tiempo ayudé a un amigo que trabaja en RWA a trazar un camino de custodia conforme. Después de dar una vuelta por varias cadenas principales, descubrí un problema: la mayoría de las cadenas convierten el hecho de poner los activos “on-chain” en un sistema de “registro equivale a finalización”. Pero en el mundo financiero real, el alcance de responsabilidad de un custodio es mucho más complejo. Las instituciones de gestión de activos deben anclar los activos subyacentes en la cadena, pero no pueden exponer el detalle de las posiciones del cliente en un libro público para que cualquiera lo revise. En el sector tradicional de custodia, esta disyuntiva se resuelve mediante capas de acuerdos legales; sin embargo, cuando se traslada “on-chain”, esa base de soporte desaparece.
$DUSK, en esta parte, tiene una perspectiva bastante diferente. No intenta simular relaciones de custodia mediante contratos inteligentes genéricos, sino que separa la prueba de propiedad y los permisos de acceso desde el propio estándar del token. Usando pruebas de conocimiento cero, el custodio puede demostrar hacia afuera que el activo existe y que no ha sido desviado, mientras que los detalles solo se revelan a auditores conformes que poseen la clave de descifrado. En esencia, este diseño traslada los requisitos duales tradicionales de “confidencialidad + auditabilidad” al nivel del protocolo, en lugar de parchearlos a nivel de aplicación.
Aun así, siempre siento que la solidez de la arquitectura técnica es solo el primer paso. Lo que realmente retrasa a las instituciones a la hora de hacer “on-chain” no es el rendimiento de la cadena, sino el déficit de confianza legal del área jurídica frente a la idea de que “la determinación de derechos en cadena equivale a la determinación legal de derechos”.
Otro punto que suele pasarse por alto es la ruptura de la cadena de responsabilidad en la custodia. En las finanzas tradicionales, la cadena de responsabilidad entre el custodio, el subcustodio y la entidad de custodia central es muy clara: cuando hay un problema, se puede rastrear el incidente hasta el eslabón específico. Pero, una vez que en la custodia on-chain se introducen claves de múltiples partes y el descifrado condicionado, la atribución de responsabilidad tras un incidente se vuelve extremadamente borrosa: si se trata de una vulnerabilidad del protocolo, mala conducta de nodos o filtración de claves, la dificultad de la prueba aumenta en un orden de magnitud respecto al sistema tradicional.
Por eso, a largo plazo, estoy de acuerdo con la dirección de DUSK: en el nicho específico de la custodia conforme, realmente han acertado con la necesidad. Pero en la etapa actual, prefiero tratarlo como un “puesto de observación”: esperaría a que los primeros custodios con licencia logren ejecutar de verdad el flujo completo del negocio y obtengan el dictamen legal, antes de tomar una decisión. ¿Crees que la custodia on-chain finalmente reemplazará a las entidades de custodia tradicionales, o solo podrá funcionar como un sistema auxiliar en paralelo? @Dusk
#dusk @Dusk