#dusk $DUSK @Dusk
La tokenización suele describirse como poner un activo en cadena (onchain). Rara vez es así. Lo que se pone en cadena es una reclamación sobre el activo, mientras que el activo en sí permanece en la base de datos del registrador donde siempre ha vivido — y el ciclo de vida permanece allí con él.
El ciclo de vida es la parte costosa. Un bono no es un objeto estático. Paga cupones, lleva un registro de tenedores, pasa por acciones corporativas, se pignora como colateral y vence. Cada uno de esos eventos es una conciliación entre sistemas que no comparten una única fuente de verdad. Envolver el instrumento en un token no elimina ninguno de ellos. Incluso podría añadir uno, porque ahora el envoltorio y el subyacente pueden no ponerse de acuerdo.
La emisión nativa es la reclamación que @dusk está haciendo en realidad: crear el instrumento en cadena desde el principio, con la elegibilidad, las restricciones de transferencia y la lógica de liquidación expresadas en la capa de protocolo, en lugar de añadirse después. Zedger es el protocolo de activos para eso, ejecutándose de forma nativa en DuskDS, con Citadel gestionando la identidad y la divulgación selectiva para que la elegibilidad pueda demostrarse sin publicar quién es el tenedor.
La dificultad honesta aquí es legal, no técnica. Para que una entrada de cadena sea el registro en lugar de un espejo de él, la ley tiene que decirlo — y precisamente para eso se construyó el Régimen Piloto de DLT de la UE, para probarlo, dentro de límites de instrumentos y por un periodo limitado.
Así que la pregunta que vale la pena hacer sobre $DUSK no es si la emisión nativa es mejor en principio. Es si un primer instrumento real se emite de esta manera y sobrevive a sus propias fechas de cupón. #dusk