Das Ampel-Klassifikationssystem

Jede Transaktion, die DeFi Tracker indexiert, wird automatisch durch den 5-schichtigen Klassifikator (packages/shared/src/classifier) geführt und erhält eine von vier Farben. Die Farbe ist Ihr Sofort-Signal dafür, was Sie — wenn überhaupt — vor der Steuersaison erledigen müssen.

GRÜN — eindeutig klassifiziert

Die Transaktion passt ohne Mehrdeutigkeit auf eine Regel. Beispiele: ein einfacher ERC-20-Transfer zwischen zwei Ihrer eigenen Wallets, ein SparkDEX-Swap, FLR-zu-WFLR-Wrapping oder eine bestätigte FTSO-Delegation-Belohnung. GRÜNE Ereignisse fließen ohne manuelle Prüfung direkt in Ihre CoinTracking-, ELSTER- und DATEV-Exporte.

GELB — der „Graubereich"

Das Ereignis wurde erkannt, aber die BMF-Rechtsprechung lässt die steuerliche Behandlung offen. Wir berechnen zwei Szenarien parallel:

• Modell A (konservativ): strengere Auslegung, höhere Steuerlast
• Modell B (progressiv): nutzerfreundliche Auslegung, niedrigere Last

Sie können pro Ereignis im Detail-Drawer ein Modell auswählen. Liquidity-Pool-Einlagen/-Auszahlungen, Cross-Chain-Bridges und bestimmte Staking-Varianten sind typische GELB-Fälle.

ROT — manuelle Klassifikation erforderlich

Wir erkennen den Vertrag, können aber noch nicht entscheiden, ob das Leg eine Veräußerung, eine Einzahlung oder Rauschen ist. ROT-Einträge erscheinen in der Bulk-Klassifikation-Queue mit Checkbox, damit Sie sie in Batches abarbeiten können. Sie sind aus den Steuersummen ausgeschlossen, bis Sie sie klassifizieren.

GRAU — steuerlich irrelevant

Interne Transfers zwischen Ihren eigenen Wallets, sich aufhebende Bridge-Legs, fehlgeschlagene Transaktionen mit reinen Gas-Kosten und ERC-20-Approvals. GRAU-Ereignisse bleiben im Audit-Trail (damit die On-Chain-Historie aufgeht), erreichen aber niemals Ihre § 23 EStG- oder § 22 Nr. 3 EStG-Summen.

Woher die Farben kommen

Der Klassifikator dispatcht zunächst nach Chain-ID und Vertragsadresse (Layer-0-Chain-Keyed-Registry), danach durch fünf Regelebenen pro Protokollfamilie. Die Topic-Hash-Provenienz wird zur Testzeit aus keccak256(signature) neu abgeleitet — gefälschte Event-Hashes können niemals ausgeliefert werden.

Falls Sie mit einer Farbe nicht einverstanden sind, ist die manuelle Überschreibung im Transaktions-Drawer vollständig auditiert und im GoBD-AuditLog festgeschrieben.