Eine Taxonomie des Marktmissbrauchs

Neugier

1. Warum braucht ein Token-Contract einen Admin-Schlüssel, wenn er doch permissionless sein soll?
2. Wie können zwei identische Trades zu unterschiedlichen Preisen führen, je nachdem, wer sie zuerst einreicht?
3. Wenn Code Social Engineering nicht verhindern kann, welcher Teil des Marktes bleibt dann angreifbar?

Erkunden

Teil IEine Taxonomie des Marktmissbrauchs

1. Marktmissbrauch lässt sich in sechs unterschiedliche Ebenen einteilen, von denen jede eine bestimmte strukturelle Schwäche ausnutzt. Die Contract-Ebene betrifft beibehaltene Befugnisse wie Minting oder Einfrieren; die Marktstruktur-Ebene umfasst dünne Pools und Kurvendesigns; die Reihenfolge-Ebene nutzt die Abfolge von Transaktionen aus; die Ebene der Fake-Aktivität bläht Volumen und Holder-Zahlen auf; die soziale Ebene manipuliert Vertrauen durch das Vortäuschen fremder Identitäten; und die Wallet-Ebene entzieht Vermögenswerte per Phishing. Jede Ebene wird von einem von vier Verteidigern abgewehrt (Code, Marktdesign, Kryptografie oder Menschen), und dieses Level zeigt, dass für jeden davon bereits Werkzeuge existieren. Es richtet sich gleichermaßen an Builder und Nutzer.
2. Auf der Contract-Ebene beginnt Diebstahl häufig. Behält ein Entwickler die Mint Authority, kann er nach Belieben neue Token drucken und sie gegen die bestehenden Holder verkaufen. Freeze-Funktionen ermöglichen es ihm, bestimmte Wallets am Verkauf zu hindern und so Kapital faktisch festzusetzen. Upgradefähige Proxys erlauben es Entwicklern, den zugrunde liegenden Code nach dem Launch auszutauschen. Das sind keine Bugs; es sind Features, die eine Angriffsfläche schaffen. Entfernt man diese Schlüssel, ist die Bedrohung beseitigt – zugleich geht aber auch die Möglichkeit verloren, kritische Fehler zu beheben oder auf Notfälle zu reagieren.
3. Reihenfolge-Angriffe werden von denjenigen ausgenutzt, die ausstehende Transaktionen sehen können, bevor diese in eine Reihenfolge gebracht werden. Front-Running liegt vor, wenn ein Trader eine ausstehende Order sieht und seine eigene Transaktion mit einer höheren Gebühr einreicht, um zuerst ausgeführt zu werden. Beim Sandwiching wird unmittelbar vor dem großen Swap eines Opfers gekauft und direkt danach verkauft, um von der Preisauswirkung zu profitieren, die dieser Swap verursacht. Diese Verluste tragen gewöhnliche Trader, die schlechtere Ausführungspreise erhalten. Slippage-Limits begrenzen mögliche Verluste, verhindern aber den Angriff selbst nicht.
4. Launch-Angriffe nutzen die Geschwindigkeit einer Preisbildung nach dem Prinzip „Wer zuerst kommt“ aus. Sniper kaufen Token bereits im allerersten Block eines Launches, oft mithilfe von Bundles, die mehrere Transaktionen für eine atomare Aufnahme bündeln. Sybil-Wallets ermöglichen es einem einzelnen Akteur, viele Adressen zu kontrollieren, um Konzentration zu verschleiern und Belohnungen pro Wallet zu farmen. Diese Angriffe beruhen auf billiger Adresserstellung und auf Belohnungsstrukturen, die nicht linear mit dem Bestand wachsen. Die Erkennung erfordert in der Regel eine nachträgliche Analyse der Funding-Graphen.
5. Fake-Aktivität bläht Kennzahlen auf, die Aufmerksamkeit lenken. Beim Wash Trading werden Token zwischen eigenen Wallets gekauft und verkauft, um künstliches Volumen zu erzeugen. Volume-Bots wälzen Trades um, um in Trending-Listen aufzusteigen, während Dust Spraying gefälschte Holder-Zahlen erzeugt. Wenn jeder Trade eine Gebühr kostet, wird Wash Trading teuer; gewichten Trending-Algorithmen jedoch einzelne Wallets, werden Sybil-Angriffe profitabel. Diese Verzerrungen täuschen Investoren über das tatsächliche Marktinteresse.
6. Die soziale Ebene nutzt menschliches Vertrauen statt Code aus. Nicht offengelegte bezahlte Promotions, das Imitieren offizieller Accounts und koordinierte Pump-and-Dumps erfordern keine technische Schwachstelle. Phishing-Seiten und bösartige Approvals leeren Wallets direkt bei den Nutzern. Code kann diese Angriffe durch die Überprüfung der On-Chain-Historie sichtbar machen, aber nicht verhindern. Diese Bedrohungen liegen im Verhalten von Menschen, nicht in der Logik von Contracts.

Teil IIWas Code beheben kann und was nicht

7. Die Contract-Logik legt fest, was möglich ist. Behält der Code eine Mint-Funktion, auf die nur ein Administrator zugreifen kann, bleibt dieser Schlüssel eine dauerhafte Angriffsfläche. Entfernt man die Mint Authority vollständig, ist das Risiko unkontrollierter Inflation beseitigt. Ebenso verhindert das Löschen von Verkaufssteuer-Variablen oder Freeze-Funktionen Honeypots und Blacklist-Missbrauch. Das sind binäre Entscheidungen: Die Befugnis existiert oder sie existiert nicht.
8. Die Marktstruktur bestimmt die Ausführungsreihenfolge. Bei sequenzieller Verarbeitung erhält der erste Kauf in einem Block den besten Preis. Batch-Clearing-Mechanismen fassen Transaktionen innerhalb eines Zeitfensters zusammen und führen sie alle zu einem einheitlichen Clearing-Preis aus. Das neutralisiert Front-Running und Sandwiches innerhalb des Batches, weil jede Order denselben Preis erhält: Wer zuerst kommt oder die Order eines anderen umschließt, gewinnt nichts.
9. Manche Risiken sind begrenzt, aber nicht beseitigt. Ein Creator, der vierzig Prozent des Angebots hält, kann diese abstoßen und den Preis für frühe Käufer abstürzen lassen. Code kann das Angebot eines Creators sperren oder per Vesting freigeben, aber einen Holder mit freigegebenen Token nicht am Verkauf hindern. Das ist Marktrisiko, kein Diebstahl. Auch der Kauf in einem früheren Block kann sich weiterhin lohnen. Designer müssen akzeptieren, dass die Volatilität durch große Holder ein inhärentes Merkmal permissionless Märkte ist und kein Bug, den man patchen könnte.
10. Social Engineering findet außerhalb der Codebasis statt. Phishing-Links, imitierte Accounts und bezahlte Promotions nutzen menschliches Vertrauen aus, keine rechnerischen Schwachstellen. Kein Smart Contract kann prüfen, ob ein Influencer seinen Anteil offengelegt hat, bevor er einen Token callt. Diese Angriffe bestehen unabhängig von der technischen Sicherheit fort, weil sie auf Aufmerksamkeit und Überzeugung wirken, nicht auf Zustandsübergänge.
11. Ein ehrliches Designdokument führt auf, welche Angriffsklassen durch Code beseitigt, welche durch Marktmechanik neutralisiert werden und welche als nicht reduzierbar beim menschlichen Verhalten verbleiben. Es hält ausdrücklich fest: Mint-Missbrauch ist unmöglich; Sandwich-Angriffe werden durch Batching abgeschwächt; Phishing bleibt eine Frage der persönlichen Sicherheitsverantwortung. Diese Transparenz ermöglicht es Nutzern, ihr Risiko zutreffend einzupreisen, statt von vollständiger Sicherheit auszugehen.
12. Öffnen Sie in einem Block-Explorer einen EVM-Token mit verifiziertem Quellcode und suchen Sie nach Funktionen wie `mint`, `pause` oder `owner`; prüfen Sie auf Solana stattdessen die Mint und Freeze Authority sowie die Upgrade Authority des Programms. Prüfen Sie, ob diese Funktionen von jedem aufgerufen werden können oder auf eine bestimmte Adresse beschränkt sind. Gibt es keine solchen Funktionen und ist der Contract nicht upgradefähig, fehlen diese Angriffsvektoren strukturell – sie sind nicht bloß deaktiviert.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Chainalysis, Crypto Crime Report (2024)
• P. Daian et al., 'Flash Boys 2.0' (IEEE S&P 2020)
• SPL Token documentation
• OpenZeppelin proxy documentation
• E. Budish, P. Cramton & J. Shim, 'The High-Frequency Trading Arms Race' (QJE 2015)