$NEWT Ich komme immer wieder darauf zurück, wie lautlos Vaults zu einem der größten Produkte in Krypto wurden.
Nicht lange her war ein Vault größtenteils nur ein Smart Contract, der ein paar Assets hielt und Yield verteilte. Heute schauen wir auf Milliarden US-Dollar, die in 3.700 Vaults über 80 verschiedene Chains hinweg gebunden sind. Das ist kein Nischenexperiment mehr. Das ist echte Infrastruktur, die Millionen Menschen und Institutionen tatsächlich nutzen.
Yield wurde ziemlich früh programmierbar. Du konntest Strategien festlegen, das Compounding automatisieren und Allokationen anhand von Bedingungen anpassen. Die Geld-Seite der Vaults wurde schnell ausgeklügelt. Aber die Regeln-Seite – wer was tun darf, wann und unter welchen Bedingungen – blieb erstaunlich primitiv.
Die meisten Vaults verlassen sich noch immer auf Logik, die entweder im Vertrag hardcodiert ist oder erst nachträglich durchgesetzt wird. Willst du ein tägliches Ausgabenlimit für einen Treasury-Vault hinzufügen? Viel Erfolg damit, es zu aktualisieren, ohne neu zu deployen. Willst du bestimmte Adressen einschränken oder Compliance-Checks hinzufügen, die sich weiterentwickeln? Am Ende schreibst du normalerweise fragile „if else“-Statements, die zum technischen Schuldenberg werden, sobald sich Anforderungen ändern. Und wenn etwas schiefgeht, ist es oft chaotisch oder unmöglich zu beweisen, was hätte passieren sollen versus was tatsächlich passiert ist.
Man, ich denke schon länger über diese Lücke nach. Yield bekam die Werkzeuge, um zu skalieren. Regeln haben nie wirklich das nötige bekommen.
Das Problem mit „Regeln“ in heutigen Vaults
Wenn du Tausende von Vaults hast, die ernsthaftes Kapital über Dutzende von Chains verwalten, bricht der alte Ansatz in ein paar offensichtlichen Punkten zusammen.
Erstens: Regeln sind meistens reaktiv statt präventiv. Eine Transaktion führt entweder aus oder nicht – abhängig von der Logik, die beim Deployment geschrieben wurde. Es gibt nur sehr wenig Möglichkeit, komplexe Bedingungen zu prüfen, bevor überhaupt etwas endgültig wird.
Zweitens: Regeln zu aktualisieren ist schmerzhaft. Die meisten Vault-Architekturen wurden nicht dafür entwickelt, dass Policies eine erstklassige, aktualisierbare Sache sind. Berechtigungen zu ändern oder neue Einschränkungen hinzuzufügen bedeutet oft, den Kernvertrag anzufassen – genau das willst du nicht tun, wenn Milliarden auf dem Spiel stehen.
Drittens: Es gibt fast keine standardisierte Möglichkeit zu beweisen, dass Regeln befolgt wurden. Wenn ein Regulierer, ein Auditor oder sogar ein anderes Protokoll verifizieren will, dass eine Transaktion bestimmte Grenzen oder Compliance-Anforderungen eingehalten hat, müssen sie üblicherweise dem Vault-Betreiber vertrauen oder den Vertrag rückentwickeln. Das skaliert nicht.
Ich bin ehrlich: Früher dachte ich, das sei nur eine Unannehmlichkeit, die Teams irgendwann schon hinbekommen. Aber je mehr Vaults wuchsen, desto deutlicher wurde: Das ist keine kleine Lücken im Tooling. Es ist ein grundlegendes Infrastrukturproblem.
Was „Regeln sollten auch programmierbar sein“ wirklich bedeutet
Die Linie, die mir an Newtons Einordnung hängen blieb, ist simpel, aber mächtig: Yield ist bereits programmierbar. Regeln sollten es auch sein. Onchain geschrieben, auf Protokollebene vor der Ausführung durchgesetzt.
Das ist die Verschiebung, auf die Newton sich fokussiert.
Statt Regeln in jeden einzelnen Vault-Vertrag einzubacken (und sie dann mühevoll zu pflegen), ermöglicht Newton dir, Policies in einer richtigen Policy-Sprache zu definieren – Rego –, die außerhalb der Ziel-Chain lebt. Diese Policies können komplex, bedingt und kombinierbar sein. Noch wichtiger: Sie werden ausgewertet, bevor sich irgendetwas per Transaktion endgültig absetzt.
Wenn die Policy es erlaubt, gibt Newton eine signierte Attestation aus – eine kryptografische Beweisführung, dass die Aktion gemäß den Regeln autorisiert war. Erst dann wird die Transaktion fortgesetzt. Wenn die Policy es blockiert, wird die Transaktion erst gar nicht ausgeführt.
Das verändert das Spiel für Vault-Betreiber und Nutzer in ein paar praktischen Punkten.
Du kannst jetzt ausgeklügelte Regeln setzen – Spend Limits, Zeitfenster, erlaubte Gegenparteien, Risikoparameter, Compliance-Einschränkungen – ohne deinen Vault-Vertrag in ein nicht wartbares Chaos zu verwandeln. Du kannst diese Regeln aktualisieren, ohne die zentrale Logik neu zu deployen. Und weil die Durchsetzung auf Protokollebene mit verifizierbaren Attestationen erfolgt, bekommst du etwas, das zuvor fehlte: nachweisbare, auditierbare Autorisierungs-Historie.
Warum das wichtig ist, wenn du 3.700 Vaults hast
Das Skalieren macht die alte Art, Dinge zu tun, unhaltbar.
Wenn es Tausende von Vaults über 80 Chains gibt, die Milliarden halten, kannst du nicht darauf vertrauen, dass jedes Team seine eigenen Permission-Systeme manuell richtig härten kann. Du brauchst eine standardisierte Schicht, die konsistent funktioniert. Du brauchst Regeln, die einmal geschrieben und über unterschiedliche Chains angewendet werden können, ohne für jede Umgebung neu geschrieben zu werden. Und du brauchst Durchsetzung, die passiert, bevor Geld bewegt wird – nicht danach.
Newtons Ansatz – Policy-Auswertung außerhalb der Ziel-Chain – ist dafür besonders gut geeignet. Die gleiche Policy kann für Vaults auf mehreren Chains gelten. Updates verbreiten sich sauber. Und die signierten Attestationen erzeugen eine verifizierbare Historie, die nicht vom Wort einer einzelnen Partei abhängt.
Ich habe zu viele Projekte gesehen, bei denen „Governance“ oder „Permissions“ entweder zu starr oder zu locker wurden, weil es keine gute Mittelposition gab. Newton versucht, genau diese Mittelposition zu schaffen: programmierbar genug, um echte Komplexität zu bewältigen, durchsetzbar genug, um Kapital tatsächlich zu schützen, und verifizierbar genug, um externe Anforderungen zu erfüllen.
Das große Ganze – zu dem ich immer wieder zurückkomme
Was mich an dieser Richtung am meisten begeistert, ist, wie gut sie zu dem passt, wohin sich die Branche tatsächlich entwickelt.
Wir bewegen uns hin zu mehr institutionellem Kapital, mehr tokenisierten Real-World-Assets und mehr autonomen Agents, die mit Vaults interagieren. All diese Use Cases brauchen ausgeklügelte Regeln – nicht nur „jeder mit dem Private Key kann alles bewegen“.
Parallel sehen wir in vielen Jurisdiktionen den regulatorischen Druck steigen. Ein System zu haben, das kryptografischen Beweis dafür liefern kann, dass Transaktionen definierte Policies befolgt haben, ist nicht mehr nur „nice to have“. Es wird zunehmend zur Voraussetzung für ernsthafte Akzeptanz.
Newton versucht nicht, Vaults zu ersetzen oder ein weiteres Yield-Optimierer-Projekt zu werden. Newton konzentriert sich auf die Autorisierungsschicht, die vor der Ausführung sitzt. Diese enge Fokussierung macht es gerade so relevant. Während alle anderen darum kämpfen, wer die besten Strategien oder die höchsten APYs hat, arbeitet Newton an der Infrastruktur, die es ermöglicht, dass diese Strategien sicher und im großen Maßstab tatsächlich funktionieren.
Ich bin ehrlich: Infrastrukturarbeit wie diese bekommt selten die Aufmerksamkeit, die sie verdient, bis etwas kaputtgeht. Aber wenn du dir 3.700 Vaults ansiehst, die Milliarden über 80 Chains halten, ist die Frage nicht, ob eine bessere Regel-Durchsetzung nötig ist. Die Frage ist, wie lange wir ohne sie weiterlaufen können.
Newtons These ist, dass die Zeit für „wir hardcoden es einfach und hoffen auf das Beste“ vorbei ist. Yield ist programmierbar geworden. Jetzt erhält auch das Regeln-System die gleiche Behandlung: onchain geschrieben, vor der Ausführung durchgesetzt und durch verifizierbare Attestationen untermauert.
Das ist die Lösung, die tatsächlich zu der Größe und Bedeutung passt, die Vaults still und leise erreicht haben.
Das fühlt sich an wie eines dieser Infrastruktur-Updates, die im Rückblick offensichtlich wirken. Die eigentliche Frage ist jedoch, wie viele Vault-Teams und Nutzer es übernehmen, bevor der nächste große Vorfall allen die Hand erzwingt. @NewtonProtocol #Newt