La gran mayoría de los proyectos en el mercado siguen la ruta de “emitir monedas y luego completar el boleto”: primero hacer que los tokens suban, primero excavar la liquidez; ¿cumplimiento normativo? Después simplemente se consigue a una firma legal que emita un dictamen y con eso ya está “arreglado”. Para decirlo sin rodeos, no tengo claro cuántos ciclos de mercado alcista puede aguantar un modelo así bajo el escrutinio de los reguladores.
Hasta que desmonté y analicé por separado el Zedger de @Dusk y el estándar XSC, me di cuenta de que hay equipos que han pensado esto a fondo. Codificaron directamente en reglas “duras” a nivel de contrato lógicas de cumplimiento como la verificación de inversores aptos, las restricciones de transferencia y las votaciones de dividendos. Antes de que cada transacción se liquide, primero pasa por una verificación de cumplimiento: si la aprueba, se genera un comprobante en cadena y se habilita; si no la aprueba, se queda bloqueada en el mismo punto. No se trata de esperar a que la transacción se suba a la cadena para luego buscar responsables, sino de rechazar desde el origen cualquier operación que no cumpla. Esta idea de “verificación previa” es casi igual en espíritu a la lógica subyacente de Newton para el control de riesgos en operaciones; la diferencia es que Dusk la aplica a un nivel más sensible: la materialización del cumplimiento regulatorio.
La capa de datos se apoya en la memoria dentro de cuentas privadas para implementar un circuito de verificación de extremo a extremo, y en teoría es un nivel superior a esos proyectos que dependen de auditoría manual fuera de la cadena. La fiabilidad del precio proporcionado por RedStone ya ha sido validada en más de 110 cadenas, así que en esa parte no me preocupa demasiado.
Pero debo decirlo: en la información pública actual hay un punto que no me deja dormir bien: no está claro quién tiene permisos para modificar las reglas.
Por muy bonito que funcione un contrato inteligente, si detrás se oculta un “acceso de administrador”, y puede cambiar parámetros y reglas en cualquier momento, entonces hay que poner un signo de interrogación a la capacidad de resiliencia del sistema. ¿Qué pasa si cambian las políticas regulatorias? ¿Quién activa la modificación si se ajustan las reglas fiscales? ¿Hay restricciones obligatorias sobre el time-lock y las firmas múltiples? Con lo que se ve ahora, no aparecen respuestas claras.
Mi juicio es: la dirección es correcta, pero el camino es largo. Este modelo de verificación previa convierte las reglas regulatorias en una capacidad nativa de la capa de base en cadena; a largo plazo, me gusta mucho esa idea. Pero Dusk aún necesita una prueba con escala real de fondos: que funcione en pruebas de unos cuantos millones de dólares no significa que también se mantenga estable cuando el tamaño llegue a decenas de miles de millones. En lo sucesivo, centraré la mirada en la implementación de DuskTrade en colaboración con NPEX: solo cuando todo el flujo—emparejamiento de operaciones, conciliación y liquidación, y verificación de cumplimiento—esté realmente en marcha, se podrá afirmar de forma genuina que esta ruta es viable.
¿Creéis que el cumplimiento nativo en cadena es la solución final o que es demasiado idealista? Hablemos en la sección de comentarios.
#dusk $DUSK @Dusk
Hasta que desmonté y analicé por separado el Zedger de @Dusk y el estándar XSC, me di cuenta de que hay equipos que han pensado esto a fondo. Codificaron directamente en reglas “duras” a nivel de contrato lógicas de cumplimiento como la verificación de inversores aptos, las restricciones de transferencia y las votaciones de dividendos. Antes de que cada transacción se liquide, primero pasa por una verificación de cumplimiento: si la aprueba, se genera un comprobante en cadena y se habilita; si no la aprueba, se queda bloqueada en el mismo punto. No se trata de esperar a que la transacción se suba a la cadena para luego buscar responsables, sino de rechazar desde el origen cualquier operación que no cumpla. Esta idea de “verificación previa” es casi igual en espíritu a la lógica subyacente de Newton para el control de riesgos en operaciones; la diferencia es que Dusk la aplica a un nivel más sensible: la materialización del cumplimiento regulatorio.
La capa de datos se apoya en la memoria dentro de cuentas privadas para implementar un circuito de verificación de extremo a extremo, y en teoría es un nivel superior a esos proyectos que dependen de auditoría manual fuera de la cadena. La fiabilidad del precio proporcionado por RedStone ya ha sido validada en más de 110 cadenas, así que en esa parte no me preocupa demasiado.
Pero debo decirlo: en la información pública actual hay un punto que no me deja dormir bien: no está claro quién tiene permisos para modificar las reglas.
Por muy bonito que funcione un contrato inteligente, si detrás se oculta un “acceso de administrador”, y puede cambiar parámetros y reglas en cualquier momento, entonces hay que poner un signo de interrogación a la capacidad de resiliencia del sistema. ¿Qué pasa si cambian las políticas regulatorias? ¿Quién activa la modificación si se ajustan las reglas fiscales? ¿Hay restricciones obligatorias sobre el time-lock y las firmas múltiples? Con lo que se ve ahora, no aparecen respuestas claras.
Mi juicio es: la dirección es correcta, pero el camino es largo. Este modelo de verificación previa convierte las reglas regulatorias en una capacidad nativa de la capa de base en cadena; a largo plazo, me gusta mucho esa idea. Pero Dusk aún necesita una prueba con escala real de fondos: que funcione en pruebas de unos cuantos millones de dólares no significa que también se mantenga estable cuando el tamaño llegue a decenas de miles de millones. En lo sucesivo, centraré la mirada en la implementación de DuskTrade en colaboración con NPEX: solo cuando todo el flujo—emparejamiento de operaciones, conciliación y liquidación, y verificación de cumplimiento—esté realmente en marcha, se podrá afirmar de forma genuina que esta ruta es viable.
¿Creéis que el cumplimiento nativo en cadena es la solución final o que es demasiado idealista? Hablemos en la sección de comentarios.
#dusk $DUSK @Dusk