Zur Website Zum Dashboard
Zum Dashboard
Wissensdatenbank
Wichtig

How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

Keine Checkliste kann beweisen, dass ein Projekt sicher ist. Sie dient dazu, Unbekanntes sichtbar zu machen, Aussagen mit überprüfbaren Nachweisen zu vergleichen und möglichen Schaden zu begrenzen.

Dieser Artikel dient ausschließlich Bildungszwecken und stellt keine Finanz-, Anlage- oder Rechtsberatung dar. Web3-Transaktionen können zum vollständigen Verlust übertragener Assets führen.

1. Quelle prüfen

  • Verwenden Sie ein gespeichertes Lesezeichen oder eine URL aus einem bestätigten offiziellen Kanal.
  • Prüfen Sie jedes Zeichen der Domain.
  • Verbinden Sie Ihre Wallet nicht über Anzeigen, unaufgeforderte Nachrichten oder zufällige Suchergebnisse.
  • Vergleichen Sie Vertragsadressen in den offiziellen Projektunterlagen.
  • Geben Sie niemals eine Seed-Phrase oder einen privaten Schlüssel weiter.

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. Netzwerk und Asset bestätigen

Notieren Sie vor jeder Übertragung:

  • Netzwerk;
  • Token-Vertragsadresse;
  • Empfänger- oder aufgerufene Vertragsadresse;
  • Betrag;
  • Gebührenasset;
  • beabsichtigte Aktion.

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. Bereitgestellten Code prüfen

In einem Block Explorer:

  • Vertrag anhand der offiziellen Adresse finden;
  • Quellcodeverifizierung prüfen;
  • ermitteln, ob es sich um einen Proxy handelt;
  • aktuelle Implementierung öffnen;
  • alle Adressen mit der Projektdokumentation vergleichen.

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. Administrative Befugnisse verstehen

Suchen Sie nach Rollen und Funktionen wie:

  • Eigentümer, Administrator, Operator und Upgrader;
  • pausieren und fortsetzen;
  • Änderungen von Gebühren oder Grenzen;
  • Änderungen verknüpfter Adressen;
  • Token-Prägung;
  • Auszahlung von Assets;
  • Upgrades der Implementierung;
  • Adresssperrung.

Fragen Sie, wer diese Schlüssel kontrolliert, ob eine Multisignatur verwendet wird, ob Änderungen einer Zeitsperre unterliegen und wie Benutzer benachrichtigt werden. Zentralisierte Kontrolle ist nicht automatisch betrügerisch, schafft jedoch eine Abhängigkeit von bestimmten Kontrollinstanzen.

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. Audit richtig lesen

Prüfen Sie, ob:

  • der Bericht vom Auditor veröffentlicht wurde;
  • Repository und Commit-Hash angegeben sind;
  • der aktive Vertrag Teil des Prüfungsumfangs ist;
  • der Bericht die aktuelle Implementierung abdeckt;
  • ungeklärte Befunde bestehen bleiben;
  • Korrekturen erneut getestet wurden;
  • wichtige Komponenten ausgeschlossen wurden.

Ein Audit ist eine zusätzliche unabhängige Prüfung. Es kann nicht jeden Fehler erkennen und umfasst nicht automatisch die Website, die Schlüsselverwaltung, das Geschäftsmodell oder künftige Upgrades.

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. Aussagen mit dem On-Chain-Verhalten vergleichen

Prüfen Sie mehrere Transaktionen auf:

  • Status;
  • Aus und To / Interacted With;
  • BEP-20-Bewegungen;
  • interne Aufrufe;
  • Logs;
  • Gebühren;
  • Änderungen von Salden und Vertragszustand.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Erfolg means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. Assets und Verbindlichkeiten getrennt betrachten

Ein sichtbarer Adresssaldo ist nur eine einzelne Information. Fragen Sie:

  • ob alle relevanten Adressen offengelegt sind;
  • wer die Assets kontrolliert;
  • ob sie ausgezahlt werden können;
  • welche Verpflichtungen gegenüber anderen Benutzern bestehen;
  • wie ein externer Preis bestimmt wird;
  • ob der Zugang von einer Bridge, DEX, einem Orakel oder einer Gegenpartei abhängt.

Ein hoher Token-Saldo belegt keine Liquidität. Eine große Anzahl von Einheiten kann einen geringen realisierbaren Wert haben.

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. Wirtschaftsmodell verständlich erklären

Finden Sie klare Antworten auf folgende Fragen:

  • woher eine Auszahlung stammt;
  • wer Gebühren bezahlt;
  • was geschieht, wenn keine neuen Benutzer hinzukommen;
  • Ausstiegsbedingungen und Sperrfristen;
  • wo Verluste entstehen können;
  • welche Parameter Administratoren ändern können;
  • wodurch der Token-Preis bestimmt wird.

Hängt das Ergebnis von Märkten, neuen Teilnehmern, Liquidität oder Teamentscheidungen ab, müssen diese Abhängigkeiten klar benannt werden.

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. Signaturen und Token-Freigaben kontrollieren

Prüfen Sie vor der Bestätigung die Angaben in der Wallet:

  • Netzwerk;
  • aufgerufene Adresse;
  • Funktion oder verständliche Aktion;
  • Wert des nativen Tokens;
  • Token und Freigabehöhe;
  • erwartete Asset-Änderungen.

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

Lehnen Sie eine Signatur ab, wenn die Angaben unklar sind oder die Adresse von der geprüften abweicht. Prüfen und widerrufen Sie nach der Nutzung nicht mehr benötigte Berechtigungen mit einem vertrauenswürdigen Werkzeug.

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. Off-Chain-Risiken berücksichtigen

Auch gründlich geprüfter Code kann nicht jedes der folgenden Ereignisse verhindern:

  • Kompromittierung von Website oder DNS;
  • schädliche Browsererweiterung;
  • Schlüsseldiebstahl;
  • kompromittiertes Projektkonto;
  • Backend-Ausfall;
  • Social-Engineering-Angriff;
  • rechtliche Einschränkung;
  • Support- oder Betriebsausfall.

Prüfen Sie Dokumentation, Vorfallverfahren, Benachrichtigungskanäle und Änderungsverlauf. Bewerten Sie rechtliche Aussagen anhand tatsächlicher Dokumente und unter Berücksichtigung Ihrer eigenen Rechtsordnung.

11. Mögliche Schäden begrenzen

Auch nach Abschluss der Prüfung:

  • mit dem kleinsten praktikablen Testbetrag beginnen;
  • für unbekannte dApps eine separate Wallet verwenden;
  • nicht alle Assets in der verbundenen Wallet aufbewahren;
  • niemals unter Zeitdruck signieren;
  • Transaktionshashs und Adressen speichern;
  • Token-Freigaben regelmäßig prüfen;
  • eine maximale Exposition festlegen, deren vollständiger Verlust verkraftbar wäre.

Die offizielle Sicherheitsdokumentation von Solidity empfiehlt, die in einem Vertrag gehaltene Asset-Menge zu begrenzen: Bei einem Fehler in Code, Compiler oder Plattform kann eine begrenzte Exposition auch den Verlust begrenzen.

Checkliste vor der Transaktion

Answer yes, no, or unknown:

  • Ich habe die Domain verifiziert.
  • Ich kenne das genaue Netzwerk.
  • Ich habe die Token-Vertragsadresse geprüft.
  • Ich habe die aufgerufene Vertragsadresse geprüft.
  • Ich kenne den Status der Quellcodeverifizierung.
  • Ich habe Proxy und Implementierung geprüft.
  • Ich verstehe die Befugnisse der Administratoren.
  • Das Audit entspricht der aktiven Version.
  • Ich habe reale Transaktionen geprüft.
  • Ich verstehe die Herkunft der Auszahlungen und mögliche Verlustszenarien.
  • Ich verstehe die Signaturanfrage.
  • Die Freigabe ist angemessen begrenzt.
  • Ich habe Risiken der Benutzeroberfläche, Schlüsselverwaltung und rechtliche Risiken berücksichtigt.
  • Der Testbetrag kann keinen kritischen Schaden verursachen.

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

Fragen, die ein vorsichtiger Benutzer stellen sollte

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.

Quellen und weiterführende Literatur

  1. Solidity Documentation — Sicherheitsaspekte
  2. Ethereum.org — Smart-Contract-Sicherheit
  3. Ethereum.org — Smart Contracts testen
  4. BscScan Information Center — Transaktionen anzeigen
  5. BscScan Information Center — Arten der Vertragsverifizierung
  6. BscScan Information Center — Was ist eine Adresse?
  7. OpenZeppelin Docs — Proxy-Upgrade-Muster