Was ist DYOR?

DYOR ist die Abkürzung für „do your own research“, also eigene Recherche betreiben. Im Zusammenhang mit Krypto-Assets heißt das, Werbung, Beiträge oder die Schlussfolgerungen anderer nicht ohne Weiteres für Tatsachen zu nehmen, sondern die ursprünglichen Materialien selbst zu suchen, Belege gegenzuprüfen und das bereits Bestätigte vom weiterhin Unbekannten zu trennen.

DYOR ist keine einheitliche Zertifizierung und keine Methode, ein Projekt verlässlich zu machen oder Verluste zu vermeiden. Es gleicht eher einem Verfahren zur Prüfung von Informationen: zuerst feststellen, was eine bestimmte Aussage konkret behauptet, dann beurteilen, welche Materialien sie stützen können, ob diese Materialien noch für die aktuelle Fassung gelten und welche Schlussfolgerungen bloß Vermutungen sind. Ein Rechercheergebnis ist auch kein einfaches Etikett „kann man kaufen“ oder „kann man nicht kaufen“.

Recherche beginnt mit einer prüfbaren Behauptung

„Dieses Projekt ist gut“, „die Gemeinschaft ist stark“ oder „die Technik ist voraus“ sind alle schwer unmittelbar zu überprüfen. Eine konkretere Behauptung zeigt, wo nach Belegen zu suchen ist, zum Beispiel:

• ob eine bestimmte Adresse der Token-Contract ist, den das Projekt gegenwärtig nutzt;
• ob das Gesamtangebot an Token steigen kann und wer das Recht zur Nachausgabe hält;
• ob der Contract bestimmte Vorgänge anhalten, aktualisieren oder einfrieren kann;
• aus welchen Märkten und welchem Zeitraum das auf einer Seite angezeigte Handelsvolumen stammt;
• welche Codefassung ein bestimmter Prüfbericht untersucht hat;
• ob eine Partnerschaft, eine Integration oder eine Produktfunktion von den beteiligten Seiten bestätigt wurde;
• ob eine als in Betrieb angekündigte Funktion eine entsprechende Aufzeichnung im Code, in der Oberfläche oder in der Onchain-Aktivität findet.

Die Behauptung zuerst aufzuschreiben verhindert auch, verschiedene Fragen zu vermischen. Dass der Quellcode eines Contracts veröffentlicht wurde, bedeutet nicht, dass der Code frei von Schwachstellen ist; dass die Identität eines Teams veröffentlicht wurde, bedeutet nicht, dass das Produkt alle Pläne erfüllen kann; und dass Menschen onchain handeln, bedeutet nicht, dass diese Transaktionen von unabhängigen Nutzenden kommen oder anhaltende Nachfrage darstellen.

Verschiedene Behauptungen brauchen verschiedene Arten von Belegen

Keine einzelne Quelle kann alle Fragen beantworten. Die bei Recherche gebräuchlichen Belege lassen sich in mehrere Klassen einteilen:

Eine „offizielle Quelle“ eignet sich, um zu bestätigen, was ein Projekt über sich selbst sagt, bleibt aber vom Projekt veröffentlichtes Material. Unabhängige Quellen können eine andere Sicht bieten und ebenso falsche oder veraltete Informationen zitieren. Eine verlässliche Schlussfolgerung stammt üblicherweise daraus, dass mehrere Quellen dieselbe konkrete Behauptung bestätigen, und nicht daraus, eine Website als „vertrauenswürdig“ zu etikettieren und dann ihren gesamten Inhalt zu übernehmen.

Prüfe zuerst Netzwerk und Contract-Adresse, dann Name und Symbolbild

Onchain-Token können denselben Namen tragen und dasselbe Symbolbild sowie dasselbe Kürzel verwenden. Beim Erkennen eines digitalen Assets unterscheiden Netzwerkname und Contract-Adresse üblicherweise besser als ein Anzeigename; bei einem nicht fungiblen Token ist womöglich auch die Tokennummer zu prüfen.

Website oder Dokumentation eines Projekts können eine Contract-Adresse liefern, und ein Block-Explorer kann die Bereitstellungstransaktion dieser Adresse, Guthaben, Token-Übertragungen und Contract-Aufrufe anzeigen. Die Einführung von Ethereum.org zu Block-Explorern führt verbreitete Onchain-Daten wie Blöcke, Transaktionen, Konten, Contracts und Token auf.

Eine Adresse ist weiterhin gegenzuprüfen. Eine nachgeahmte Website kann ebenso einen tatsächlich bestehenden Contract anzeigen, und Suchergebnisse oder Beiträge in sozialen Medien können auf einen gleichnamigen gefälschten Token verweisen. Was eine Markierung „verifiziert“ auf einer Seite konkret bedeutet, hängt von den Prüfregeln dieses Dienstes ab; aus einem Symbolbild oder einer Kennzeichnung allein lässt sich nicht schließen.

Eine Onchain-Aufzeichnung kann belegen, was geschehen ist, erklärt aber nicht automatisch, warum

Eine Blockchain kann erfassen, wann eine bestimmte Adresse eine Transaktion ausgelöst hat, wie Assets sich bewegt haben und wie sich der Contract-Zustand geändert hat. Diese Klasse von Aufzeichnung eignet sich, um Angebotsänderungen, die Richtung von Mitteln, Governance-Abstimmungen und den Aufruf einer bestimmten Funktion zu prüfen.

Eine Onchain-Aufzeichnung teilt Lesenden üblicherweise nicht unmittelbar die wirkliche Identität hinter einer Adresse mit und kann den Zweck einer Transaktion für sich nicht erklären. Eine Person kann mehrere Adressen kontrollieren, und mehrere Personen können über die Adresse derselben verwahrenden Plattform handeln. Eine Anzahl Adressen lässt sich nicht unmittelbar mit einer Anzahl Nutzender gleichsetzen, und eine Zählung von Token-Übertragungen nicht unmittelbar mit einem Grad tatsächlicher Verbreitung.

Onchain-Daten können zudem Indexierung, Kennzeichnung und Berechnung durchlaufen, bevor sie angezeigt werden. Onchain unabhängig prüfbare Transaktionsfelder gehören zur Protokollaufzeichnung, während die von einem Dienst bereitgestellten Adresskennzeichnungen, Haltereinteilungen und Statistikdiagramme zusätzliche Beurteilung enthalten. Bei Nutzung dieser Klasse von Ergebnissen sind Berechnungsgrundlage, abgedeckte Netzwerke und Aktualisierungszeit zu betrachten.

Verifizierter Quellcode zeigt nur, dass der Code zur bereitgestellten Fassung passt

Ein Smart Contract ist ein auf einer Blockchain bereitgestelltes Programm, das Vorgänge nach seinem Code ausführt. In Netzwerken, die die Ethereum Virtual Machine (EVM) nutzen, etwa Ethereum, kompiliert die Quellcode-Verifizierung üblicherweise den veröffentlichten Code unter denselben Einstellungen neu und vergleicht ihn dann mit dem an der Contract-Adresse tatsächlich laufenden Maschinencode. Maschinencode ist das kompilierte Ergebnis, das das Netzwerk unmittelbar ausführt. Der Hinweis von Ethereum.org zur Contract-Verifizierung trennt diese Art Übereinstimmungsprüfung von der formalen Verifikation; formale Verifikation prüft mit mathematischen Methoden, ob ein Programm vorab angegebene Eigenschaften erfüllt. Andere Netzwerke erfordern die Prüfung von Programmcode nach ihren eigenen Bereitstellungs- und Versionsmechanismen.

„Der Contract-Code ist verifiziert“ zeigt daher üblicherweise, dass der von Lesenden gesehene Code dem Onchain-Programm entspricht; es zeigt nicht, dass der Code eine Sicherheitsprüfung durchlaufen hat, und nicht, dass das Programm keine Logikschwachstellen hat. Kommentare und Variablennamen in veröffentlichtem Code können ebenfalls irreführend sein; das tatsächliche Verhalten hängt von der ausführbaren Logik ab.

Zudem ist festzustellen, ob ein Eingangs-Contract Anfragen an einen anderen Implementierungscode weiterleitet. Ein solcher Eingang wird häufig Proxy-Contract genannt. Ein aktualisierbarer Proxy erlaubt einem Konto mit dem entsprechenden Recht, den Implementierungscode auszutauschen; die Proxy-Contract-Dokumentation von OpenZeppelin erläutert, wie Proxy, Implementierungs-Contract und Aktualisierungsadministration zusammenwirken. Nur den kurzen Code der Proxy-Adresse selbst zu lesen kann sowohl den Contract, der die Funktionen wirklich ausführt, als auch die Aktualisierungsrechte übersehen.

Ein Code-Repository zeigt einen Entwicklungsverlauf, was nicht den produktiven Funktionen entspricht

Ein öffentliches Code-Repository kann Dateien, Commit-Aufzeichnungen, Versionsmarkierungen, Problemdiskussionen und Mitwirkende zeigen. Ein Commit ist eine erfasste Codeänderung, und eine Versionsmarkierung dient oft dazu, eine bestimmte Veröffentlichung zu kennzeichnen. Sie können helfen zu prüfen, ob ein Projekt seinen Code weiter ändert, wann eine bestimmte Funktion hinzukam und was sich zwischen Fassungen geändert hat.

Der Hinweis von GitHub zur Repository-Aktivität zeigt Aufzeichnungen wie Pushes, Merges, erzwungene Pushes und Branch-Änderungen. Viel Aktivität bedeutet keine hohe Codequalität, und wenige Commits zeigen nicht zwangsläufig, dass ein Projekt eingestellt wurde; automatische Aktualisierungen, kopierter Code und Entwicklung außerhalb eines öffentlichen Repositorys beeinflussen alle die oberflächlichen Zahlen.

Der Code des Repositorys muss auch der tatsächlich bereitgestellten Fassung entsprechen. Bei der Untersuchung einer Onchain-Anwendung ist zu betrachten, ob Veröffentlichungsmarkierungen, Bereitstellungsaufzeichnungen oder Contract-Verifizierungsangaben eine Fassung im Repository mit einer Onchain-Adresse verbinden; andernfalls lässt sich nur bestätigen, dass „dieser Code im Repository vorhanden ist“, nicht dass er produktiv läuft.

Ein Prüfbericht ist nach Umfang, Fassung, Datum und Umgang mit Befunden zu lesen

Eine Sicherheitsprüfung bedeutet, dass Fachleute Code, einen Entwurf oder Betriebsannahmen in einem bestimmten Umfang und Zeitraum untersuchen und gefundene Probleme festhalten. Beim Lesen eines Berichts zählt nicht nur, dass „eine Prüfung stattfand“, sondern auch:

• ob die untersuchten Dateien, Contract-Adressen oder Code-Commits klar angegeben sind;
• ob sich der Code nach Abschluss der Prüfung erheblich geändert hat;
• welche Bestandteile, externen Abhängigkeiten und Betriebsbedingungen außerhalb des Prüfumfangs liegen;
• welche Probleme der Bericht gefunden hat und wie das Projekt reagiert hat;
• ob Behebungen nachgeprüft wurden und ob unbehobene Probleme weiterhin bestehen;
• ob der Bericht von der prüfenden Seite veröffentlicht wurde und ob ein Link auf die vollständige Datei verweist.

Eine Prüfung kann nicht belegen, dass keine unbekannte Schwachstelle besteht. Die Mainnet-Vorbereitungsdokumentation von OpenZeppelin erläutert ebenso, dass eine Prüfung nicht gewährleisten kann, dass Code frei von Fehlern ist. Eine alte Fassung, ein Teilmodul oder einen Bericht mit nicht nachgeprüften Befunden als Sicherheitsnachweis für das gesamte System zu nehmen geht über das hinaus, was der Bericht selbst stützen kann.

Ein Whitepaper legt einen Plan dar, was keine Aufzeichnung der Umsetzung ist

Ein Whitepaper stellt üblicherweise das Problem vor, das ein Projekt lösen will, seinen Entwurfsansatz, Token-Vorkehrungen oder einen Entwicklungsplan. Es eignet sich, um zu bestätigen, welche Ziele ein Projekt öffentlich vorgebracht hat, kann aber für sich nicht belegen, dass diese Ziele erreicht wurden.

Bei der Recherche lassen sich die überprüfbaren Behauptungen eines Whitepapers gesondert mit der aktuellen Dokumentation, Codeveröffentlichungen, der Onchain-Bereitstellung und den tatsächlichen Funktionen abgleichen. Ein verstrichenes Fahrplandatum ohne entsprechende Veröffentlichungsaufzeichnung, Tokenregeln, die nicht zum bereitgestellten Contract passen, oder eine lange nicht aktualisierte Dokumentation sind alle Abweichungen, die weiter zu bestätigen sind; sie belegen für sich nicht zwangsläufig, dass ein Projekt täuscht.

Dokumentation kann zudem eine ältere Fassung beschreiben. Veröffentlichungsdatum einer Seite, letzte Änderung, zutreffendes Netzwerk und Versionsnummer bestimmen, ob eine Passage für das aktuelle System verwendbar ist. Fehlen Datum oder Versionsangabe, kennzeichne die Schlussfolgerung als unsicher, statt den fehlenden Hintergrund selbst zu ergänzen.

Aufmerksamkeit in sozialen Medien ist kein Tatsachennachweis

Gefällt-mir-Angaben, Weiterleitungen, Gruppengrößen und Suchinteresse beschreiben die Verbreitung von Inhalten; sie können technische Funktionen, Nutzeridentität, Mittelsicherheit oder Marktnachfrage nicht unmittelbar belegen. Ein Konto kann nachgeahmt oder übernommen sein, und Interaktionen können von automatisierten Programmen oder abgestimmter Werbung stammen.

Soziale Medien eignen sich besser dazu, zu prüfende Behauptungen zu finden, als als einziger Beleg einer Behauptung. Wo eine Contract-Adresse, eine Versionsaktualisierung, ein Sicherheitsvorfall oder eine externe Beziehung betroffen ist, lässt sich zur Bestätigung auf Projektdokumentation, Code-Repository, Onchain-Aufzeichnungen und die ursprünglichen Erklärungen der beteiligten Seiten zurückgehen.

Ob eine Quelle ihre Interessen offenlegt, zählt ebenfalls. Verfassende Personen können den betreffenden Token halten, eine Vergütung erhalten, am Projekt mitwirken oder über einen Empfehlungslink profitieren. Eine fehlende Offenlegung belegt für sich nicht, dass der Inhalt falsch ist, doch Lesende können daraus keinen möglichen Interessenkonflikt beurteilen, weshalb das Gewicht dieses Belegs von unabhängig prüfbaren Materialien getrennt bleiben muss.

Ein vollständiges Prüfverfahren behält die offenen Fragen

Das Ergebnis eines DYOR sollte nicht nur eine Reihe Links sein; es sollte auch angeben, was jeder Beleg beantwortet hat. Ein allgemeines Verfahren zur Prüfung von Informationen lässt sich so festhalten:

1. eine vage Bewertung in eine konkrete, überprüfbare Behauptung umschreiben;
2. das der Behauptung nächstliegende Ursprungsmaterial finden und herausgebende Stelle, Datum und Fassung festhalten;
3. mit Onchain-Aufzeichnungen, Code, einem vollständigen Bericht oder einer weiteren unabhängigen Quelle gegenprüfen;
4. unmittelbar beobachtete Tatsachen, daraus gezogene Folgerungen und persönliche Meinung unterscheiden;
5. die Widersprüche zwischen Quellen aufschreiben und was an Belegen noch fehlt;
6. wenn Contract, Recht, Fassung oder externe Beziehung nicht bestätigt werden können, „unsicher“ beibehalten; eine Lücke nicht als bejahende oder verneinende Schlussfolgerung nehmen.

Dieselbe Rechercheschlussfolgerung verliert mit der Zeit ihre Geltung. Contracts können aktualisiert, Verwaltungsrechte übertragen, Dokumentation und Prüfumfang geändert werden, und auch Liquidität und Tokenverteilung verschieben sich. Beim Zitieren veränderlicher Informationen behalte den Zeitpunkt der Daten bei; schreibe eine einzelne Prüfung nicht als dauerhafte Schlussfolgerung.

Ein verbreitetes Warnzeichen verlangt weitere Prüfung, kein unmittelbares Urteil

Die folgenden Umstände zeigen, dass die vorhandenen Materialien unzureichend oder widersprüchlich sind, und verlangen weitere Prüfung:

• eine Contract-Adresse erscheint nur in Beiträgen oder privaten Nachrichten, deren Herkunft nicht bestätigt werden kann;
• Name, Symbolbild und Kürzel sind gleich, doch Netzwerk oder Contract-Adresse unterscheiden sich;
• eine Seite erklärt den Code als quelloffen, doch es gibt kein Repository und keine Verifizierungsaufzeichnung zur bereitgestellten Fassung;
• eine Prüfung wird erklärt, doch es werden kein vollständiger Bericht, keine untersuchte Fassung und kein Behebungsstand bereitgestellt;
• die Angebots- oder Rechtebeschreibung im Whitepaper passt nicht zum aktuellen Contract-Verhalten;
• Sprache wie „garantierte Rendite“ oder „ohne Risiko“ wird verwendet oder Dringlichkeit erzeugt;
• Unterstützung durch externe Institutionen wird erklärt, doch die betreffende Seite hat keine prüfbare entsprechende Erklärung veröffentlicht;
• eine verwaltende Stelle kann Assets aktualisieren, anhalten oder bewegen, doch die öffentliche Beschreibung erwähnt diese Rechte nicht;
• eine Datenaufnahme hat keine Quelle, keine Zeitspanne und keinen nachprüfbaren Link;
• eine Diskussion zitiert nur Artikel, die einander übernehmen, ohne dass am Ende Ursprungsmaterial zu finden ist.

Ein einzelnes Warnzeichen kann nicht automatisch belegen, dass ein Projekt betrügerisch ist. Dass ein Entwicklungsteam nicht alle Identitäten veröffentlicht, dass Codeaktualisierungen selten sind oder dass ein Contract Administratorrechte hat, kann jeweils verschiedene Gründe haben. Eine Schlussfolgerung muss konkreten Zusagen, der technischen Struktur und prüfbaren Aufzeichnungen entsprechen.

DYOR hat Grenzen und sollte nicht dazu dienen, Geschädigten die Schuld zuzuweisen

Gewöhnliche Lesende können nicht eigenständig allen Code prüfen, jede Teamangabe überprüfen oder einen professionellen Angriff erkennen. Informationen können absichtlich verborgen sein, Oberflächen und Konten können nachgeahmt sein, und auch Prüfungen und öffentliche Daten können blinde Flecken haben. Eigene Recherche kann nur einen Teil der Informationslücke verringern; sie kann nicht jedes unbekannte Risiko in ein bekanntes verwandeln.

„Du hättest eigene Recherche betreiben sollen“ kann ebenso wenig eine genaue Offenlegung wichtiger Informationen durch das Projekt ersetzen oder eine Falschaussage entschuldigen. Erleidet jemand durch irreführende Materialien, Nachahmung oder eine technische Schwachstelle einen Verlust, übergeht der bloße Vorwurf, „kein DYOR gemacht“ zu haben, die Informationsasymmetrie und die erforderliche Fachschwelle.

Erfordert eine Frage fachliche technische, sicherheitsbezogene, steuerliche oder rechtliche Beurteilung, kann eine gewöhnliche Informationsprüfung weder denselben Belegumfang noch dieselbe Verantwortung abdecken.

Häufig gestellte Fragen

Gilt das Lesen des Whitepapers als vollzogenes DYOR?

Nein. Ein Whitepaper erläutert vor allem Ziele und Entwurf eines Projekts. Weiterhin zu prüfen ist, ob aktueller Code, Bereitstellung, Rechte, Onchain-Aktivität, Prüfumfang und Dokumentationsfassung zu diesen Aussagen passen.

Bedeutet verifizierter Contract-Code, dass er sicher ist?

Nein. Die Quellcode-Verifizierung bestätigt vor allem, dass der veröffentlichte Code dem bereitgestellten Maschinencode entspricht. Sie findet nicht automatisch jede Logikschwachstelle und beseitigt weder Aktualisierungsrechte noch externe Abhängigkeiten noch betriebliches Risiko.

Onchain-Daten lassen sich nicht fälschen — ist eine daraus gezogene Schlussfolgerung also sicher verlässlich?

Onchain-Transaktionsaufzeichnungen lassen sich überprüfen, doch Adresskennzeichnungen, Identitätszuordnung, Nutzerzahlen und Transaktionsmotive brauchen üblicherweise zusätzliche Erläuterung. Eine falsche Berechnungsgrundlage oder mehrere Adressen für mehrere Nutzende zu halten erzeugt ebenso eine falsche Schlussfolgerung.

Ist ein anonymes Team zwangsläufig unzuverlässig?

Aus Anonymität allein lässt sich nicht schließen. Eine veröffentlichte Identität kann prüfbare Informationen hinzufügen, doch nichts über Code, Sicherheit oder Zusagen belegen; Anonymität verringert das überprüfbare Material zu Identität und Werdegang, und diese Informationslücke sollte ausdrücklich festgehalten werden.

Kann DYOR mir sagen, welches Asset ich kaufen sollte?

Nein. DYOR ist ein Verfahren zur Prüfung von Informationen, Quellen und Unbekannten. Es erzeugt nicht automatisch eine für eine bestimmte Person geeignete Kauf-, Verkaufs- oder Halteschlussfolgerung und kann künftige Preise nicht vorhersagen.

Verwandte Begriffe

Lies weiter über digitales Asset, Smart Contract, Krypto-Token und privater Schlüssel, oder kehre zum Krypto-Glossar zurück.

Quellen

• Ethereum.org: Block explorers — die Block-, Transaktions-, Konto-, Contract- und Tokendaten, die ein Block-Explorer anzeigen kann.
• Ethereum.org: Verifying smart contracts — der Unterschied zwischen Quellcode-Übereinstimmung, Maschinencode und formaler Verifikation.
• OpenZeppelin Docs: Upgrades Plugins FAQ — das Verhältnis von Proxy, Implementierungs-Contract und Aktualisierungsadministration.
• OpenZeppelin Docs: Preparing for mainnet — Prüfungen, Quellcode-Verifizierung, Verwaltungsrechte und die Grenzen einer Prüfung.
• GitHub Docs: Using the activity view — Aufzeichnungen von Repository-Änderungen, Pushes, Merges und Branch-Aktivität.