Die Vermögenswerte von DeFi-Nutzern sind nicht mehr etwas, das dauerhaft in einem einzigen Protokoll „abgestellt“ bleibt. Durch Ertragsverlagerungen, Airdrop-Anreize und Protokoll-Upgrades ändert sich unsere Position nahezu jeden Monat. Die Vertrags-Migrationsvorlage, die Newton Protocol bereitstellt, sollte eigentlich zur Basisinfrastruktur für solche häufigen, dynamischen Moves werden. In der Praxis wirkt sie jedoch eher wie ein spezialisiertes kleines Schalter-Tool, das nur einen einzelnen Anwendungsfall handhaben kann.
Die Kernlogik der Vorlage besteht darin, die beiden Schritte „die alte Vertragsautorisierung widerrufen + neue Vertrags-Einzahlung“ zu einem atomaren Transaktionseinheits-Paket zusammenzufassen. In einer TEE-Umgebung wird dies mit einem Session Key signiert, und der Agent führt es einmalig vollständig aus. Das löst das Problem von Autorisierungslücken bei manuellen Abläufen und verhindert, dass z. B. Trittbrettfahrer oder Zwischenkomponenten Arbitrage betreiben. Genau diesen Punkt sehe ich genauso – und derzeit kann das weder die MetaMask-Wallet noch irgendeine Multisig-Lösung leisten.
Doch da stellt sich die Frage: In den heutigen DeFi-Migrationsszenarien handelt es sich bei der großen Mehrheit nicht einfach um ein Upgrade von Verträgen innerhalb desselben Protokolls, sondern um eine Neukonfiguration über Protokolle hinweg – oder sogar über Chains hinweg. Wenn zum Beispiel der Nutzer auf Aave die Einzahlungrendite senkt und zu einem bestimmten Morpho-Tresor migrieren möchte, geht es nicht nur um Abheben und Einzahlen: Dazu gehören auch die Pfadauswahl, Slippage-Kontrolle und der Abgleich von Oracle-Preisen. Wenn zwischendurch noch ein Cross-Chain-Schritt nötig ist, wächst die Anzahl der Aktionen schnell explodierend.
Die derzeitigen Migrations-Templates von Newton decken die oben genannten Anforderungen überhaupt nicht ab. In den Template-Parametern können Sie lediglich die alte Vertragsadresse, die neue Vertragsadresse und den Migrationsbetrag eingeben. Diese Kombination wirkt zwar „programmierbar“, aber im aktuellen Produktkontext kann der Nutzer die Vorlagen nicht so nutzen, dass mehrere DeFi-Protokolle miteinander verknüpft werden. Anders gesagt: Die Migration wird zu einem Zug, der nur einen Schritt erlaubt, während ein echtes Brett eine Zugfolge mit drei Schritten braucht.
Der Grund dafür liegt vermutlich in den zusammengesetzten Bedingungen. Sobald man erlaubt, über Protokolle hinweg zu migrieren, muss man zwangsläufig Bedingungsprüfungen einführen: Reicht das TVL im neuen Pool aus? Liegt der implizite Slippage über der Renditedifferenz? Wie steht es um das Audit-Risiko des neuen Protokolls? Ein solches Bedingungsnetz kann die Strategieebene von Newton aktuell nicht vollständig tragen. Das Team setzt daher Priorität auf eine einzelne Vertragsmigration – möglicherweise, um die Grenzen für Compliance und Sicherheit sauber einzuhalten.
Aber inzwischen vergleichen Community-Spieler bereits mit anderen Tools. Zum Beispiel über DeFi Saver automatisierte Recipes oder indem man selbst mit Gelato eine einfache Task schreibt – damit lässt sich bereits ein portiatsübergreifendes, bedingungsbasiertes automatisches Umschichten umsetzen. Auch wenn es keine TEE-gesicherte Ausführung nutzt, ist für viele Nicht-„Big Whale“-Nutzer die Sicherheit nicht wichtiger als die Flexibilität.
Wenn Newton in der Narrative „On-Chain autonome Agenten“ die Nase vorn haben will, muss es die Migrations-Templates von „eins-zu-eins umbinden“ zu „eins-zu-viele-Routing“ weiterentwickeln. Selbst wenn die erste Version den Nutzern nur eine Protokoll-Whitelist bietet, damit der Agent innerhalb dieser Liste anhand von aktuellem APY oder Gas automatisch das Migrationsziel auswählt, würde das die Nutzungshäufigkeit stark erhöhen.
Ein weiteres vielversprechendes Einsatzgebiet ist die Kombination mit einem Reinvestitions-Template: So etwas wie „dynamisches Umschichten mit Zinseszins“ – wenn der Agent erkennt, dass die Rendite im Zielpool kontinuierlich sinkt, schaltet er automatisch die Reinvestitionsgebote um. Das ist wirklich eine DeFi-Autopilot-Anwendung. Doch aktuell müssen Nutzer noch alle paar Tage manuell nachsehen, wie sich die Rendite entwickelt, und dann selbst entscheiden, ob sie umschichten oder nicht.$BTC
Ich bezweifle keinen Moment, dass das Newton-Team diese Szenarien sieht. Der Weg dorthin ist aber lang. Ich hoffe, dass man in den nächsten Updates erkennt, dass die Migrations-Templates nicht mehr nur auf dieses kleine Feld „Vertrags-Upgrade“ fokussiert sind, sondern sich mutig den realen Anforderungen an mehr Asset-Fluss widmen. Erst dann „wohnt“ dieser Agent wirklich in den Geldbörsen der Nutzer.