Der Wasserfall der "Best Practices" für die Proof-of-Reserve- und Solvenztransparenz von DeFi-Protokollen: 1. Alle Adressen/Wallets/Positionen öffentlich offenlegen -> vollständig verifizierbar (aber aus verschiedenen Gründen meist nicht machbar) 2. Offenlegung an bestimmte Systeme/Datenverifikationsnetzwerke (z.B. @AccountableData), die die Möglichkeit bieten, die Daten unabhängig über zkproofs (PoR, Solvenz, delta-neutralität usw.) zu verifizieren -> vertrauenslose Lösung für onchain verifizierbare Daten (Vertrauen in den Code + Vollständigkeit des Umfangs) 3. Offenlegung an Oracle-Netzwerke, die die Möglichkeit bieten, zu verifizieren, dass die bezogenen Daten nicht manipuliert wurden (d.h. wie sie vom Oracle empfangen wurden) -> vertrauensminimierte Lösung (Vertrauen in das Oracle-Netzwerk) 4. Offenlegung an Drittanbieter-"Prüfer", die periodische Bestätigungen veröffentlichen können (meist in Form von PDFs) -> keine Echtzeitverfolgung 5. Selbstberichtete Bestätigungen -> geringste Vertrauensverbesserung, da man der gleichen Partei vertraut 6. Nichts offenlegen -> volles Vertrauen Das Obige gilt hauptsächlich für onchain-Bilanzen (tokenisierte delta-neutrale Strategien und ähnliche renditeträchtige Stablecoins, Verwahrer usw.). Offchain-Vermögenswerte & RWAs (Stablecoins, MMFs, ETFs, CLOs, Fonds) haben offensichtlich (1) nicht als Option, während die Leiter weniger vertikal wird, da (2), (3) & (4) ähnlich sind, da das Vertrauen in offchain-Datenquellen bleibt, also: (2) ZK-Systeme → Privatsphäre + formale Ansprüche über vertrauenswürdige Dokumente (3) Oracle-Netzwerke → Integrität + Dezentralisierung der Berichterstattung (4) Prüfer → rechtliche + buchhalterische Durchsetzung

arguably (4) kann im Vergleich zu (3) vorzuziehen sein, abhängig davon, wie die Bestätigungen strukturiert sind