He pasado tiempo con la capa de cumplimiento de Dusk esta semana: específicamente, qué es lo que realmente habilita $DUSK cuando te pasas el pitch deck. El argumento arquitectónico es real: Citadel gestiona ZK-KYC en el onboarding, Hedger aplica reglas en la ejecución. #dusk @Dusk La afirmación es que el cumplimiento vive dentro de la transacción, no alrededor de ella. Esa es toda la diferencia frente a cualquier otra cadena de RWA.

Luego ocurrió el incidente del puente del 16 de agosto. Hubo actividad sospechosa en una wallet gestionada por el equipo, el puente se pausó y no se perdieron fondos de usuarios: actuaron rápido. Pero la remediación que destacó fue una lista de bloqueo de destinatarios para Web Wallet, desplegada para bloquear transferencias a direcciones señaladas. Restricción a nivel de dirección. El mismo instrumento contundente que TradFi ha usado durante décadas. Bloquea la dirección, no verificas la transacción.

Y eso no es un reproche. La respuesta ante una crisis recurre a la herramienta más rápida disponible, y una lista de bloqueo es exactamente eso. Pero es una ilustración precisa de lo que todo el proyecto intenta evitar. La propiedad a nivel de token está resuelta. El bloqueo a nivel de dirección también está resuelto. Lo que aún no está resuelto —y de lo que depende la propuesta de RWA institucional— es que las reglas se hagan cumplir por sí mismas en la ejecución, dentro de cada transacción, de forma determinista, sin que alguien tenga que cambiar un interruptor.

La arquitectura de Dusk apunta correctamente a ese problema. La pregunta que no dejo de darle vueltas es si la capa de cumplimiento con ZK madura antes de que las instituciones a las que está cortejando necesiten usarla realmente bajo presión...