Es war ein Uhr nachts, und ich starrte eine halbe Stunde lang auf das Architekturdiagramm des Newton Mainnet Beta. In der offiziellen Ankündigung von RedStone stand: „RedStone has integrated its verified price data directly into Newton’s policy enforcement layer.“ Dieses auf EigenLayer AVS basierende Autorisierungsschichten-Design ist wirklich gelungen – wenn Transaktionen die Newton-Autorisierungsschicht erreichen, bewertet das System vor dem Settlement die Situation mit RedStones Echtzeit-Marktdaten und entscheidet, ob es genehmigt oder blockiert.
Doch wenn man der Datenflussrichtung weiter nach unten folgt, wird mir mulmig.
Der Policy-Engine von Newton vertraut RedStone als Preis- und Marktdaten-Ebene. In der Analyse von KuCoin heißt es ganz direkt: „a key risk is concentration. If Newton's policy engine becomes heavily dependent on RedStone pricing, any disruption at the oracle layer could cascade into transaction blocks or freezes across the platform.“ Jede Unterbrechung kann sich zu einer Transaktionssperre auf Plattformebene hochschaukeln.
Eine einzelne Datenquelle bedeutet einen einzelnen Punkt des Versagens. Das Sicherheits-Framework von Chainlink führt „single point of failure / single data source“ längst als eines der fünf größten Oracle-Sicherheitsrisiken auf. Oracle-Server-Ausfälle, manipulierte Daten, Preismanipulation – das sind keine theoretischen Szenarien. Im Oktober 2025 führte ein Marktverkauf von 60 Millionen US-Dollar zu einem Wertverlust von 19,3 Milliarden US-Dollar. Wenn im Oracle ein Riss entsteht, stürzt die gesamte darüberliegende Struktur ein. Wenn RedStones Preiszufuhr manipuliert wird, führen alle automatisierten Strategien, die auf Preisabfragen basieren – DCA, Hedging, Liquidationen – automatisch die falschen Aktionen aus.
Noch beunruhigender ist für mich die Datenherkunft. Die von TEE gelesenen Kursdaten und die Off-Chain-Berechnungsdaten erzeugen lediglich vereinfachte ZK-Beweise. Vollständige Rohdaten werden nicht on-chain gespeichert. Wenn es bei automatisierten Trades zu Verluststreitigkeiten kommt, können Nutzer die ursprünglichen Daten nicht vollständig on-chain nachprüfen und nicht feststellen, ob es ein Oracle-, ein Node- oder ein Smart-Contract-technisches Problem war. Ein „verifizierbares“ System kann an der wichtigsten Datenquelle dennoch keine vollständigen On-Chain-Audit-Hinweise liefern.
„A policy is only as strong as the data behind it.“ So schön die Policy auch ist – wenn die Datenquelle reißt ab, wird sie zu Makulatur. Gibst du deine automatisierten Strategien einem Oraclesystem, das von einem einzigen Punkt abhängt, und wenn es sich irrt, bekommst du dann überhaupt Beweise, um Verantwortung nachzuverfolgen?
Das Obige sind nur persönliche Ansichten und stellen keine Anlageberatung dar.
#newt $NEWT @NewtonProtocol
Doch wenn man der Datenflussrichtung weiter nach unten folgt, wird mir mulmig.
Der Policy-Engine von Newton vertraut RedStone als Preis- und Marktdaten-Ebene. In der Analyse von KuCoin heißt es ganz direkt: „a key risk is concentration. If Newton's policy engine becomes heavily dependent on RedStone pricing, any disruption at the oracle layer could cascade into transaction blocks or freezes across the platform.“ Jede Unterbrechung kann sich zu einer Transaktionssperre auf Plattformebene hochschaukeln.
Eine einzelne Datenquelle bedeutet einen einzelnen Punkt des Versagens. Das Sicherheits-Framework von Chainlink führt „single point of failure / single data source“ längst als eines der fünf größten Oracle-Sicherheitsrisiken auf. Oracle-Server-Ausfälle, manipulierte Daten, Preismanipulation – das sind keine theoretischen Szenarien. Im Oktober 2025 führte ein Marktverkauf von 60 Millionen US-Dollar zu einem Wertverlust von 19,3 Milliarden US-Dollar. Wenn im Oracle ein Riss entsteht, stürzt die gesamte darüberliegende Struktur ein. Wenn RedStones Preiszufuhr manipuliert wird, führen alle automatisierten Strategien, die auf Preisabfragen basieren – DCA, Hedging, Liquidationen – automatisch die falschen Aktionen aus.
Noch beunruhigender ist für mich die Datenherkunft. Die von TEE gelesenen Kursdaten und die Off-Chain-Berechnungsdaten erzeugen lediglich vereinfachte ZK-Beweise. Vollständige Rohdaten werden nicht on-chain gespeichert. Wenn es bei automatisierten Trades zu Verluststreitigkeiten kommt, können Nutzer die ursprünglichen Daten nicht vollständig on-chain nachprüfen und nicht feststellen, ob es ein Oracle-, ein Node- oder ein Smart-Contract-technisches Problem war. Ein „verifizierbares“ System kann an der wichtigsten Datenquelle dennoch keine vollständigen On-Chain-Audit-Hinweise liefern.
„A policy is only as strong as the data behind it.“ So schön die Policy auch ist – wenn die Datenquelle reißt ab, wird sie zu Makulatur. Gibst du deine automatisierten Strategien einem Oraclesystem, das von einem einzigen Punkt abhängt, und wenn es sich irrt, bekommst du dann überhaupt Beweise, um Verantwortung nachzuverfolgen?
Das Obige sind nur persönliche Ansichten und stellen keine Anlageberatung dar.
#newt $NEWT @NewtonProtocol