Ich habe vorhin im Repo „duskevm-genesis“ herumgestöbert – die Genesis-Block-Konfiguration von DuskEVM wurde am 8. August aktualisiert, und ein Teil dieser Vorbereitung ist offenbar im Hinblick auf die Chainlink-Integration im Gange.
Hier ist, was hängenblieb: Die Einordnung rund um Dusk Network ($DUSK ), DataLink und Chainlink Data Streams lautet „verifiziertes Exchange-Datenmaterial onchain“ – aber verifiziert von wem genau? NPEX, die regulierte niederländische Börse, wird als exklusiver Datenanbieter genannt. #dusk @Dusk leitet hier kein dezentrales Set an Oracle-Nodes um. DataLink speist den eigenen Feed von NPEX direkt onchain. Data Streams übernimmt die Low-Latency-Zustellung. Es ist eine einzige Quelle, formal qualifiziert, technisch sauber.
Und ehrlich gesagt, ist das wahrscheinlich auch beabsichtigt. Regulierte Wertpapier-Workflows wollen keine 21 anonymen Oracle-Nodes, die einen Preis im mittleren Marktsegment mitteln. Sie wollen die Börse, die den Deal tatsächlich bepreist hat. Für tokenisierte KMU-Aktien im EU-Rahmen ist ein einzelner autoritativer Feed kein Mangel – das ist die Architektur.
Aber nimm dir einen Moment dafür Zeit: Entwickler, die auf DuskEVM in dieser Datenebene unterwegs sind, verlassen sich nicht auf ein Protokoll im üblichen Sinn. Sie setzen auf eine exklusive Vereinbarung zwischen zwei konkreten Parteien. Das ist kein Oracle-Risiko. Das ist näher an Lizenzierungsrisiko – nur eben im Gewand von Oracle.
Ich bin mir trotzdem nicht sicher, ob dieser Unterschied für Builder in der Praxis sichtbar wird, oder ob er nur dann relevant wird, wenn sich die Beziehung jemals ändert.
Hier ist, was hängenblieb: Die Einordnung rund um Dusk Network ($DUSK ), DataLink und Chainlink Data Streams lautet „verifiziertes Exchange-Datenmaterial onchain“ – aber verifiziert von wem genau? NPEX, die regulierte niederländische Börse, wird als exklusiver Datenanbieter genannt. #dusk @Dusk leitet hier kein dezentrales Set an Oracle-Nodes um. DataLink speist den eigenen Feed von NPEX direkt onchain. Data Streams übernimmt die Low-Latency-Zustellung. Es ist eine einzige Quelle, formal qualifiziert, technisch sauber.
Und ehrlich gesagt, ist das wahrscheinlich auch beabsichtigt. Regulierte Wertpapier-Workflows wollen keine 21 anonymen Oracle-Nodes, die einen Preis im mittleren Marktsegment mitteln. Sie wollen die Börse, die den Deal tatsächlich bepreist hat. Für tokenisierte KMU-Aktien im EU-Rahmen ist ein einzelner autoritativer Feed kein Mangel – das ist die Architektur.
Aber nimm dir einen Moment dafür Zeit: Entwickler, die auf DuskEVM in dieser Datenebene unterwegs sind, verlassen sich nicht auf ein Protokoll im üblichen Sinn. Sie setzen auf eine exklusive Vereinbarung zwischen zwei konkreten Parteien. Das ist kein Oracle-Risiko. Das ist näher an Lizenzierungsrisiko – nur eben im Gewand von Oracle.
Ich bin mir trotzdem nicht sicher, ob dieser Unterschied für Builder in der Praxis sichtbar wird, oder ob er nur dann relevant wird, wenn sich die Beziehung jemals ändert.