#dusk $DUSK @Dusk
Empecé a analizar el diseño del settlement y acabé centrándome en un concepto financiero:
Entrega contra pago.
La idea es sencilla.
Un lado entrega el activo.
El otro lado entrega el pago.
Ambos deben liquidarse al mismo tiempo.
Si el activo se mueve mientras el pago falla, la transacción tiene un problema.
Si el pago se mueve mientras el activo falla, el problema simplemente cambia de lado.
Por eso, poner una seguridad en la cadena (onchain) es solo una parte del problema del settlement.
Importan tanto la pata del activo como la pata del pago.
El Régimen Piloto de la UE para DLT es especialmente relevante, porque proporciona un marco para probar infraestructuras de mercados financieros basadas en DLT bajo condiciones regulatorias.
La finalidad determinista de @Dusk le da a la red un punto de liquidación claro, con $DUSK asegurando a los validadores que llegan hasta allí. #dusk
Pero la finalidad por sí sola no crea DvP.
Todavía es necesario que ambos lados coordinen correctamente.
Esa es la parte que me gustaría ver demostrada en una transacción real regulada.
No un diagrama.
No un concepto.
Una pata real del activo y una pata real del pago completándose juntas bajo las reglas requeridas.
Eso me diría mucho más sobre el diseño de settlement de Dusk que otra comparación de rendimiento.