Fachbeiträge

Oracles und Bewerter bei Level-3-Inputs

Tokenisierte Fonds und Kreditportfolios bringen ihren Nettoinventarwert über Oracles auf die Blockchain, wo er öffentlich, signiert und täglich aktualisiert vorliegt. Der Beitrag trennt diese Eigenschaften von der Beobachtbarkeit i.S.d. IFRS 13 und ordnet Oracle-Preise als Informationen Dritter ein. Darüber hinaus behandelt er die Angabeerleichterung in IFRS 13.93(d) und beziffert an einem fiktiven Kreditfonds, wie sich Feed-Risiko und Bewertungsrisiko zueinander verhalten.

M.Sc. Oliver Sonntag04.11.2026Rechtsstand 04.11.2026
Gliederung

I. Einleitung

Bei tokenisierten Fonds wird der Nettoinventarwert (NAV) außerhalb der Blockchain errechnet und erst danach von einem NAV-Oracle als fertige Zahl auf die Kette gebracht, wo sie von Smart Contracts bspw. als Sicherheitenwert verwendet wird.11Vgl. Chainlink, What Is a NAV Oracle, aktualisiert 15.05.2026; RedStone, NAV Onchain, 23.04.2026. Da diese Zahl bei Kreditfonds regelmäßig auf nicht beobachtbaren Annahmen beruht, stellt sich die Frage, ob sie durch die Veröffentlichung an Qualität gewinnt und ob ein Investor als Inhaber eines solchen Tokens den Feed als beobachtbaren Input verwenden kann.

Die Standardsetzer haben sich zu dieser Frage – soweit ersichtlich – nicht geäußert. Das IVSC führt digitale Vermögenswerte in seinem aktuellen Konsultationspapier auf der Themenagenda.22Vgl. IVSC, Exposure Draft Basis for Conclusions, 2026, Abschn. Consultation Process. Das FSB nennt die Abhängigkeit von nicht regulierten Oracles für Preisfindung und Bewertung als Risiko der Tokenisierung, ohne einen Maßstab zu geben.33Vgl. FSB, The Financial Stability Implications of Tokenisation, 22.10.2024, S. 17. Daneben regen EBA und ESMA einen Zertifizierungsrahmen für Oracles an.44Vgl. EBA/ESMA, Joint Report on recent developments in crypto-assets, 13.01.2025, Rn. 93.

Der Beitrag beantwortet die Frage aus IFRS 13 heraus. Hierzu werden in Abschn. II. die Arten von Oracle-Daten unterschieden, bevor Abschn. III. die Einordnung vornimmt, Abschn. IV. ein Beispiel rechnet und Abschn. V. die Gegenpositionen würdigt und Prüfschritte ableitet.

II. Arten von Oracle-Daten

1. Marktpreis-Feeds

Bei Marktpreis-Feeds werden die Preise mehrerer Quellen zusammengefasst. Eine neue Runde wird bei Chainlink gestartet, wenn die Preise um mehr als eine festgelegte Schwelle abweichen oder eine festgelegte Zeit verstrichen ist (Heartbeat).55Vgl. Chainlink, Decentralized Data Model. Pyth aggregiert dagegen die Meldungen von Publishern über eine Variante des gewichteten Medians und gibt ein Konfidenzintervall mit aus.66Vgl. Pyth Data Association, Whitepaper version 2.0, 28.09.2023. Die Aggregation kann sich je nach Produkt unterscheiden. Das Ergebnis ist in beiden Fällen eine neue Zahl, die so an keinem Markt gehandelt wurde. Die Abweichungen zwischen den Feeds können dabei erheblich sein: Beim Kursverfall vom 10.10.2025 lag USDe nach einer Analyse rund 65 Bp bei Chainlink, 430 Bp bei Pyth und über 3.500 Bp am Spotmarkt von Binance von seinem Referenzwert entfernt.77Vgl. LlamaRisk, When Pricing Breaks: A USDe Case, 18.10.2025. Die Einordnung als Depeg ist umstritten, vgl. The Block, 13.10.2025.

Auch bei korrekter Wiedergabe seiner Quelle kann ein Feed einen unbrauchbaren Wert liefern. So kam es am 26.11.2020 nach dem kurzzeitigen Ausweis von DAI mit rund 1,30 USD bei Coinbase Pro zu Liquidationen von rund 88 Mio. USD bei Compound, das diese Quelle nutzte.88Vgl. The Block, 26.11.2020. Es handelt sich um Liquidationsvolumen, nicht um den Gesamtschaden. Die Ursache des Kurses ist ungeklärt, vgl. Caldarelli/Ellul, The Blockchain Oracle Problem in Decentralized Finance – A Multivocal Approach, Applied Sciences 11(16), 2021, Abschn. 5.4. Insoweit übernahm das Oracle den Kurs seiner Quelle, ohne dessen Aussagekraft zu beurteilen. Daneben stehen gezielte Eingriffe, durch die nach Angaben der IOSCO allein 2022 über 400 Mio. USD in 41 Fällen von Oracle-Manipulation verloren gingen.99Vgl. IOSCO, Final Report with Policy Recommendations for DeFi, FR/14/2023, Dezember 2023, S. 36; zum Anteil an Preismanipulationen EBA/ESMA, a.a.O., Rn. 55, 74, wonach diese gemessen am gesamten in DeFi-Angriffen gestohlenen Wert zwischen 2023 und Oktober 2024 nur rund 1 % ausmachten.

2. NAV-Feeds

NAV-Feeds aggregieren keine Märkte. RedStone beschreibt für Fonds wie BUIDL und ACRED ein Einzelquellenmodell (ohne die übliche Aggregation mehrerer Quellen) und versieht jedes Update zur Nachprüfbarkeit der Herkunft mit Signatur und Zeitstempel.1010Vgl. RedStone, Tokenize the World, 06.07.2026. Es handelt sich um eine Anbieterangabe. Ein NAV werde – so der Anbieter selbst – errechnet und nicht am Markt gefunden.1111Vgl. RedStone, NAV Onchain, a.a.O. Dieselbe Quelle nennt für die meisten tokenisierten Fonds eine tägliche Rechnung (bei manchen Kreditvehikeln eine wöchentliche bzw. monatliche) und bezeichnet eine untertägige Fortschreibung als Extrapolation des Tageswerts und nicht als laufende Bewertung.

Der Feed-Takt sagt daher nichts über das Alter der Bewertung aus, denn mit einem Heartbeat von 24 Stunden kann eine Zahl immer wieder neu signiert werden, deren Annahmen einen Monat alt sind.1212Zum Heartbeat von 24 Stunden vgl. RedStone, Tokenize the World, a.a.O.; zum erneuten Signieren statischer NAV vgl. RedStone, Case Study Securitize.

3. Bestandsnachweise

Proof-of-Reserve-Feeds melden Bestände, deren Quellen Dritte (wie Prüfer und Verwahrer) bzw. der Emittent selbst sind. Bei den von uns eingesehenen Feeds handelt es sich um eine Leistung ohne Bestätigungscharakter, die vollständig auf Angaben Dritter beruht.1313Vgl. Chainlink, SmartData; Chainlink Data, EURR Reserves. Ein solcher Nachweis ersetzt weder eine Abschlussprüfung noch eine Bewertung.

Tab. 1: Arten von Oracle-Daten
ArtEntstehungZahl der QuellenAussage
Marktpreis-FeedAggregation von Handels- oder PublisherpreisenMehrereAbgeleiteter Preis, keine Transaktion
NAV-FeedÜbernahme eines berechneten WertsEineWert von Verwalter, Administrator oder Emittent
BestandsnachweisÜbernahme von BestandsangabenEine oder wenigeMenge, kein Wert

4. Verantwortung

Die Anbieter weisen die Verantwortung für die Zahl in ihren Hinweisen dem Nutzer zu. So überlässt Chainlink ihm die Beurteilung von Genauigkeit und Qualität der Daten und übernimmt keine Verantwortung für selbst gemeldete Reservedaten,1414Vgl. Chainlink, Selecting Quality Data Feeds; Chainlink, SmartData, a.a.O. Die Nutzungsbedingungen konnten wir nicht auswerten. während Pyth „as is“ liefert und die Haftung ausschließt.1515Vgl. Pyth, Disclaimer for Pyth Network Price Feeds, 08.05.2025. Gleichwohl ist die Beschreibung eines bloßen Transports durch das Oracle zu eng, da Aggregation, Konfidenzberechnung und Obergrenzen eine Zahl erzeugen bzw. verändern können. Im März 2026 senkte eine fehlkonfigurierte Obergrenze den wstETH-Kurs bei Aave um rund 2,85 % und löste Liquidationen von rund 26 Mio. USD aus.1616Vgl. Chaos Labs, Post-Mortem wstETH CAPO, 10.03.2026. Es handelt sich um den Eigenbericht des betroffenen Dienstleisters, der im selben Verlauf am 12.03.2026 die Verantwortung für das Update übernommen hat; zum Ausgleich dienten zurückgeholte Mittel und die Treasury der Aave DAO. Da das Oracle die Zahl mitbestimmen kann, ist vor der Verwendung zu klären, wer nach den Bedingungen des jeweiligen Anbieters für Fehler einsteht.

III. Einordnung nach IFRS 13

1. Beobachtbarkeit

Anhang A von IFRS 13 versteht unter beobachtbaren Inputs solche, die aus Marktdaten (bspw. öffentlich verfügbaren Informationen über tatsächliche Ereignisse oder Geschäftsvorfälle) abgeleitet werden und die Annahmen der Marktteilnehmer widerspiegeln. Auch die IVS knüpfen beobachtbare Daten – neben der Verfügbarkeit für Marktteilnehmer – an tatsächliche Ereignisse oder Transaktionen.1717Vgl. IVSC, International Valuation Standards, gültig ab 31.01.2025 (im Folgenden IVS 2025), Glossar Tz. 10.20. Diese Anforderungen erfüllt die öffentliche Verfügbarkeit einer Zahl allein nicht, weil es auch auf ihren Ursprung ankommt. In dieselbe Richtung weist die Feststellung des IFRS Interpretations Committee von 2015 zu Konsenspreisen Dritter, die Hierarchie ordne Inputs und nicht Verfahren und die Einordnung hänge von den Inputs des Dritten ab.1818Vgl. IFRIC Update Januar 2015, wiedergegeben in der annotierten Ausgabe von IFRS 13, zu Tz. 72. Die Entscheidung betrifft Konsenspreise, nicht Oracles; die Übertragung ist unsere Ableitung. Damit bleibt ein NAV auf Basis modellierter Kreditwerte – auch signiert auf einer öffentlichen Blockchain – modelliert. Die Signatur belegt lediglich die unveränderte Herkunft der Zahl von einer bestimmten Quelle und sagt nichts über ihre inhaltliche Richtigkeit aus.

Bei Marktpreis-Feeds ist die Lage differenzierter, da ein Level-2-Input in Betracht kommt, soweit sie auf tatsächlichen Geschäftsvorfällen beruhen (IFRS 13.82). Als Level-1-Input scheidet ein aggregierter Wert dagegen regelmäßig aus, da Level 1 unangepasste notierte Preise für identische Vermögenswerte in aktiven Märkten verlangt, zu denen das Unternehmen am Bewertungsstichtag Zugang hat (IFRS 13.76). Das AICPA hält aggregierte Preise bei einem aktiven Hauptmarkt ausdrücklich für ungeeignet.1919Vgl. AICPA, Accounting for and auditing of digital assets, Stand 30.09.2025, Q&A 18. Die Practice Aid ist nicht verbindlich und bezieht sich auf US GAAP.

2. Preise Dritter

IFRS 13 schließt die Verwendung notierter Preise von Dritten (bspw. von Kursinformationsdiensten oder Maklern) nicht aus, wenn das Unternehmen nach IFRS 13.B45 festgestellt hat, dass sie gemäß dem Standard entwickelt wurden. Für den Fall eines erheblichen Rückgangs der Aktivität ergänzen B46 und B47, dass die Preise auf ihre Grundlage hin zu beurteilen sind (aktuelle Informationen bzw. eine die Annahmen von Marktteilnehmern widerspiegelnde Technik) und Notierungen in Form verbindlicher Angebote stärker gewichtet werden. Diese Regelung passt allerdings nur teilweise, da sie im Abschnitt zum Aktivitätsrückgang steht und von notierten Preisen spricht, die ein NAV nicht ohne Weiteres darstellt. Stammt die Zahl vom Emittenten, Fondsverwalter bzw. dessen Administrator, ist ihr Urheber für den Inhaber zwar ein Dritter, aber nicht vom Bewertungsobjekt unabhängig.

Wir halten B45 dennoch für den richtigen Ausgangspunkt, da die Übernahme einer fremden Zahl danach eine eigene Feststellung über ihr Zustandekommen voraussetzt. Dies entspricht der Linie der Prüfungspraxis. Nach IAPN 1000 bleibt das Management auch bei einem Preisdienst für die Bewertung verantwortlich und hat zu verstehen, wie der Preis entstanden ist, ob er verbindlich ist und wie oft er aktualisiert wird.2020Vgl. IAPN 1000, Tz. 52, 60 f. Die Praxisnote hat nicht die Autorität eines ISA. Für Oracle-Daten sehen wir keinen Grund, geringere Anforderungen zu stellen.

3. Angabepflicht bei Level 3

Eine besondere Schwierigkeit enthält IFRS 13.93(d): Die Vorschrift verlangt bei Level 3 quantitative Informationen über die bedeutenden nicht beobachtbaren Inputs, befreit das Unternehmen aber von deren Erzeugung, wenn es sie nicht selbst entwickelt (bspw. bei Verwendung von Preisinformationen eines Dritten ohne Anpassung). Dabei darf es die ihm bei vertretbarem Aufwand verfügbaren quantitativen Inputs nicht ignorieren. Bei wörtlicher Lesart kann die unveränderte Übernahme eines NAV-Feeds also dazu führen, dass im Abschluss des Token-Inhabers zu den tatsächlich preisbestimmenden Annahmen keine Zahlen genannt werden.

Die Erleichterung erstreckt sich allerdings weder auf die Beschreibung von Bewertungstechnik und Inputs in IFRS 13.93(d) noch auf die Angaben nach IFRS 13.93(g) und (h)(i). Zudem verlangt IFRS 13.89 bei der Entwicklung nicht beobachtbarer Inputs – ohne Pflicht zu umfassenden Anstrengungen zur Beschaffung – die besten verfügbaren Informationen. Soweit der Inhaber das Zustandekommen des NAV nicht feststellen kann, genügt der Feed nach unserer Auffassung der Linie des B45 nicht.

4. Bewertete Einheit

Da der Inhaber den Anteil und nicht das Portfolio des Fonds bewertet, sind die Inputs für die Bewertung des Anteils maßgeblich (IFRS 13.73) und kann dieser auf einem anderen Level stehen als die Vermögenswerte des Fonds. Zum NAV enthält IFRS 13 keine eigene Regelung. Sofern ein Marktteilnehmer den Anteil jederzeit zum NAV zurückgeben kann, lässt sich u.E. vertreten, dass der NAV ein realisierbarer Preis und insoweit ein beobachtbarer Input ist. Ein aktiver Sekundärmarkt für den Token wäre davon unabhängig zu prüfen (IFRS 13.76 f.). Dieses Argument trägt bei Kreditfonds mit Sperrfristen, Rückgabequoten oder Warteschlangen nicht. Daher kommt es für die Einordnung auf Rückgabebedingungen und Zweitmarkt an, an denen das Oracle nichts ändert. Für den externen Bewerter eines Fonds stellt sich die Frage ohnehin auf Ebene der Vermögensgegenstände.2121Vgl. unseren Beitrag zur externen Bewertung für tokenisierte AIF.

IV. Zahlenbeispiel

Ein fiktiver tokenisierter Kreditfonds habe ein Fondsvermögen von 100,00 Mio. EUR und 100.000 Anteile (NAV von 1.000,00 EUR je Anteil). Das Portfolio bestehe aus Krediten ohne Marktpreis (Duration 2,5). Der NAV werde vom Verwalter monatlich festgestellt und vom Oracle mit einem Heartbeat von 24 Stunden und einer Abweichungsschwelle von 0,10 % signiert. Die Parameter orientieren sich an den Angaben der Anbieter, während das Portfolio erfunden ist.

Tab. 2: Fiktiver Kreditfonds, mögliche Abweichung vom festgestellten NAV
Quelle der AbweichungJe Anteil in EURMio. EURGröße
Feed: Übertragungstoleranz im Normalbetrieb±1,00±0,100,10 %
Modell: Sensitivität bei einer Renditeänderung um ±100 Bp±25,00±2,502,50 %
Ereignis: Ausfall eines Kredits (4 % des Portfolios, Verlustquote 80 %)−32,00−3,203,20 %

Eigene Berechnung. Die Wirkung der Rendite ist näherungsweise als Duration × Renditeänderung ermittelt.

Die Übertragungstoleranz macht in diesem Fall ein Fünfundzwanzigstel der Modellsensitivität aus. Dieses Verhältnis folgt aus den gesetzten Annahmen und schließt Störfälle wie die in Abschn. II. genannten nicht ein. Es zeigt aber, dass die auf der Blockchain sichtbaren 0,10 % die Treue der Übertragung beschreiben und nichts über die Unsicherheit der Bewertung aussagen. Ein Ausfall kurz nach einer Feststellung erreicht den Feed zudem erst mit dem nächsten NAV. Bis dahin meldet das Oracle täglich einen frisch signierten Wert von 1.000,00 EUR, dessen Annahmen bis zu einen Monat alt sind.

Für den Inhaber ist hieraus zwischen zwei Altersangaben zu unterscheiden: dem auf der Blockchain ablesbaren Alter des Feeds und dem Alter der Bewertung, das sich nur ablesen lässt, soweit der Anbieter ein Datum mitliefert.2222So das Feld navDate in Chainlink, Data Streams Report Schema v9, das den Veröffentlichungszeitpunkt des NAV-Reports nennt und nicht den Stand der Modellannahmen. Da für den Stichtag nur das Alter der Bewertung zählt, ist bei einem Stichtag zwischen zwei NAV-Feststellungen zu prüfen, ob Ereignisse nach der letzten Feststellung eine Anpassung erfordern.2323Für notierte Preise regelt IFRS 13.79(b) den vergleichbaren Fall bedeutender Ereignisse nach Marktschluss; eine Anpassung führt dort aus Level 1 heraus. Die Übertragung auf NAV-Feeds ist unsere Ableitung.

V. Würdigung und Prüfschritte

1. Einwände

Gegen die hier vertretene Einordnung lassen sich drei Einwände vorbringen, die im Folgenden gewürdigt werden.

a) Konsens mehrerer Quellen

Man mag einwenden, viele unabhängige Quellen machten einen Konsenspreis zu einem belastbaren Datum. IAPN 1000 räumt Konsensdiensten tatsächlich Beweiswert ein (daneben sind ggf. weitere Nachweise erforderlich).2424Vgl. IAPN 1000, a.a.O., Tz. 57 f. Die stärkste Gegenposition wäre ein – uns nicht dokumentiertes – Oracle, in dem mehrere unabhängige Bewerter ihre Einschätzung zum selben Kredit melden, während bei NAV-Feeds nach den Anbieterangaben gerade eine Einzelquelle vorliegt.

b) Prüfung regulierter Fonds

Ferner wird auf die Prüfung der Fonds verwiesen, die als regulierte Vehikel über Verwalter, Verwahrer und Abschlussprüfer verfügen. Dies kann die Belastbarkeit der Zahl für den geprüften Stichtag erhöhen und ist bei der Würdigung zu berücksichtigen. Da die Beobachtbarkeit davon jedoch unberührt bleibt, wird auch eine gut geprüfte Level-3-Bewertung weiterhin auf Level 3 eingeordnet.

c) Zirkel aus Bewertung und Marktbeleg

Ein Zirkel könnte entstehen, wenn dieselbe Zahl sowohl als Bewertung als auch als Marktbeleg dient. Wird ein zurückgespielter NAV als Sicherheitenwert verwendet und daraus ein Kurs abgeleitet, steckt in diesem Kurs wieder der ursprüngliche NAV. Dabei handelt es sich bislang um eine Gefahr und nicht um einen belegten Befund, weil wir keinen Fall gefunden haben, in dem eine Oracle-Zahl als Marktbeleg für einen Level-3-Wert verwendet worden wäre. Verwandt damit ist der Fall eines fest kodierten Oracle-Preises, bei dem eine Zahl nicht mehr neu bewertet wird.2525Vgl. CoinShares, 07.11.2025, zu Stream Finance xUSD: Nach dieser Darstellung arbeitete ein Oracle mit festen 1,27 USD, während der Token bei 0,26 USD gehandelt wurde. Es handelt sich um ein Editorial eines Marktteilnehmers.

2. Prüfschritte und Rollen des Bewerters

Für die Verwendung von Oracle-Daten in einer Bewertung werden aus dem Vorstehenden folgende Prüfschritte abgeleitet:

  1. Art der Zahl klären (Marktaggregat, berechneter Wert oder Bestandsangabe).
  2. Quelle benennen (wer rechnet, wer signiert und ob diese Stelle vom Bewertungsobjekt unabhängig ist).
  3. Alter der Bewertung ermitteln, getrennt vom Alter des Feeds.
  4. Annahmen beschaffen (insb. bedeutende nicht beobachtbare Inputs, Spanne und Sensitivität der Quelle).
  5. Einheit und Rückgabe prüfen (ob der Anteil oder das Portfolio eingeordnet wird und ob die Rückgabe zum NAV tatsächlich möglich ist).
  6. Plausibilisieren (bspw. durch Abgleich mit Rücknahmen, Vergleichstransaktionen oder einer eigenen Rechnung) und Ereignisse seit der letzten Feststellung würdigen.

Bewerter treten dabei in zweifacher Rolle auf: zum einen als Nutzer von Oracle-Daten, für deren Würdigung als Input sie dann die Verantwortung tragen,2626Vgl. IVS 2025, IVS 100 Tz. 30.03, zu Spezialisten und Dienstleistern. zum anderen selbst als Quelle eines Feeds, wenn eine signierte Bewertung auf die Blockchain gebracht wird. Im zweiten Fall sollte die Zahl mit Spanne, Stichtag und Gültigkeit ausgewiesen werden, da ein Punktwert ohne diese Angaben eine Genauigkeit vermittelt, die eine Level-3-Bewertung nicht aufweist.

VI. Fazit

Ein Oracle macht eine Zahl zugänglich, ohne sie i.S.d. IFRS 13 beobachtbar zu machen. Nach dem für die Einordnung maßgeblichen Ursprung des Werts können Marktpreis-Feeds Level-2-Inputs liefern, während NAV-Feeds eine Bewertung wiedergeben. Ohne realisierbare Rückgabe spricht dies für Level 3. Bei der Übernahme einer solchen Zahl sollte ihr Zustandekommen entsprechend IFRS 13.B45 festgestellt werden. Die Erleichterung in IFRS 13.93(d) betrifft dabei nur quantitative Angaben. Für den Stichtag zählt das Alter der Bewertung, das von der Aktualität des Feeds zu trennen ist.

Fußnoten

  1. 1Vgl. Chainlink, What Is a NAV Oracle, aktualisiert 15.05.2026; RedStone, NAV Onchain, 23.04.2026.
  2. 2Vgl. IVSC, Exposure Draft Basis for Conclusions, 2026, Abschn. Consultation Process.
  3. 3Vgl. FSB, The Financial Stability Implications of Tokenisation, 22.10.2024, S. 17.
  4. 4Vgl. EBA/ESMA, Joint Report on recent developments in crypto-assets, 13.01.2025, Rn. 93.
  5. 5Vgl. Chainlink, Decentralized Data Model.
  6. 6Vgl. Pyth Data Association, Whitepaper version 2.0, 28.09.2023. Die Aggregation kann sich je nach Produkt unterscheiden.
  7. 7Vgl. LlamaRisk, When Pricing Breaks: A USDe Case, 18.10.2025. Die Einordnung als Depeg ist umstritten, vgl. The Block, 13.10.2025.
  8. 8Vgl. The Block, 26.11.2020. Es handelt sich um Liquidationsvolumen, nicht um den Gesamtschaden. Die Ursache des Kurses ist ungeklärt, vgl. Caldarelli/Ellul, The Blockchain Oracle Problem in Decentralized Finance – A Multivocal Approach, Applied Sciences 11(16), 2021, Abschn. 5.4.
  9. 9Vgl. IOSCO, Final Report with Policy Recommendations for DeFi, FR/14/2023, Dezember 2023, S. 36; zum Anteil an Preismanipulationen EBA/ESMA, a.a.O., Rn. 55, 74, wonach diese gemessen am gesamten in DeFi-Angriffen gestohlenen Wert zwischen 2023 und Oktober 2024 nur rund 1 % ausmachten.
  10. 10Vgl. RedStone, Tokenize the World, 06.07.2026. Es handelt sich um eine Anbieterangabe.
  11. 11Vgl. RedStone, NAV Onchain, a.a.O.
  12. 12Zum Heartbeat von 24 Stunden vgl. RedStone, Tokenize the World, a.a.O.; zum erneuten Signieren statischer NAV vgl. RedStone, Case Study Securitize.
  13. 13Vgl. Chainlink, SmartData; Chainlink Data, EURR Reserves.
  14. 14Vgl. Chainlink, Selecting Quality Data Feeds; Chainlink, SmartData, a.a.O. Die Nutzungsbedingungen konnten wir nicht auswerten.
  15. 15Vgl. Pyth, Disclaimer for Pyth Network Price Feeds, 08.05.2025.
  16. 16Vgl. Chaos Labs, Post-Mortem wstETH CAPO, 10.03.2026. Es handelt sich um den Eigenbericht des betroffenen Dienstleisters, der im selben Verlauf am 12.03.2026 die Verantwortung für das Update übernommen hat; zum Ausgleich dienten zurückgeholte Mittel und die Treasury der Aave DAO.
  17. 17Vgl. IVSC, International Valuation Standards, gültig ab 31.01.2025 (im Folgenden IVS 2025), Glossar Tz. 10.20.
  18. 18Vgl. IFRIC Update Januar 2015, wiedergegeben in der annotierten Ausgabe von IFRS 13, zu Tz. 72. Die Entscheidung betrifft Konsenspreise, nicht Oracles; die Übertragung ist unsere Ableitung.
  19. 19Vgl. AICPA, Accounting for and auditing of digital assets, Stand 30.09.2025, Q&A 18. Die Practice Aid ist nicht verbindlich und bezieht sich auf US GAAP.
  20. 20Vgl. IAPN 1000, Tz. 52, 60 f. Die Praxisnote hat nicht die Autorität eines ISA.
  21. 21Vgl. unseren Beitrag zur externen Bewertung für tokenisierte AIF.
  22. 22So das Feld navDate in Chainlink, Data Streams Report Schema v9, das den Veröffentlichungszeitpunkt des NAV-Reports nennt und nicht den Stand der Modellannahmen.
  23. 23Für notierte Preise regelt IFRS 13.79(b) den vergleichbaren Fall bedeutender Ereignisse nach Marktschluss; eine Anpassung führt dort aus Level 1 heraus. Die Übertragung auf NAV-Feeds ist unsere Ableitung.
  24. 24Vgl. IAPN 1000, a.a.O., Tz. 57 f.
  25. 25Vgl. CoinShares, 07.11.2025, zu Stream Finance xUSD: Nach dieser Darstellung arbeitete ein Oracle mit festen 1,27 USD, während der Token bei 0,26 USD gehandelt wurde. Es handelt sich um ein Editorial eines Marktteilnehmers.
  26. 26Vgl. IVS 2025, IVS 100 Tz. 30.03, zu Spezialisten und Dienstleistern.

Der Beitrag gibt die Auffassung des Verfassers wieder. Der Verfasser ist Geschäftsführer der Surion GmbH, die Bewertungsleistungen und signierte Attestierungen für digitale Vermögenswerte anbietet. Das Zahlenbeispiel ist fiktiv. IFRS 13 wird mit den Textziffern der von der EU übernommenen Fassung zitiert (Verordnung (EU) 2023/1803 in der aktuellen Fassung). Die dort als Stufen und Eingangsparameter bezeichneten Größen heißen hier Level und Inputs. Internetquellen wurden zuletzt am 04.11.2026 abgerufen.

Sprechen Sie direkt mit dem Bewerter.