Vor ein paar Wochen sah ich immer wieder @NewtonProtocol , die durch die vertraute Sprache von KI-Agenten und Onchain-Automatisierung beschrieben wurden. Die Grundidee klang zwar nützlich, aber nicht gerade überraschend: Nutzer definieren eine Aufgabe, Software führt sie aus, und die Blockchain-Infrastruktur macht das Ergebnis überprüfbar.
Das war zumindest mein erster Eindruck.
Ich habe angefangen, mehr zu lesen, weil ich verstehen wollte, was „verifizierbare Automatisierung“ in der Praxis eigentlich bedeutet. Wollte Newton vor allem beweisen, dass ein Agent eine Transaktion korrekt abgeschlossen hat? War das ein weiterer Marktplatz für automatisierte Strategien? Oder war der wichtige Teil woanders im Spiel?
Die Policy-Ebene hat verändert, wie ich es gesehen habe.
Newton ist um Regeln herum entworfen, die vor der Ausführung sensibler Onchain-Aktionen geprüft werden können. Diese Policies können Grenzen, Berechtigungen, Marktbedingungen, Autorisierungsanforderungen oder andere Einschränkungen definieren. Eine Transaktion, die gegen die relevante Policy verstößt, kann gestoppt werden, bevor Gelder bewegt werden—statt sie nur nachträglich als Problem zu identifizieren.
Das ist spannender als Automatisierung allein.
Automatisierung beantwortet eine praktische Frage: Kann Software die Aufgabe ausführen?
Die Policy-Ebene beantwortet eine wichtigere Frage: Soll diese konkrete Aktion unter diesen Bedingungen erlaubt sein?
Ich kann nachvollziehen, warum diese Architektur nützlich ist. Einer KI-Agentin oder einem KI-Agenten uneingeschränkte Kontrolle über ein Wallet zu geben, ist unangenehm, besonders wenn der Agent mit volatilen Märkten, unbekannten Verträgen oder großen Guthaben interagiert. Eine Policy könnte die Assets einschränken, die er verwenden darf, die Transaktionsgröße begrenzen, bestimmte Marktbedingungen verlangen oder Aktionen blockieren, die außerhalb einer genehmigten Strategie liegen.
Anstatt darauf zu vertrauen, dass der Agent jede Grenze im Gedächtnis behält, versucht das System, diese Grenzen zur Ausführungszeit durchzusetzen.
Doch eine Unterscheidung ließ mich nicht los.
Ein Policy-Engine kann prüfen, ob eine Aktion den Regeln folgt. Sie kann jedoch nicht automatisch beweisen, dass die Regeln selbst sinnvoll sind.
Zunächst behandelte ich „verifizierbar“ als etwas, das nahe an „sicher“ liegt. Bei genauerem Hinsehen merkte ich, dass das keine gleiche Behauptung ist. Newton kann helfen nachzuweisen, dass eine Operation zu einem bestimmten Zeitpunkt einer definierten Policy entsprach. Das ist wertvoll. Doch die Qualität des Ergebnisses hängt weiterhin davon ab, wer die Policy entworfen hat, welche Informationen sie verwendet hat und welche Situationen der Autor nicht voraussehen konnte.
Betrachte ein Treasury, das einem automatisierten Agenten erlaubt, Stablecoin-Bestände zu rebalancieren. Seine Policy könnte sagen, dass der Agent pro Transaktion nicht mehr als 10% des Treasuries bewegen darf und nur genehmigte Protokolle verwenden kann.
Der Agent befolgt diese Regeln vollkommen.
Dann beginnt ein genehmigter Stablecoin, Marktvertrauen zu verlieren. Der Agent weist weiterhin in ihn zu, weil das Asset weiterhin auf der genehmigten Liste steht und die geschriebenen Bedingungen nicht aktualisiert wurden. Technisch gesehen hat das Policy-System funktioniert. Die Aktion wurde genau so autorisiert, wie sie entworfen wurde. Das unerwünschte Ergebnis entstand durch eine unvollständige Policy, nicht durch eine fehlgeschlagene Durchsetzung.
Dieses Beispiel trifft auf das, was ich jetzt als Newtons tiefere Herausforderung sehe.
Wer ist dafür verantwortlich, menschliche Absichten in maschinenwirksame Regeln zu übersetzen?
Die meisten Nutzer denken nicht von Natur aus an Sonderfälle, Oracle-Ausfälle, ungewöhnliche Liquiditätsbedingungen oder sich widersprechende Einschränkungen. Entwickler können möglicherweise detaillierte Policies schreiben, aber normale Nutzer werden wahrscheinlich auf Vorlagen, Anwendungen, Risikodienstleister oder Institutionen angewiesen sein, um diese Grenzen für sie zu definieren.
Das schafft eine neue Angriffs- bzw. Vertrauensfläche. Wir müssen der Ausführung vielleicht weniger blind vertrauen, aber wir müssen die Menschen und Prozesse hinter der Policy trotzdem bewerten.
Das Risiko steigt, je autonomer die Automatisierung wird. Ein schlecht entworfenes Regelwerk, das ein kleines experimentelles Wallet betrifft, ist das eine. Der gleiche Fehler in einem institutionellen Treasury, einem Zahlungssystem oder einem Netzwerk interagierender Agenten könnte sich über Tausende von Transaktionen wiederholen, bevor irgendjemand das Muster vollständig versteht.
Das macht die Policy-Ebene nicht weniger wertvoll. Es macht sie zum zentralen Bestandteil des Systems.
Der native Token von Newton, NEWT, könnte irgendwann anhand der Teilnahme an der Sicherheits- und Autorisierungsinfrastruktur des Protokolls bewertet werden, aber ich bin noch nicht bereit, allein aus der Erzählung eine starke Markteinschätzung abzuleiten. Die Technologie ist interessant; die Token-These hängt weiterhin von sinnvollen Integrationen, einer anhaltenden Nutzung und dem Nachweis ab, dass eine autorisierungsbasierte Policy die Probleme löst, vor denen Nutzer bereit wären, zu bezahlen.
Ursprünglich sah ich Newton als Infrastruktur, die Agenten hilft, Dinge automatisch zu tun. Jetzt sehe ich es eher als Infrastruktur, die festlegt, was Agenten tun dürfen.
Das ist eine stärkere Idee, führt aber auch zu einer schwierigeren Frage: Wenn Maschinen Regeln perfekt befolgen können, wie viel Aufmerksamkeit schenken wir dann den Menschen, die sie schreiben?