Lo que sigo teniendo presente con los valores tokenizados es que la elegibilidad no es una función que se agrega más adelante. Tiene que ser estructural, o no es realmente compatible, solo está etiquetada así. Los primitivas de control de acceso de Dusk están diseñadas para manejar verificaciones de elegibilidad del inversor, estado de acreditación, jurisdicción y restricciones similares, a nivel de protocolo en lugar de hacerlo mediante un “guardia” fuera de la cadena, acoplado como un añadido a un contrato público.
Por qué esa distinción importa: la aplicación fuera de la cadena depende de que alguien verifique, de forma consistente, cada vez. Las primitivas on-chain hacen que la verificación forme parte de la lógica de la transacción en sí, lo que en principio ofrece una garantía más sólida, pero solo si los datos subyacentes de identidad y atestación que alimentan esas verificaciones son en sí confiables. La privacidad añade otra capa de tensión aquí, ya que verificar la elegibilidad sin exponer la identidad completa del inversor es un problema más difícil que verificarla de forma abierta. Lo que aún no sé es cómo estas primitivas manejan los casos límite, cambios de jurisdicción, acreditaciones revocadas, atestaciones impugnadas. Preferiría ver esto probado con escenarios reales y desordenados, más que con documentación pulcra. Estoy observando cómo los emisores configuran en la práctica estos controles.

@Dusk #dusk $DUSK