Nachdem ich die offizielle Dokumentation und das GitHub-Repository von $NEWT VaultKit komplett durchgesehen hatte, ist mir ein interessantes Phänomen aufgefallen: Die Funktionalität ist zwar wirklich stark, aber die Einstiegshürde könnte deutlich höher sein, als es das offizielle Marketing vermuten lässt.

Laut der offiziellen Aussage ermöglicht VaultKit Curator, die Autorisierungslogik nicht von Grund auf neu aufzubauen und stattdessen dem Tresor konforme Regeln hinzuzufügen. Das klingt nach einem Compliance-Toolset, das man einfach einsteckt und sofort verwenden kann – Ausgabenobergrenzen, Anforderungen an Sicherheiten, Checks der Gegenparteien: Alle Regeln sollen sich automatisch vor der Transaktionsabwicklung ausführen lassen. Aber nachdem ich das einmal anhand der Doku durchlaufen habe, stellte sich heraus, dass es doch nicht so einfach ist

Ich bin kein Einsteiger, aber schon beim ersten Schritt bin ich hängen geblieben.

Das Installieren des SDK, das Konfigurieren der Umgebungsvariablen und das Initialisieren einer VaultKit-Instanz – der Ablauf ist zwar klar. Aber als ich versuchte, die Sanctions-Checks-Policy von Chainalysis anzubinden, stellte sich heraus, dass ich zusätzlich einen API Key beantragen muss. Außerdem passen das Newton-Policy-Format und das von Chainalysis zurückgegebene Format nicht 1:1 zusammen – ich muss selbst eine Transformationslogik schreiben. Die offizielle Doku sagt nur „Chainalysis integriert“, aber nicht „Chainalysis zu halb integriert – die andere Hälfte musst du selbst nachbauen“.

Noch subtiler ist die Fehlerbehandlung.

Ich habe absichtlich auf dem Testnet ein Policy-Format eingereicht, das fehlerhaft ist. Die von VaultKit zurückgegebene Fehlermeldung besteht nur aus einer Zeile – „policy evaluation failed“. Es wird nicht konkret erläutert, an welcher Stelle das Problem liegt: Ist die Datenquelle nicht erreichbar? Oder liegt ein Syntaxfehler in der Regel vor? Oder fehlt die Berechtigung? Ich habe in den GitHub-Issues nachgesehen und festgestellt, dass nicht nur ich dieses Problem habe. Die offizielle Antwort lautet: „Wir optimieren gerade das Error Reporting.“ Doch „gerade optimieren“ bedeutet: Im Moment ist es noch nicht so weit.

Ich habe andere Produkte genutzt und möchte darüber einfach mal ablästern.

OpenZeppelin Defender hat ein detailliertes Logging- und Alarmierungssystem, und Tenderly kann Transaktionen simulieren und für jeden Schritt einen Trace ausgeben. Newtons VaultKit wirkt jetzt eher wie ein „Tool, das läuft“, statt wie ein „Tool, das sich gut debuggen lässt“. Für institutionelle Curators wirkt sich das direkt auf die Betriebseffizienz aus – eine Policy einzurichten dauert halb einen Tag zum Debuggen, wer hält das schon aus?

Auch die Daten auf dem Newton Explorer bestätigen dieses Problem indirekt. Im aktuellen Mainnet-Beta wächst die Zahl aktiver Curators sehr schnell, aber die meisten sind nur Testläufe für einfache Policies. Die tatsächliche Nutzungsquote für kombinierte Policies ist extrem niedrig, während die Ausfallrate sehr hoch ist. Das zeigt: Die Bedienbarkeit des SDK hält noch nicht mit der Komplexität der Funktionen Schritt – man kann zwar komplexe Regeln bauen, aber das Debuggen ist schmerzhaft@NewtonProtocol .

VaultKit ist #Newt das wertvollste umgesetzte Produkt, und das Funktionsdesign zielt auch wirklich auf den Compliance-Bedarf in den institutionellen Tresoren ab. Aber die Entwicklererfahrung mit dem aktuellen SDK hat noch deutliche Schwächen – die Doku sagt nur, „was man machen kann“, aber nicht, „wie mühsam das ist“. Selbst wenn die Authorization Layer noch so stark ist: Wenn Curator nicht sauber eingerichtet werden kann, bleibt es am Ende nur eine Ansammlung schicker Dokumentation. Erst wenn Magic Labs das Error Reporting und die Tools zum Debuggen von Policies so optimiert hat, ist VaultKit wirklich bereit, das Kapital institutioneller Kunden zuverlässig zu übernehmen. Aber im Moment will ich einfach mal die Maus weglegen und ein paar Runden spielen, um mich zu entspannen.