#dusk $DUSK @Dusk
Siguió volviendo a cómo funciona realmente Zedger bajo XSC. No es solo "tokens conformes", es lógica de conformidad incorporada dentro de la propia función de transferencia del contrato: comprobaciones de elegibilidad, restricciones de transferencia, transferencias forzadas, todo evaluado en el momento en que alguien intenta mover el activo. $DUSK #dusk @Dusk no está almacenando la conformidad como metadatos: la está convirtiendo en un requisito previo para que la transición de estado pueda pasar.
Eso es un cambio real frente a los sistemas de back-office, donde una infracción se detecta después de la liquidación, y luego se revierte, se multa o se reporta. Aquí la transferencia no conforme simplemente no se ejecuta. No hay operación que deshacer, porque nunca llegó a ser una operación.
Pero eso también significa que cada regla de conformidad tiene que estar codificada completamente de antemano. Los equipos de back-office actualmente toman decisiones, aplican discreción y manejan excepciones caso por caso. Un contrato no puede encogerse de hombros y usar discreción: solo conoce la regla que se le dio.
Lo que cambió para mí fue darme cuenta de que "la conformidad on-chain" en realidad no se trata de la transparencia, sino de eliminar el espacio donde antes se sentaba el juicio humano. Vale la pena observar si las implementaciones en vivo de XSC de Dusk realmente codifican el manejo de excepciones para casos límite, o si cada caso límite sigue en silencio regresando a una anulación fuera de cadena.