BMIC Research · Evidence education · 2026-09-05

Beleg-Checkliste für Krypto-Presales | Neutrale Due-Diligence-Methode

Ein Krypto-Presale sollte zuerst als Belegfrage und erst danach als Geschichte betrachtet werden. Suchergebnisse, Social-Media-Beiträge und fertige Dashboards können kopiert oder veraltet sein. Halten Sie fest, was wann mit welcher Quelle geprüft wurde und was weiterhin unbewiesen ist. Diese Seite ist eine neutrale Methode zur Prüfung eines Krypto-Presales und keine Rangliste oder Aufforderung zur Teilnahme.

Veröffentlicht von BMIC Research, das mit dem BMIC-Emittenten verbunden ist. Dies ist keine unabhängige Investmentanalyse.

Risikoleitfaden von BMIC Research (Herausgeber-Dokument, Englisch)

Nur zur Information. Kryptoanlagen können an Wert verlieren, illiquide werden oder nicht wie erwartet funktionieren. Keine Finanz-, Rechts-, Steuer- oder Anlageberatung und keine Empfehlung.

1. Exaktes Netzwerk und exakte Adresse abgleichen

Beginnen Sie mit Chain, Netzwerkumgebung und vollständiger Contract-Adresse. Vergleichen Sie die Adresse Zeichen für Zeichen zwischen der englischen Sicherheitsrichtlinie des Herausgebers, dem passenden Block-Explorer und einer unabhängigen technischen Quelle. Ticker, Logo, Kurzlink oder Wallet-Name beweisen keine Identität. Notieren Sie Explorer-URL und Prüfzeitpunkt. Prüfen Sie, ob der Vertrag im vorgesehenen Netzwerk läuft, ob eine Seite nicht still das Netzwerk wechselt und ob eine Proxy-Adresse mit der Implementierungsadresse verwechselt wird. Eine Abweichung ist ein Stoppsignal, kein kleines Darstellungsproblem.

2. Auditdatum, Umfang und deployed Bytecode dokumentieren

Ein Audit ist ein Beleg für einen bestimmten Umfang zu einem bestimmten Zeitpunkt. Lesen Sie Datum, Commit- oder Bytecode-Referenz, enthaltene Verträge, Ausschlüsse, Schweregrade und Behebungsstatus. Gleichen Sie den deployed Bytecode oder verifizierten Quelltext ab, soweit der Bericht dies erlaubt. Ein Audit von Quelltext, der nicht deployed wurde, beantwortet eine andere Frage. Bei einem Proxy müssen Implementation, Proxy-Admin, Upgrade-Rechte, Pausen- und Mint-Rechte sowie andere privilegierte Grenzen geprüft werden. Fragen Sie, ob Kontrollen zeitgesperrt, multisigniert, aufgegeben, dokumentiert oder nur behauptet sind. „Auditiert“ bedeutet weder sicher noch zertifiziert noch unveränderlich.

3. Verteilung, Vesting und Liquidität trennen

Behandeln Sie Tokenverteilung, Vesting und Liquidität als drei getrennte Belegspuren. Suchen Sie eine datierte Allokationstabelle, den Verteilungsmechanismus und die Stelle, die den Zeitplan ändern kann. Prüfen Sie, ob Vesting on-chain erzwungen oder nur im Text beschrieben wird. Für Liquidität braucht es den tatsächlichen Handelsplatz, das Paar oder den Pool, Sperrbedingungen, Freigabedatum, Tiefe und Kontrolle über die Mittel. „Liquidität geplant“ ist kein Nachweis. Wenn Unterlagen fehlen, schreiben Sie „unbewiesen“, statt eine Lücke zu füllen. Auch bei konsistenten Dokumenten bleiben Verlust-, Verwässerungs-, Illiquiditäts- und Vertragsrisiken möglich.

4. Aussagen zu Standards präzise halten

FIPS 203 ist ein NIST-Standard für ML-KEM, einen Mechanismus zur Kapselung von Schlüsseln. Er ist kein Produktzertifikat, kein Smart-Contract-Audit, keine Token-Empfehlung und kein Nachweis, dass eine konkrete Implementierung alle Anforderungen erfüllt. Lesen Sie die primäre NIST-Veröffentlichung und unterscheiden Sie klar zwischen technischem Standard und gesondertem Konformitätsnachweis. Ein Algorithmusname, ein Roadmap-Satz oder ein Partnerlogo darf nicht in eine Zertifizierung umformuliert werden. Diese Seite nutzt den Standard nur als Leshilfe und macht keine Zertifizierungsaussage über BMIC Research oder ein Produkt. primäre NIST-FIPS-203-Veröffentlichung.

5. Wallet und Transaktionsspur schützen

Geben Sie niemals Seed Phrase, Private Key oder Wiederherstellungscode an eine Website, einen Supportkontakt oder einen Reviewer. Prüfen Sie vor der Signatur im Wallet Netzwerk, Zielvertrag, Chain-ID, Tokenfreigabe und Transaktionsdetails. Bei einer ausstehenden Transaktion zuerst Explorer und Nonce prüfen; nicht automatisch wiederholen oder erneut senden, nur weil eine Seite einen Fehler meldet. Dringliche Nachrichten, kopierte Adressen, gefälschte Verifikationsseiten und Wallet-Connect-Aufforderungen sind Phishing-Risiken. Bewahren Sie Transaktionshash, genaue Seite und Datum auf, ohne persönliche Wallet-Identität zu veröffentlichen.

6. Lokale Zulässigkeit getrennt prüfen

Aus Sprache, Wohnort, einer erreichbaren Webseite oder einer erfolgreichen Wallet-Verbindung darf keine lokale Zulässigkeit abgeleitet werden. Die japanische Finanzaufsicht erläutert in ihren Primärmaterialien, dass Fragen zu Einordnung und Registrierung von den Tatsachen und dem anwendbaren Rahmen abhängen können. Für den Einzelfall sind Primärquellen und qualifizierte lokale Beratung nötig. Diese Seite entscheidet nicht, ob BMIC Research, ein Token oder ein Angebot in Japan oder anderswo zulässig ist. Eine Übersetzung darf nicht zu einer Finanzwerbung werden; Unsicherheit und mögliche Beschränkungen müssen sichtbar bleiben. primäres Material der japanischen FSA.

7. Belegprotokoll statt Urteil veröffentlichen

Notieren Sie für jede Prüfung URL, Datum, genaue Aussage, Ergebnis, Einschränkung und nächste Frage. Kennzeichnen Sie Fakten als aktuell, historisch, nicht verfügbar oder unbewiesen. Bewahren Sie widersprüchliche Belege auf, statt die günstigste Version auszuwählen. Ein gutes Ergebnis kann lauten: Adresse stimmt, Auditumfang ist begrenzt, Vesting und Liquidität sind unbewiesen, lokale Zulässigkeit braucht unabhängige Beratung. Das ist hilfreicher als Sterne oder die Behauptung, ein Projekt sei sicher. BMIC Research wird nur als in den eigenen Unterlagen genannte Herausgeber-Verbindung offengelegt; diese allgemeine Checkliste ist keine Produktempfehlung.

Primärquellen und Herausgeber-Dokumente