Seguí mirando un diagrama de flujo de un pago de dividendos hasta que dejó de tener sentido. DTC a bróker a subcustodio a accionista, cuatro saltos, y asumí que el cuello de botella estaba en alguna parte de la velocidad de procesamiento. No es eso. Cuanto más lo investigaba, más claro veía que el costo real está en la conciliación: cada eslabón en esa cadena actualiza sus propios registros de forma independiente y luego todos comparan notas después. Ahí es donde en realidad se va el coste de 58.000 millones de dólares al año en acciones corporativas.
Lo que me llamó la atención al profundizar en el diseño XSC de DUSK es que no intenta hacer más rápidos cada uno de los saltos. Elimina la necesidad de que los saltos tengan que conciliar en absoluto: una sola ejecución, un solo resultado, cada titular lee desde la misma fuente en lugar de que cuatro partes calculen por separado y se contrasten más tarde. Es aquí donde el enfoque de DUSK empieza a sentirse diferente de la mayor parte de la infraestructura que había visto antes.
Fue entonces cuando se me aclaró la diferencia entre tokenización y emisión nativa. Envolver una acción en un token sigue encima de la misma infraestructura de DTC, a la que has añadido una capa, no la has reemplazado. La emisión nativa sobre algo como DUSK plantea una pregunta más directa: ¿siguen siendo necesarios miles de agentes pagadores procesando de forma independiente el mismo evento de dividendo si existe una sola capa de liquidación de la que todos leen? La arquitectura completa de DUSK parece apostar a que la respuesta es no.
Aun así, me sigue preocupando la parte de la responsabilidad. Si un contrato de DUSK calcula mal un pago, ¿quién queda obligado: la cadena, el emisor, el agente pagador que antes existía? No creo que eso esté respondido todavía, y no estoy seguro de que deba pasarse por alto solo porque la arquitectura esté más limpia.
#dusk $DUSK @Dusk
Lo que me llamó la atención al profundizar en el diseño XSC de DUSK es que no intenta hacer más rápidos cada uno de los saltos. Elimina la necesidad de que los saltos tengan que conciliar en absoluto: una sola ejecución, un solo resultado, cada titular lee desde la misma fuente en lugar de que cuatro partes calculen por separado y se contrasten más tarde. Es aquí donde el enfoque de DUSK empieza a sentirse diferente de la mayor parte de la infraestructura que había visto antes.
Fue entonces cuando se me aclaró la diferencia entre tokenización y emisión nativa. Envolver una acción en un token sigue encima de la misma infraestructura de DTC, a la que has añadido una capa, no la has reemplazado. La emisión nativa sobre algo como DUSK plantea una pregunta más directa: ¿siguen siendo necesarios miles de agentes pagadores procesando de forma independiente el mismo evento de dividendo si existe una sola capa de liquidación de la que todos leen? La arquitectura completa de DUSK parece apostar a que la respuesta es no.
Aun así, me sigue preocupando la parte de la responsabilidad. Si un contrato de DUSK calcula mal un pago, ¿quién queda obligado: la cadena, el emisor, el agente pagador que antes existía? No creo que eso esté respondido todavía, y no estoy seguro de que deba pasarse por alto solo porque la arquitectura esté más limpia.
#dusk $DUSK @Dusk
