Letzte Woche bin ich bei einem Airdrop für ein Meme-„Scam-/Hund“-Projekt ge-triggert worden, um vorne mit dabei zu sein, und hab dafür ein Script geschrieben, um massenhaft zu claimen. Ergebnis: Ich hab ein paar hundert Dollar an Gas verbrannt, aber alle Transaktionen sind fehlgeschlagen. Der Grund ist echt absurd: Der Projektbetreiber hat eine Whitelist-Limitierung eingebaut, und meine Adresse ist nicht drin. Aber das Problem ist—ich hatte das Gas schon lange abgezogen. On-Chain wird auch „Erfolg“ angezeigt, aber der Contract vom Projekt schickt mir dann ein Revert. Das Geld ist einfach weg, nicht mal ein Geräusch gehört. Dieses „erst zahlen, dann prüfen“-Spielchen ist in DeFi echt zum Kotzen. Besonders jetzt, wo man AI-Tracking/Copy-Trading und Batch-Interaktionen spielt: Du weißt nie, an welcher Stelle du auf eine Mine trittst.

Also, ich habe in letzter Zeit@NewtonProtocol … jenes Mainnet-Beta gemeint – diese Idee, das Risikomanagement vor die Abbuchung zu verlagern. Die halte ich persönlich für ziemlich gut. Als Beispiel: Früher war es so, als würdest du zuerst eine Eintrittskarte kaufen und in den Vergnügungspark gehen. Dann merkst du, dass man dich an jedem Fahrgeschäft am Eingang aufhält und sagt, du wärst nicht berechtigt – und das Ticketgeld wird nicht erstattet. Newton ist wie ein Sicherheitscheck am Eingang: Der Security scannt deine Ausweisdaten; wenn du nicht durchkommst, lässt er dich direkt abblitzen, damit du nicht Geld für Tickets verschwendest. Dieses „Identity Verification“-Domain wird separat herausgezogen: Sämtliche Compliance-Prüfungen und Berechtigungsvalidierungen laufen schon vollständig ab, bevor deine Transaktion gepackt wird und bevor noch Gas abgezogen wird. Wenn du die Voraussetzungen nicht erfüllst, wird die Transaktion einfach abgefangen – du bekommst nicht mal die Chance, überhaupt on-chain zu gehen. Ein Detail finde ich dabei besonders clever: Es nutzt die Rego-Sprache, damit die Projektseite ihre eigenen Regeln schreiben kann. Was heißt das konkret? Zum Beispiel kann der Projektbetreiber sagen: „Es dürfen nur Adressen interagieren, deren ETH-Balance größer als 1 ist“, oder „für eine einzelne Transaktion gilt ein Limit von 500 U“. Diese Regeln laufen in einer TEE-Umgebung (Trusted Execution Environment), ziehen die nötigen Daten über einen Oracle-Connector, führen dann die BLS-Signatur-Generierung aus und schreiben anschließend die Transaktion on-chain. Die Daten werden zusätzlich in IPFS abgelegt. Auch die Berechtigungen sind viel granularer: Früher bei Autorisierungen für KI-Agenten – entweder gab man alles frei oder gar nichts, so schwarz-weiß wie bei einem Liebesdrama. Newton unterstützt „granulare Autorisierung“: Du kannst z. B. Limits pro Einzeltransaktion setzen, nur bestimmte Assets erlauben und den Betrieb stoppen, wenn die Volatilität über einen gewissen Wert steigt. In Kombination mit Smart Accounts ist es, als würdest du der KI einen Rahmen geben: Sie darf nur innerhalb dieser Grenzen „springen“.

Aber ich muss einen Eimer kaltes Wasser drüberkippen: Das ist natürlich kein Allheilmittel. In meinen Tests gibt es ein paar deutliche Schwachstellen:

Erstens: Es hängt von Oracle-Daten ab. Letzte Woche, als der Markt stark schwankte, konnte ich direkt sehen, dass der Median-Preis zeitverzögert war – fast hätte das mein Risikomanagement zu einer Fehlentscheidung verleitet. Bei extremen Marktphasen wird dieses Timing-Problem noch stärker ins Gewicht fallen.

Zweitens: Die benutzerdefinierten Strategien klingen zwar cool, aber für normale User ist die Einstiegshürde echt nicht niedrig. Ich habe einen Nachmittag lang Rego gelernt – mir ist dabei echt der Kopf heiß geworden. Die meisten werden wahrscheinlich eher mit vorhandenen Templates arbeiten.

Drittens: Die Zahl der angebundenen Projekte ist noch nicht groß. Du kannst natürlich sagen, dass sie es großartig anpreisen – aber wie es sich in einem echten, großflächigen Rollout verhält, muss man abwarten. Dafür braucht es einfach Zeit und echte Ergebnisse.

Ich finde, die Positionierung von Newton ist ziemlich klar: Es geht nicht darum, wie man KI-Transaktionen noch profitabler macht, sondern darum, wie man verhindert, dass KI-Transaktionen völlig aus dem Ruder laufen. Für Szenarien mit niedrigerer Frequenz und hohen Compliance-Anforderungen – etwa DAO-Treasury-Management oder das Ausführen von DCA-/Sparplan-Strategien – ist dieses vorgelagerte Risikomanagement tatsächlich wie eine zusätzliche Sicherheitsstufe. Aber wenn du hochfrequent und mit großen Beträgen in irgendwelche „Dog“-Coins reinballern willst? Dann könnte dich genau diese Lösung eher ausbremsen.

Wenn man sich die Entwicklung von On-Chain-KI bis heute anschaut, ist es mit Autorisierung, Vertrauen und Ausführungssicherheit tatsächlich immer schwieriger geworden. Newton gibt in diese Richtung zumindest ordentlich Gas – auch wenn es noch weit bis zum Ziel ist. Aber die Richtung finde ich zumindest richtig.

Ach ja: Wenn ihr mit On-Chain-Automation spielt – welcher Teil macht euch am meisten Kopfzerbrechen? Sind es die sinnlos verbrannten Gasgebühren, oder ist es eher, dass man die Berechtigungen gibt und dann nicht mehr schlafen kann? Schreibt mal in die Kommentare: Ich beschäftige mich gerade damit, wie man mit KI ein Risk-Management für Grid-Trading macht – falls ihr gute Ansätze habt, nur her damit.

$NEWT #Newt