2,7 Milliarden Blockchain-Spam-Transfers: Was das für das Sanktionsscreening bedeutet
Zwischen Januar und August 2026 wurden mehr als 2,7 Milliarden mutmaßliche Spam-Transfers über TRON, Ethereum, BNB Smart Chain und Polygon abgewickelt. Rechnet man 2,5 Milliarden Dust-Transfers auf Solana allein im Q1 2026 hinzu, ergibt sich ein deutliches Bild: Ein erheblicher Teil der gesamten On-Chain-Aktivität hat keinen wirtschaftlichen Wert und dient keinem echten Nutzerinteresse. Für Compliance-Teams ist dieses Volumen nicht nur lästig. Es führt direkt zu Alert-Müdigkeit, erhöhten Ablehnungsquoten und echten Fragen zur Integrität von Sanktionsscreening-Workflows. Für Unternehmen, die Krypto-Buchhaltungssoftware nutzen, um Transaktionsdaten in Compliance-Kontrollen einzuspeisen, ist das Verständnis dessen, was Spam ist, wie er sich je Chain verhält und was er operativ kostet, inzwischen eine Grundvoraussetzung.
Was Blockchain-Spam tatsächlich ist
Der Sammelbegriff umfasst drei verschiedene Angriffstypen, jeder mit unterschiedlichen Kostenstrukturen, Erkennungsprofilen und Chain-Präferenzen. Alle drei verfolgen ein Ziel: eine vom Angreifer kontrollierte Adresse in die Transaktionshistorie eines Opfers einzufügen, damit sie später mit einer vertrauenswürdigen Gegenpartei verwechselt werden kann.
Dusting
Der Angreifer sendet einen realen, aber vernachlässigbaren Betrag eines Tokens, oft einen Bruchteil eines Cents in einem Stablecoin, an die Ziel-Wallet. Die Transaktion ist technisch legitim. Tokens bewegen sich. Aber der einzige Zweck besteht darin, die Adresse des Angreifers in der Historie des Opfers zu platzieren. Wenn das Opfer das nächste Mal eine kürzlich verwendete Adresse aus seiner Wallet-Oberfläche kopiert, die Adressen typischerweise auf die ersten und letzten paar Zeichen verkürzt, kann es die falsche erwischen.
Zero-Value-Transfers
Auf bestimmten Blockchains, insbesondere TRON, erlauben die Token-Transfer-Regeln jedem, einen Transfer mit Betrag null im Namen einer beliebigen Adresse einzureichen, ohne die privaten Schlüssel dieser Adresse zu besitzen. Es bewegen sich keine Gelder. Es werden keine Schlüssel kompromittiert. Aber die Wallet-Historie des Opfers zeigt nun einen scheinbaren ausgehenden Transfer an die Adresse des Angreifers. Das Opfer sieht den Eintrag und kopiert möglicherweise später diese Adresse für einen echten Transfer.
Gefälschtes Token-Spoofing
Der Angreifer setzt einen gefälschten Token-Vertrag ein, der Name und Tickersymbol eines legitimen Tokens nachahmt, und erzeugt dann Transfer-Events, die in Block-Explorern und Wallets so erscheinen, als hätte das Opfer den echten Token empfangen oder gesendet. Dies ist die technisch anspruchsvollste Variante, da sie die Bereitstellung eines Smart Contracts erfordert, was sie teurer macht. Diese Kosten treiben sie zu Chains mit höheren Gebühren, wo die Auszahlung pro Ziel-Wallet den Aufwand rechtfertigt.
Die Aufschlüsselung nach Chain
Spam konzentriert sich dort, wo die Gebühren im Verhältnis zur möglichen Auszahlung niedrig sind. Welche Methode Angreifer verwenden, folgt dem zugrunde liegenden Gebührenregime und der Architektur jeder Chain. Die Daten von Januar bis August 2026 machen die Unterschiede deutlich.
TRON
TRON ist das proportional am stärksten betroffene Netzwerk. Dust machte 30 % aller Transfers im Messzeitraum aus. Von allen aktiven Wallets, die Gelder auf TRON empfangen, wurden 60 % mindestens einmal von Dusting berührt. TRONs Bandwidth- und Energy-Modell, das viele Transfers für Konten mit ausreichend gestakten Ressourcen effektiv kostenlos macht, ermöglicht industriellen Spam zu vernachlässigbaren Grenzkosten. Zero-Value-Transfers sind auf TRON aufgrund der permissiven Regeln für Token-Transfer-Einreichungen ebenfalls strukturell möglich.
Solana
Solana verzeichnete allein im Q1 2026 2,5 Milliarden Dust-Transfers, was 13 % der Aktivität entspricht und 27 Millionen Adressen erreichte. Diese Zahlen decken nur das erste Quartal ab und sind daher nicht direkt mit den achtmonatigen Gesamtsummen der anderen vier Chains vergleichbar. Solanas Architektur umfasst Mint-Authority-Validierung, die gefälschtes Token-Spoofing in großem Maßstab unpraktisch macht. Infolgedessen dominiert hier Dusting, während das ausgefeiltere vertragsbasierte Spoofing, das auf EVM-Chains zu finden ist, weitgehend fehlt.
BNB Smart Chain
BSC ist die Hauptstadt der gefälschten Token im Datensatz. Mehr als 460 Millionen gefälschte Transfer-Events traten zwischen Januar und August 2026 auf, wobei etwa 7.000 gefälschte Token-Verträge mehr als 454 Millionen Adressen erreichten. Das bedeutet, dass 44,5 % aller aktiven BSC-Empfänger mindestens ein gespooftes Token-Event erlebten. Jeder Vertrag erreichte durchschnittlich etwa 65.000 Adressen.
Ethereum
Ethereum verzeichnet insgesamt geringere Spam-Volumina, was auf höhere Gas-Kosten zurückzuführen ist, die Massen-Dusting unwirtschaftlich machen. Angreifer kompensieren dies, indem sie aus jedem eingesetzten Vertrag weit mehr herausholen. Nur 390 gefälschte Token-Verträge erreichten 30,6 Millionen Ethereum-Adressen, etwa 18 % der aktiven Empfänger, mit einer Rate von etwa 79.000 Adressen pro Vertrag. Das ist die höchste Reichweite pro Vertrag aller gemessenen Chains und deutet auf einen hochgradig gezielten Einsatz hin.
Polygon
Polygon zeigt eine Mischung aller drei Angriffstypen. Gefälschte Token erreichten 22,7 Millionen Adressen über etwa 790 Verträge, was 24 % der aktiven Empfänger abdeckt. Die im Vergleich zu Ethereum geringere Reichweite pro Vertrag spiegelt die niedrigere Gebührenumgebung von Polygon wider, die einen breiteren, aber weniger gezielten Einsatz ermöglicht.
| Chain | Dominanter Spam-Typ | Betroffene Adressen | Anteil aktiver Empfänger |
|---|---|---|---|
| TRON | Dust / Zero-Value | ~709 Mio. (kombiniert, 5 Chains) | 60 % gedustet |
| Solana | Dust | 27 Mio. (nur Q1) | 13 % der Q1-Aktivität |
| BSC | Gefälschte Token | 454 Mio.+ | 44,5 % |
| Ethereum | Gefälschte Token | 30,6 Mio. | ~18 % |
| Polygon | Gemischt | 22,7 Mio. | 24 % |
Die operativen Kosten für Compliance-Teams
Spam in dieser Größenordnung landet direkt in Sanktionsscreening-Workflows. Jeder Spam-Transfer, der eine markierte oder nahezu markierte Adresse berührt, erzeugt einen Alert, den ein Mensch oder ein automatisiertes System prüfen und entweder eskalieren oder ablehnen muss. Die Daten quantifizieren diese Belastung genau.
Durch Dust verursachte Alert-Ablehnungen
Im Jahr 2026 stammten 38 % aller Sanktionsalert-Ablehnungen von Dust-Transfers. Die Zahl war nicht über das Jahr hinweg konstant. Sie begann im Januar 2026 bei 25 % und sank bis August 2026 auf 10 %, mit zwischenzeitlichen Anstiegen. Der Trend deutet darauf hin, dass sich die Compliance-Workflows im Laufe des Zeitraums angepasst haben, sei es durch verbesserte Filterregeln, Schwellenwertanpassungen oder bessere Tools, aber der Ausgangspunkt unterstreicht, wie exponiert viele Teams zu Jahresbeginn waren.
Die wirtschaftliche Bedeutung dieser Ablehnungen ist nahezu per Definition vernachlässigbar. Der durchschnittliche Wert eines abgelehnten dust-bezogenen Sanktionsalerts betrug 0,0000588 USD, der Median lag bei 0,00 USD, was Zero-Value-Token-Transfers widerspiegelt. Compliance-Teams verbrachten Untersuchungszeit mit Transaktionen, die nichts bewegten. Das ist kein Risikokalibrierungsproblem, sondern ein Rauschproblem, das, wenn es nicht behoben wird, die Signalqualität des gesamten Screening-Programms beeinträchtigt.
Schwellenwert- und Gewichtungsentscheidungen
Wie viel von dieser Last ein einzelnes Unternehmen trägt, ist in erheblichem Maße eine institutionelle Entscheidung. Compliance-Programme haben einen breiten Ermessensspielraum darüber, was ihre Screening-Kontrollen markieren und bei welchen Schwellenwerten. Die Analyse stellt fest, dass die reifsten Teams mehrere Faktoren in Kombination abwägen: Absendercharakteristika, Wallet-Historie, Transaktionsbetrag und Hop-Muster. Auf einen einzelnen Datenpunkt zu reagieren, etwa eine Adresse, die in einer Transaktion erscheint, ohne Kontext, führt zu Alert-Volumina, die Tracking-Systeme nicht effizient bewältigen können.
Was das für Wirtschaftsprüfungsgesellschaften und CFOs bedeutet
Für Wirtschaftsprüfungsgesellschaften, die Klienten mit digitalen Vermögenswerten beraten, und für CFOs, die Treasury-Operationen mit Krypto-Assets verwalten, hat das Spam-Problem zwei unterschiedliche Dimensionen.
Transaktionsklassifizierung und Ledger-Integrität
Unerbetene Dust-Transfers und Zero-Value-Token-Events landen in der Wallet-Historie eines Klienten, ob gewünscht oder nicht. In einer gut konfigurierten Buchhaltungssoftware für digitale Vermögenswerte müssen diese Einträge korrekt identifiziert und klassifiziert werden. Ein unerbetener Dust-Eingang mit einem Marktwert von 0,00000X USD ist nach den meisten Ansatzrahmen technisch Einkommen, aber der Betrag ist so klein, dass Wesentlichkeitsschwellen ihn fast universell eliminieren werden. Das ernstere Risiko besteht darin, dass ein gefälschtes Token-Event im Ledger so erscheint, als wäre ein echter Token empfangen worden, was die Vermögensbilanzen verzerren könnte, wenn die Software Rohdaten ohne Unterscheidung zwischen echten und gespooften Transfers einliest.
Unternehmen, die Krypto-Buchhaltungs-Workflows betreiben, müssen bestätigen, dass ihre Datenpipelines zwischen echten Token-Eingängen und durch gefälschte Verträge erzeugten Events unterscheiden können. Dies ist kein theoretisches Problem. Bei 460 Millionen gefälschten Transfer-Events allein auf BSC über acht Monate ist die Wahrscheinlichkeit hoch, dass mindestens ein solches Event eine aktiv verwaltete Wallet berührt.
AML-Programmgestaltung
Für Unternehmen mit AML-Verpflichtungen, sei es als Anbieter virtueller Vermögenswerte, als Berater solcher oder als regulierte Einheiten, die Krypto-Transaktionen verarbeiten, untermauern die TRM-Daten ein Prinzip, das Regulierungsbehörden in mehreren Jurisdiktionen bereits formuliert haben: Sanktionsscreening-Kontrollen müssen risikokalibriert sein, nicht binär. Ein Screening-System, das bei jeder Adresse, die in einem Transaktionsdatensatz erscheint, einen Alert auslöst, erzeugt auf TRON, BSC und zunehmend auf Ethereum ein nicht handhabbares Alert-Volumen. Regulierungsbehörden erwarten, dass Unternehmen ihre Begründung für die Schwellenwertfestlegung dokumentieren und nachweisen, dass Ablehnungen auf einer substanziellen Analyse beruhen und nicht auf reflexartiger Freigabe von Rauschen mit niedrigem Wert.
Dies steht in direktem Zusammenhang mit der Durchsetzungshaltung. Wie in unserer früheren Berichterstattung über Blockchain-Analytik und Sanktionscompliance behandelt, haben Regulierungsbehörden klargestellt, dass unzureichende Screening-Methodik, nicht nur unzureichende Screening-Abdeckung, eine Quelle von Durchsetzungsrisiken darstellt. Ein Unternehmen, das 38 % seiner Sanktionsalerts aufgrund von Dust ablehnt, ohne eine dokumentierte Begründung dafür, warum Dust bei Sub-Cent-Schwellenwerten ein vernachlässigbares Risiko darstellt, befindet sich nicht in einer verteidigungsfähigen Position.
Die Cross-Chain-Dimension erhöht die Komplexität weiter. Unternehmen, die über TRON, Ethereum und BSC hinweg tätig sind, sehen auf jeder Chain materiell unterschiedliche Spam-Typologien, und eine einzige Screening-Richtlinie ist wahrscheinlich nicht für alle drei gleichzeitig gut kalibriert. Die früher in diesem Jahr veröffentlichte Cross-Chain-Kriminalitätsanalyse unterstreicht, warum chain-spezifische Risikobewertungen für Unternehmen mit Multi-Chain-Exposition zunehmend notwendig sind.
Praktische Schritte für Compliance-Teams
Schwellenwertlogik je Chain überprüfen
Wenn Ihr Sanktionsscreening-Programm einheitliche Schwellenwerte über alle Chains hinweg anwendet, deuten die obigen Daten darauf hin, dass es falsch kalibriert ist. TRONs Spam-Rate von 30 % und BSCs Penetrationsrate gefälschter Token von 44,5 % bedeuten, dass ein undifferenzierter Ansatz entweder übermäßiges Alert-Volumen erzeugt oder echtes Risiko durch zu aggressives Unterdrücken verfehlt. Dokumentieren Sie jetzt chain-spezifische Schwellenwertbegründungen, bevor ein Regulator danach fragt.
Ledger-Datenaufnahme prüfen
Fragen Sie Ihren Anbieter von Krypto-Buchhaltungssoftware oder Ihr internes Datenteam, wie das System gefälschte Token-Events handhabt. Konkret: Werden alle Token-Transfer-Events von Block-Explorern eingelesen, oder werden Token-Vertragsadressen gegen ein Known-Good-Register validiert? Wenn Ersteres der Fall ist, haben Sie möglicherweise Phantom-Vermögenswerte in Klienten-Ledgern, die überprüft und korrigiert werden müssen.
Mitarbeiter in der Mechanik schulen
Compliance-Analysten, die verstehen, warum eine Wallet Tausende von 0,00-USD-Transfers erhalten hat, und die typischen Muster von Adressverkürzungs-Spoofing erkennen können, werden legitime Alerts schneller abarbeiten und echtes Risiko zuverlässiger eskalieren. Die TRM-Analyse bietet eine nützliche technische Grundlage für interne Schulungsmaterialien.
Häufig gestellte Fragen
Begründet der Erhalt eines Dust-Transfers eine Steuerpflicht?
In den meisten Jurisdiktionen ist der unerbetene Erhalt eines Tokens technisch gesehen ein steuerpflichtiger Zugang zum faireren Marktwert. Bei Dust-Transfers mit einem Wert von 0,00 USD oder einem Bruchteil eines Cents wird dieser Betrag fast immer unter jeder praktischen Wesentlichkeitsschwelle liegen, aber das Prinzip gilt weiterhin. Unternehmen sollten sicherstellen, dass ihre Buchhaltungssoftware für digitale Vermögenswerte diese korrekt klassifiziert, anstatt sie völlig zu ignorieren, damit die Aufzeichnungen prüfbar sind.
Kann ein gefälschtes Token-Event einen falschen Vermögensbestand in den Buchhaltungsunterlagen erzeugen?
Ja, wenn Ihre Datenpipeline rohe Token-Transfer-Events einliest, ohne die Ursprungsvertragsadresse gegen den Vertrag des echten Tokens zu validieren. Ein gefälschtes Token-Event kann als Eingang eines bekannten Stablecoins oder Governance-Tokens erscheinen. Wenn die Software nicht zwischen dem echten und dem gefälschten Vertrag unterscheidet, kann sie einen Phantom-Vermögenswert erfassen. Unternehmen sollten bei ihren Datenanbietern bestätigen, wie die Vertragsverifizierung gehandhabt wird.
Sind Unternehmen verpflichtet, Dust-Transfers im Rahmen von Sanktionsvorschriften zu screenen?
Sanktionsverpflichtungen sind im Allgemeinen transaktionsbasiert und befreien Transfers nicht allein deshalb, weil ihr Wert vernachlässigbar ist. Regulierungsbehörden erwarten jedoch, dass Screening-Programme risikokalibriert sind. Unternehmen können einen Schwellenwert dokumentieren, unterhalb dessen Dust-Transfers als mit vernachlässigbarem wirtschaftlichem Risiko behaftet eingestuft werden, sofern diese Begründung verteidigungsfähig und konsistent angewendet wird. Ein Unternehmen, das Dust-Alerts ohne dokumentierte Begründung ablehnt, befindet sich in einer schwächeren Position als eines, das eine schriftliche Richtlinie hat, die darlegt, warum Transfers von 0,000X USD außerhalb des Bereichs einer bedeutenden Exposition liegen.
Warum variiert Spam so stark zwischen Blockchains?
Gebührenökonomie und Chain-Architektur treiben die Variation voran. Chains mit niedrigen Gebühren wie TRON und Solana machen Massen-Dusting zu fast keinen Kosten pro Transfer machbar, sodass Angreifer es in großem Umfang betreiben. Chains mit höheren Gebühren wie Ethereum machen Massen-Dusting unwirtschaftlich und drängen Angreifer zu weniger, aber präziser ausgerichteten gefälschten Token-Verträgen, die viele Wallets pro Einsatz erreichen können. Solanas Mint-Authority-Validierung macht gefälschtes Token-Spoofing dort auch strukturell unpraktisch, weshalb stattdessen Dust dominiert.
Was sollte ein Unternehmen tun, wenn es gefälschte Token-Events in der Ledger-Historie eines Klienten entdeckt?
Der erste Schritt besteht darin, alle betroffenen Einträge zu identifizieren, indem die Token-Vertragsadresse für jedes Event gegen den veröffentlichten Vertrag des legitimen Tokens validiert wird. Durch gefälschte Verträge erzeugte Einträge sollten umklassifiziert werden, typischerweise als nicht-wirtschaftliche Ereignisse mit Nullwert, und die Anpassung sollte mit einem klaren Prüfpfad dokumentiert werden. Wenn das Ledger zur Erstellung von Finanzberichten oder Steuererklärungen verwendet wurde, ist eine Wesentlichkeitsbeurteilung erforderlich, um festzustellen, ob Änderungen notwendig sind.
Quelle: TRM Labs