> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Vorverarbeitete Transaktionen: Vor-Ausführung Solana-Daten ohne Deshredding

> Streamen Sie vor-Ausführung Solana-Transaktionen, bevor sie den verarbeiteten Commitment-Level erreichen. Helius übernimmt die Shred-Decodierung — Sie erhalten signierte Transaktionen über WebSocket.

## Übersicht

Vorverarbeitete Transaktionen sind vor-Ausführung Solana-Transaktionen, die **bevor sie den `processed` Commitment-Level erreichen** geliefert werden. Helius aggregiert mehrere vor-Ausführung-Quellen — hauptsächlich direkt dekodierte Shreds bei Eingang am Validator, ergänzt durch [Prekonfirmation](/docs/de/pre-confirmations/overview)-Signale — und liefert sie als einen deduplizierten Stream, ohne dass Rohshred-Pakete empfangen oder eine Deshredding-Infrastruktur auf Ihrer Seite betrieben werden müssen.

Transaktionen, die aus Prekonfirmationssignalen stammen, erreichen diesen Feed später als das dedizierte [Prekonfirmationen](/docs/de/pre-confirmations/overview)-Produkt, das weiterhin den frühesten Zugriff bietet.

Der Weg, vorverarbeitete Transaktionen zu konsumieren, ist die [`preprocessedSubscribe` WebSocket-Methode](/docs/de/preprocessed-transactions/preprocessed-subscribe) (Public Beta) — verfügbar in **allen kostenpflichtigen Plänen** für **0,1 Kredite pro Nachricht**.

<CardGroup cols={2}>
  <Card title="preprocessedSubscribe (WSS)" icon="tower-broadcast" href="/docs/de/preprocessed-transactions/preprocessed-subscribe">
    Die empfohlene Methode, um vorverarbeitete Transaktionen zu streamen: Konto-Filterung, kompakte Binärdaten, alle kostenpflichtigen Pläne.
  </Card>
</CardGroup>

## Wo vorverarbeitete Transaktionen im Lebenszyklus stehen

In der Architektur von Solana durchlaufen Transaktionen mehrere Phasen, bevor sie vollständig verarbeitet werden:

1. **Shred-Empfang** → Validator empfängt Transaktions-Shreds (Datenfragmente). ← **[Rohshreds (UDP)](/docs/de/shred-delivery/raw-shreds)** werden hier geliefert.
2. **Shred-Decodierung** → Shreds werden in Rohtransaktionen dekodiert. ← **Vorverarbeitete Transaktionen werden hauptsächlich hier geliefert.**
3. **Transaktionsausführung** → Transaktion wird von der Laufzeit ausgeführt.
4. **Metadatenerstellung** → Vor/Nach-Bilanzen, Logs und Fehlermeldungen werden berechnet.
5. **Commitment** → Transaktion erreicht verarbeiteten/bestätigten/finalisierten Zustand. ← **[LaserStream gRPC](/docs/de/laserstream)** und **[LaserStream WebSocket](/docs/de/rpc/websocket)** liefern hier.

Post-Execution-Subskriptionen liefern Daten in Phase 5 — nach vollständiger Ausführung und Metadatenerstellung. Vorverarbeitete Transaktionen werden in Phase-2-Zeit geliefert — nach Shred-Decodierung, bevor die Ausführung abgeschlossen ist. Für ein noch früheres Signal streamen [Prekonfirmationen](/docs/de/pre-confirmations/overview) Transaktionen, bevor sie zu Shreds werden.

**Der Kompromiss:** Sie erhalten Transaktionsdaten früher, aber ohne Ausführungsmetadaten wie Bilanzänderungen, Logs oder Fehlermeldungen.

<Warning>
  **Dies ist ein reiner Transaktions-Stream.** Konto- und Programmstatusaktualisierungen
  existieren erst, wenn die Laufzeit die Transaktion ausführt. Wenn Sie Echtzeit-
  Konto- oder Programmaktualisierungen benötigen — Token-Bilanzen, Bonding-Kurven-Zustand, Programm-
  Konten — verwenden Sie **[LaserStream gRPC](/docs/de/laserstream) bei `processed` Commitment**
  stattdessen.
</Warning>

## Welche Daten sind verfügbar?

Vorverarbeitete Transaktionen beinhalten die vollständige signierte Transaktion, aber keine Ausführungsmetadaten:

### Verfügbare Daten

* ✅ **Transaktionssignatur** - Eindeutiger Transaktionsidentifikator
* ✅ **Kontoschlüssel** - Alle von der Transaktion referenzierten Konten
* ✅ **Anweisungen** - Vollständige Anweisungsdaten und Programmaufrufe
* ✅ **Aktueller Blockhash** - Referenz für das Transaktionsablaufdatum
* ✅ **Signaturen** - Alle Transaktionssignaturen
* ✅ **Slotnummer** - In welchem Slot die Transaktion beobachtet wurde

### Fehlende Daten

* ❌ **Transaktionsmetadata** - Token-Bilanzänderungen, Vor/Nach-Bilanzen, Transaktionsstatus
* ❌ **Transaktionsfehler** - Wir können nicht feststellen, ob die Transaktion fehlgeschlagen ist
* ❌ **Innere Anweisungen** - Cross-Program-Aufrufe (CPIs) sind nicht enthalten
* ❌ **Log-Meldungen** - Programmlogs werden während der Ausführung generiert
* ❌ **Verbrauchte Recheneinheiten** - Ausführungsmetriken nicht verfügbar

Betrachten Sie vorverarbeitete Transaktionen als den Erhalt des "Vorschlags" ohne das "Ergebnis". Sie sehen, was der Absender versuchte, aber nicht, was tatsächlich geschah.

## Liefergarantien

Die Lieferung erfolgt nach dem Best-Effort-Prinzip, nicht garantiert, und es gibt keine historische Wiedergabe. Ein gestreamte Transaktion ist ein vor-Ausführungs-Signal, nicht ein Commitment-Level — sie kann fehlschlagen, verworfen werden oder in einem anderen Fork landen. Deduplizieren nach Signatur und abgleichen mit einem verarbeiteten oder bestätigten Stream, wenn Ausführungsergebnisse von Bedeutung sind.

Für kritische Anwendungen, die garantierte Lieferung und vollständige Daten erfordern, verwenden Sie stattdessen [LaserStream gRPC](/docs/de/laserstream).

## Wann sollten vorverarbeitete Transaktionen verwendet werden

Latenzempfindliche Anwendungen, die dekodierte, vor-Ausführung Transaktionen ohne Betrieb eines Shred-Decoders wünschen:

* propAMMs
* Sniper
* Copy Trader
* Liquidationsbots
* Arbitrage

Wenn jede Mikrosekunde zählt und Sie in der Lage sind, am Leitungstempo zu deshreddern, verwenden Sie [Rohshreds (UDP)](/docs/de/shred-delivery/raw-shreds). Wenn Sie das frühestmögliche Signal benötigen, verwenden Sie [Prekonfirmationen](/docs/de/pre-confirmations/overview).

## Preisgestaltung

[`preprocessedSubscribe`](/docs/de/preprocessed-transactions/preprocessed-subscribe) ist in **allen kostenpflichtigen Plänen** verfügbar und wird mit **0,1 Krediten pro Nachricht** abgerechnet — eine Nachricht pro gelieferte Transaktion. Einzelheiten finden Sie unter [Credits](/docs/de/billing/credits).

## FAQs

<AccordionGroup>
  <Accordion title="Können Sie Echtzeit-Filters bei vorverarbeitete Subskriptionen aktualisieren?">
    Nein, das Filter ist durch die initiale `preprocessedSubscribe` festgelegt. Um eine Lücke zu vermeiden, empfehlen wir, eine zweite Verbindung mit dem neuen Filter zu öffnen, auf deren Bestätigung zu warten und dann Ihren Service auf den neuen Filter umzustellen.
  </Accordion>

  <Accordion title="Ist das vorverarbeiteteSubscribe zeitgleiche Subskriptionslimit pro API-Schlüssel oder Konto?">
    Das Limit von 10 gleichzeitigen Verbindungen wird pro API-Schlüssel durchgesetzt. Jeder API-Schlüssel in einem Projekt erhält sein eigenes 10-Verbindungs-Limit.
  </Accordion>
</AccordionGroup>

## Nächste Schritte

<CardGroup cols={2}>
  <Card title="Abonnieren mit preprocessedSubscribe" icon="tower-broadcast" href="/docs/de/preprocessed-transactions/preprocessed-subscribe">
    Endpunkt, Konto-Filterung, Binärdatenlayout und Code-Beispiele.
  </Card>

  <Card title="Prekonfirmationen" icon="bolt" href="/docs/de/pre-confirmations/overview">
    Transaktionen, die gestreamt werden, bevor sie zu Shreds werden — das früheste Transaktionssignal.
  </Card>

  <Card title="Rohshreds (UDP)" icon="network-wired" href="/docs/de/shred-delivery/raw-shreds">
    Unverarbeitete Shred-Pakete über UDP. Sie implementieren das Deshredding.
  </Card>

  <Card title="Helius Sender" icon="paper-plane" href="/docs/de/sending-transactions/sender">
    Handeln Sie basierend auf dem, was Sie sehen, mit der schnellsten Transaktionsausführung.
  </Card>
</CardGroup>