Kaskada "najlepszych praktyk" dotyczących przejrzystości Proof-of-Reserve i wypłacalności protokołów DeFi: 1. ujawnienie wszystkich adresów/portfeli/pozycji publicznie -> w pełni weryfikowalne (ale zazwyczaj nie wykonalne z różnych powodów) 2. ujawnienie niektórym systemom / sieciom weryfikacji danych (np. @AccountableData), które mogą zapewnić możliwość niezależnej weryfikacji danych za pomocą zkproofs (PoR, wypłacalność, delta-neutralność itp.) -> rozwiązanie bez zaufania dla danych weryfikowalnych onchain (ufając kodowi + kompletności zakresu) 3. ujawnienie sieciom oracle, które mogą zapewnić możliwość weryfikacji, że pozyskane dane nie zostały zmanipulowane (tj. tak, jak otrzymane przez oracle) -> rozwiązanie z minimalnym zaufaniem (ufając sieci oracle) 4. ujawnienie zewnętrznym "audytorom", którzy mogą publikować okresowe zaświadczenia (zazwyczaj w formie PDF) -> brak śledzenia w czasie rzeczywistym 5. samodzielne raportowanie zaświadczeń -> najmniejsza poprawa zaufania, ponieważ ufasz tej samej stronie 6. nie ujawniaj niczego -> pełne zaufanie Powyższe dotyczy głównie bilansów onchain (tokenizowane strategie delta-neutralne i podobne stablizowane aktywa przynoszące zyski, kustodiani itp.). Aktywa offchain i RWAs (stablecoiny, MMFs, ETF-y, CLOs, fundusze) oczywiście nie mają (1) jako opcji, podczas gdy drabina staje się mniej pionowa, ponieważ (2), (3) i (4) są podobne, ponieważ zaufanie do źródeł danych offchain pozostaje, więc: (2) systemy ZK → prywatność + formalne roszczenia dotyczące zaufanych dokumentów (3) sieci oracle → integralność + decentralizacja raportowania (4) audytorzy → egzekwowanie prawne + księgowe
można argumentować, że (4) może być preferowane w porównaniu do (3) w zależności od tego, jak są zorganizowane zaświadczenia
188