Ich habe in den letzten Wochen einen guten Teil meiner Zeit damit verbracht, DeFi-Vault-Dokumentationen durchzugehen, und da gab es ein Muster, das mich früher gestört hat: Ein Vault-Curator hält irgendwo eine Reihe von Regeln fest – in einem Dokument, einem Tweet, einem Governance-Forum-Beitrag – aber der Smart Contract selbst hat keine Ahnung davon. Die Regeln leben in einer Zusage. Der Code führt einfach nur aus. Wenn der Curator seine Meinung ändert, kompromittiert wird oder es schlicht falsch versteht, verhindert nichts im Vertrag, dass die Transaktion trotzdem durchgeht.

Genau diese Lücke bildet das Fundament von Newton Protocol – und dessen Mainnet-Beta, die seit dem 23. Juni auf Base und Ethereum live ist, ist der erste echte Versuch, sie auf Vertragsebene zu schließen, statt nur auf Dokumentations-Ebene. Der Vergleich, der bei mir den Groschen hat fallen lassen, ist einer, den das Team selbst verwendet: Karten-Netzwerke bewegen kein Geld, sie autorisieren es, bevor es sich bewegt. Newton versucht, dieser Autorisierungsschritt für Onchain-Transaktionen zu sein – zwischen dem Moment, in dem jemand eine Überweisung anstößt, und dem Moment, in dem sie sich endgültig einpendelt, indem es sie gegen eine Policy prüft und sie nur dann durchwinken lässt, wenn sie erfolgreich ist.

Was mich über den Pitch hinaus hat weiterlesen lassen, war das Operator-Design. Statt dass ein einziger Server entscheidet, ob eine Transaktion konform ist, läuft das bei Newton über ein Netzwerk unabhängiger Operatoren, die durch restaked ETH über EigenLayer abgesichert sind. Jeder Operator erhält dieselbe Transaktion und dieselbe Policy, zieht alle Daten heran, die diese Policy verlangt, und bewertet sie für sich. Wenn Newton über die Beta hinaus skaliert, soll die Autorisierung eine Zustimmung einer ausreichenden Anzahl unabhängiger Operatoren erfordern – nicht nur eines. Wenn ein Operator eine falsche Antwort abnickt, kann er während eines Dispute-Zeitfensters mit einem Zero-Knowledge-Fraud-Proof herausgefordert werden, und er verliert einen Teil seines eingezahlten Kapitals. Das sind echte finanzielle Kosten für einen Fehler – eine andere Art von Garantie als „Vertrauen Sie unserem Bot“.

Das erste Produkt, das darauf aufbaut, sind Vaults – und Magic Labs hat VaultKit zusammen mit der Beta ausgeliefert, damit Kuratoren nicht bei null anfangen und Authorization-Logik selbst schreiben müssen. Stattdessen setzen sie Policies aus bestehenden Datenquellen zusammen: Chainalysis für Sanktionen und Kontrakt-Risiken, RedStone für Preisfeeds, Credora für Sicherheiten und Risiko-Bewertungen, vaults.fyi für Vault-Gesundheitsdaten und Webacy für den Wallet-Ruf. Eine Policy kann sich auf eine dieser Quellen oder mehrere stützen, und Newton prüft all das zum exakten Zeitpunkt, an dem eine Auszahlung oder ein Rebalance andernfalls durchlaufen würde. Euler ist unter den Protokollen, die bereits integriert sind.

Ich würde es nicht so weit nennen, dass es „gelöst“ ist. Es ist Beta, es läuft bisher auf zwei Chains, und eine Policy ist nur so gut wie die Person, die sie schreibt, und wie gut sie die Daten vertraut. Aber die Einordnung von Autorisierung als etwas, das ein Vertrag durchsetzt – statt als etwas, das ein Kurator verspricht – ist der eigentliche Wandel: dasselbe Problem, mit dem sich das klassische Finanzwesen vor Jahrzehnten über Clearinghäuser befasst hat, nur ohne ein einzelnes Unternehmen in der Mitte, das die Prüfung übernimmt. $NEWT ist das native Token des Netzwerks, das für Staking und Governance genutzt wird, während das System weiter dezentralisiert.

Wenn Sie Kurator oder Zuteiler sind, lohnt es sich, sich die Dokumentation und den Newton Explorer selbst anzusehen, bevor Sie irgendetwas davon weitergeben.

Geschrieben im Rahmen einer Content-Kooperation mit @NewtonProtocol . #Newt #DEFİ #protocol