Wie Concrete den NAV verwaltet: Die Accounting-Ebene hinter institutionellem DeFi

Das Problem mit Echtzeit-Vaults

Jeder Vault-Anteil stellt einen Anspruch auf die zugrunde liegenden Vermögenswerte dar. Die Frage ist, ob der Preis, der zum Prägen und Einlösen dieser Anteile verwendet wird, tatsächlich korrekt ist.

Im traditionellen Finanzwesen bewegt sich der NAV(1) langsam. Die meisten Fonds verwenden eine Vorwärtspreisgestaltung, bei der Einlagen später über gestaffelte Eintrittsfenster abgerechnet werden, was das Risiko veralteter Preisbildung auf natürliche Weise begrenzt.

DeFi ändert das grundlegend. Damit Vault-Anteile über Kreditmärkte, Hebelmechanismen und On-Chain-Finanzsysteme hinweg komponierbar bleiben, müssen Einlagen atomar erfolgen, während die zugrunde liegenden Strategien und Buchhaltungssysteme asynchron über Chains, Handelsplätze und Ausführungsumgebungen hinweg aktualisiert werden.

Das schafft eine gefährliche Lücke zwischen dem, was der Vault tatsächlich besitzt, und dem, was er zu besitzen glaubt.

Sobald Kapital kontinuierlich bewegt werden kann, ist der NAV keine reine Berichtsfunktion mehr, sondern wird zur Kerninfrastruktur. Jede Einlage, jeder Rückkauf, jedes Rebalancing und jede Abrechnung hängt von der Integrität des Preises ab, der genau in diesem Moment verwendet wird. Ein veralteter NAV ist kein kosmetisches Problem; er ist ein Werttransferereignis.

Wenn Einlagen zu veralteten Salden bepreist werden, subventionieren neue Nutzer die bestehenden Anteilsinhaber. Wenn Rückkäufe zu veralteten Preisen abgerechnet werden, entziehen austretende Nutzer dem Vault Wert. Und wenn eine Strategie Verluste erleidet, bevor die NAV-Aktualisierungen nachkommen, können neue Einlagen unwissentlich beeinträchtigte Bestände zu Preisen vor dem Verlust kaufen. Keiner dieser Fehler taucht im angegebenen APY auf, aber sie sind von Bedeutung.

Dies ist das verborgene Infrastrukturproblem hinter institutionellem DeFi, und genau deshalb hat Concrete ein Echtzeit-NAV-Managementsystem entwickelt, das für asynchrone On-Chain-Finanzierung ausgelegt ist.

Die meisten Vault-Systeme basierten auf dieser Annahme: Strategien waren vollständig On-Chain, und die Ertragsgenerierung war programmatisch. Kapital bewegte sich durch Smart Contracts, Positionen wurden deterministisch aktualisiert, und die Buchhaltung konnte direkt in den Vault selbst codiert werden. Solange Strategien vollständig On-Chain lebten, blieb der NAV relativ einfach zu berechnen, da der Vault stets unmittelbare Einsicht in seine zugrunde liegenden Positionen und Salden hatte.

Diese Annahme bricht, sobald sich Vaults über reine Smart-Contract-Strategien hinaus entwickeln.

Moderne Vault-Systeme verlassen sich zunehmend auf aktive Ausführung, kuratorgesteuerte Allokationen, kettenübergreifende Bereitstellung und Off-Chain-Erträge, die nicht in Echtzeit On-Chain abgebildet werden können. Strategien operieren jetzt über Bridges, Perpetual-Derivatebörsen, Geldmärkte, Restaking-Systeme und Liquiditätspools hinweg, alle mit unterschiedlichen Abwicklungszeiten, Meldeverzögerungen und Liquiditätseigenschaften. In manchen Fällen hängt der relevante Positionsstatus von Verwahrstellenaufzeichnungen, Handelsplatzdaten, kettenübergreifenden Abrechnungen oder Off-Chain-Ausführungsprotokollen ab, die nicht mit der gleichen Geschwindigkeit On-Chain abgebildet werden können wie ein einfacher Token-Saldo.

Die Folge ist, dass sich Kapital kontinuierlich bewegt, während sich der zugrunde liegende Zustand des Vaults asynchron aktualisiert, was eine gefährliche Lücke zwischen dem schafft, was der Vault tatsächlich besitzt, und dem, was er zu besitzen glaubt.

In dieser Lücke entweicht Wert.

Preislatenz ist kein operativer Reibungsverlust, sondern ein verborgener Risikotransfer. Je schneller sich DeFi bewegt, desto wichtiger wird die Integrität der Buchhaltung.

NAV-Management für On-Chain-Finanzierung

Concrete betrachtet den NAV als Systemproblem und nicht als einzelnes Orakel oder einzelne Buchhaltungsaktualisierung. Die Architektur kombiniert Glättungsmodelle, dynamische Risikoschwellen, unabhängige Verifikation, Einlagenkontrollen und automatische Pausierungsmechanismen in einem einheitlichen Rahmenwerk, das darauf ausgelegt ist, die Vault-Preisbildung auch unter volatilen Marktbedingungen genau zu halten.

Die erste Herausforderung ist Rauschen. Rohe Preisdaten sind von Natur aus unvollkommen. Brückenverzögerungen, veraltete APIs, vorübergehende Liquiditätsstörungen und asynchrone Abwicklungsereignisse können alle die kurzfristige Buchhaltung verzerren. Concrete glättet NAV-Beobachtungen mithilfe eines exponentiell gewichteten gleitenden Durchschnitts (EWMA), sodass aktuelle Beobachtungen stärker gewichtet werden, während isolierte Spitzen und vorübergehende Anomalien gefiltert werden.(2) Ziel ist es nicht, Volatilität zu unterdrücken, sondern den Einfluss isolierter Datenunregelmäßigkeiten auf die Vault-Preisbildung zu begrenzen.

Aber Glättung allein reicht nicht aus, da sich jeder Vault anders verhält. Eine delta-neutrale Carry-Strategie hat ein völlig anderes Volatilitätsprofil als ein gehebelter Restaking-Vault. Eine Bewegung von 50 Basispunkten kann für eine Strategie unbedeutend und für eine andere katastrophal sein. Concrete kalibriert jeden Vault unabhängig, indem Pausenschwellen an rollierende Volatilitätsmessungen gekoppelt werden, die aus einem Zwei-Wochen-Standardabweichungsmodell abgeleitet werden.(3) Die Schwellen werden in stabilen Perioden automatisch enger und in volatilen Umgebungen weiter, sodass das Risikomanagement dynamisch auf das Verhalten der zugrunde liegenden Strategie reagieren kann, anstatt auf statischen Annahmen zu beruhen.

Verifikation vor Abwicklung

Selbst dann ist Geschwindigkeit ohne Verifikation keine institutionelle Infrastruktur. Jede NAV-Aktualisierung innerhalb von Concrete durchläuft einen Drei-Parteien-Verifikationsprozess. Ein Transaktionsvorschlagender berechnet das vorgeschlagene Update anhand von Strategie- und Buchhaltungsdaten. Ein unabhängiger Unterzeichner validiert das Update anhand einer separaten Buchhaltungsquelle. Schließlich lehnt der Smart Contract selbst Updates ab, die außerhalb vordefinierter Buchhaltungsgrenzen liegen.(4) Durch dieses Design kann kein einzelner Betreiber, einschließlich Concrete, die Vault-Buchhaltung unilateral außerhalb der vom Smart Contract durchgesetzten Grenzen ändern. Der Zweck des Systems ist nicht nur operative Redundanz; es soll das Risiko verringern, dass schlechte Daten, veraltete Meldungen oder Bedienungsfehler direkt die Preisbildungsebene beeinflussen, gegen die Nutzer Transaktionen durchführen.

Preisintegrität ist jedoch nur die Hälfte des Problems. Selbst perfekt verifizierte Buchhaltungssysteme können die Latenz zwischen Marktereignissen und Abwicklungsaktualisierungen nicht beseitigen.

Die Verifikation stellt sicher, dass der gemeldete NAV korrekt ist. Die Abwicklungsintegrität stellt sicher, dass Nutzer zu diesem NAV fair handeln, während sich der zugrunde liegende Zustand des Vaults weiterhin asynchron aktualisiert.

Ziel ist es nicht, Latenz vollständig zu beseitigen. Ziel ist es, zu verhindern, dass vorübergehende Unsicherheit zu dauerhaftem Wertverlust wird.

Schutz des nächsten Einlegers

Dies wird besonders wichtig bei wesentlichen Verlustereignissen, und hier werden die meisten DeFi-Pausensysteme grundlegend missverstanden. Pausierungsmechanismen werden oft als operative Sicherheitsmaßnahmen dargestellt, die Protokolle oder Betreiber schützen. In Wirklichkeit existieren sie, um den nächsten Einleger zu schützen.

Wenn eine Strategie einen wesentlichen Verlust erleidet, bevor der NAV vollständig aktualisiert ist, ist das schlechtestmögliche Ergebnis, dass neue Einlagen weiterhin zu veralteten Preisen in den Vault fließen können. Diese Nutzer kaufen effektiv beeinträchtigte Bestände, ohne es zu merken. Concretes Pausenarchitektur ist speziell für dieses Szenario ausgelegt. Wenn Abweichungen zwischen der Live-Beobachtungsschicht und dem geglätteten Preismodell volatilitätsangepasste Schwellen überschreiten, ist das System darauf ausgelegt, Einlagen zu stoppen, bis die Preisintegrität wiederhergestellt ist.(5) Der Zweck ist nicht operative Bequemlichkeit; es soll das Risiko verringern, dass Verluste unbeabsichtigt auf alle Teilnehmer verteilt werden.

Abhebungen führen das gleiche Problem in umgekehrter Richtung ein. Wenn Kapital nach Einleitung eines Auszahlungsantrags weiterhin eingesetzt bleibt, generiert es weiterhin Erträge und ist weiterhin Risiken ausgesetzt. Nutzer als ausgestiegen zu behandeln, bevor Positionen tatsächlich aufgelöst sind, erzeugt eine Diskrepanz zwischen wirtschaftlichem Engagement und buchhalterischer Realität.

Concretes asynchrone Vault-Architektur verwendet ERC-4626-kompatible Epochen-Auszahlungswarteschlangen, die Rückkäufe gegen den NAV zum Zeitpunkt der Abwicklung abrechnen, nicht zum Zeitpunkt des Antrags.(6) Das Prinzip ist einfach: Wenn Gelder weiterhin dem Strategierisiko ausgesetzt sind, müssen sie auch den daraus resultierenden NAV-Änderungen ausgesetzt bleiben. Alles andere schafft Arbitragemöglichkeiten und unfaire Werttransfers zwischen Teilnehmern.

Das Produkt ist der Stack

Entscheidend ist nicht die einzelne Kontrollebene, sondern wie die Ebenen sich gegenseitig verstärken. Glättung ohne adaptive Schwellen wird zu starr. Schwellen ohne Verifikation führen operationelles Risiko ein. Verifikation ohne Einlagenkontrollen setzt Nutzer während Latenzfenstern weiterhin Risiken aus. Einlagenobergrenzen ohne Pausensysteme erlauben weiterhin beeinträchtigte Preisereignisse. Und Pausensysteme ohne eine kohärente Auszahlungsarchitektur lassen dennoch Wert bei Rückkäufen entweichen.

Das Produkt ist nicht der EWMA. Das Produkt sind nicht die Einlagenobergrenzen. Das Produkt ist nicht die automatisierte Buchhaltung.

Das Produkt ist der Stack.

Institutionelle Kapitalallokatoren bewerten Vaults nicht nur anhand der Rendite. Sie bewerten Buchhaltungsintegrität, operationelle Kontrollen, Preisgenauigkeit und das Design zur Verlustminderung. Dies ist die Infrastrukturschicht, die erforderlich ist, damit DeFi über spekulative Kapitalflüsse hinaus reifen und sich zu einer programmierbaren Finanzinfrastruktur entwickeln kann, die institutionelles Kapital unterstützen kann.

Concretes System ist so ausgelegt, dass NAV-Aktualisierungen unabhängig verifiziert werden, Preisauffälligkeiten vor der Abwicklung gefiltert werden, das Einlagenrisiko dynamisch begrenzt wird, wesentliche Verlustereignisse Pausierungsmechanismen für neue Zuflüsse auslösen und Auszahlungen gegen Live-Buchhaltungszustände statt gegen veraltete Schnappschüsse abgerechnet werden. Diese Systeme sind keine optionalen Funktionen, die nachträglich auf Vaults aufgesetzt werden. Sie sind grundlegende Anforderungen, um programmierbare Finanzierung in großem Maßstab vertrauenswürdig zu machen.

Die Zukunft der Vault-Infrastruktur

DeFi hat Transparenz gelöst, bevor es Buchhaltung gelöst hat. Das ändert sich jetzt.

Da sich Vaults zu programmierbaren Finanzinfrastrukturen entwickeln, die über Chains, Strategien und Liquiditätsschichten hinweg operieren, wird die Infrastrukturqualität wichtiger als der angegebene APY. Die nächste Phase von DeFi wird nicht dadurch definiert sein, wer am schnellsten Renditen meldet. Sie wird dadurch definiert sein, wer diese Zahlen vertrauenswürdig machen kann.

Echtzeit-NAV ist nicht einfach eine UX-Verbesserung. Es ist grundlegende Infrastruktur für institutionelles Kapital. Denn je schneller Kapital On-Chain bewegt wird, desto wichtiger wird die Integrität der Buchhaltung.

Vaults sind nicht länger passive Ertragshüllen. Sie sind programmierbare Finanzsysteme, und programmierbare Finanzsysteme erfordern programmierbares Vertrauen.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Anlage-, Rechts-, Steuer- oder Finanzberatung oder ein Angebot oder eine Aufforderung irgendeiner Art dar. Die Beschreibungen der Architektur, Kontrollen und Entwurfsziele von Concrete sind illustrativ; sie beseitigen nicht die mit Smart Contracts, DeFi-Protokollen, Marktbedingungen, Orakel- oder Datenausfällen, Betriebsstörungen, Drittanbieter-Infrastruktur oder Gegenparteileistungen verbundenen Risiken. Concrete garantiert nicht, dass eine Zielrendite, NAV-Genauigkeit, ein Pausenverhalten oder ein anderes Systemergebnis erreicht wird. Zukunftsgerichtete Aussagen spiegeln die derzeitigen Erwartungen von Concrete wider und sind keine Garantie für zukünftige Ergebnisse. Die Teilnahme an Concrete Vaults ist mit Risiken verbunden, einschließlich des Risikos eines Totalverlusts. Vollständige Risikohinweise finden Sie unter https://concrete.xyz/disclaimers.

1. In diesem Artikel bezieht sich „NAV" auf den operativen Buchwert, der zur Preisbildung von Vault-Anteilen, Einlagen, Rückkäufen und der Abwicklung auf Strategieebene verwendet wird. Er kann vom NAV des Jahresabschlusses, von Verwahrstellenaufzeichnungen oder von Drittanbieter-Protokollwerten abweichen und kann vault-spezifischen Methoden und Zeitvorgaben unterliegen.

1. Ein exponentiell gewichteter gleitender Durchschnitt gibt aktuellen Beobachtungen mehr Gewicht, während ältere Daten dennoch einfließen. Spezifische Parameter, einschließlich Abklingrate und Beobachtungsfenster, werden pro Vault kalibriert und können von Concrete im Laufe der Zeit basierend auf Strategiemerkmalen, Marktbedingungen und Betriebsdaten aktualisiert werden. Die EWMA-Glättung verringert den Einfluss kurzfristiger Preisauffälligkeiten, beseitigt jedoch nicht das Preisrisiko.

1. Volatilitätsfenster, Schwellenbreiten und Pausenparameter werden pro Vault kalibriert, können nach Concretes Ermessen geändert werden und hängen von der Genauigkeit der Eingabedaten ab. Kein Schwellenmodell kann alle Marktbedingungen vorhersehen.

1. Die beschriebenen Rollen (Transaktionsvorschlagender, unabhängiger Unterzeichner und On-Chain-Validierung) operieren innerhalb der Vault-Smart-Contracts von Concrete und unterliegen Multisig- und Timelock-Kontrollen. Die Verifikation verringert, beseitigt jedoch nicht das Risiko fehlerhafter NAV-Aktualisierungen, einschließlich Risiken aufgrund kompromittierter Schlüssel, fehlerhafter Eingabedaten oder Smart-Contract-Schwachstellen. Concretes Prüfhistorie ist verfügbar unter docs.concrete.xyz/audits.

1. Das Pausenverhalten hängt von einer genauen Schwellenkalibrierung und der Genauigkeit der zugrunde liegenden Beobachtungsschicht ab. Pausen werden möglicherweise nicht in allen Verlustszenarien ausgelöst, und das Design soll das Risiko, dass neue Einleger zu veralteten Preisen handeln, verringern, nicht beseitigen.

1. Concretes Vaults sind nach dem ERC-4626-Vault-Standard gebaut, mit Epochen-basierten asynchronen Auszahlungswarteschlangenerweiterungen auf Vertragsebene. Der Abwicklungszeitpunkt hängt vom Liquiditätsprofil der zugrunde liegenden Strategie ab und kann Vault-gesteuerten Sperren, Aussetzungsereignissen und anderen in der jeweiligen Vault-Dokumentation festgelegten Bedingungen unterliegen.