Skip to main content
Dies ist der Basis-Transaktionspfad — pro Sendung abgerechnet und am besten, wenn Zuverlässigkeit wichtiger ist als reine Geschwindigkeit (Zahlungen, Wallets, Apps). Wenn Sie handeln und die geringste Latenz benötigen, verwenden Sie stattdessen Helius Sender.
Eigene Transaktionslogik zu entwickeln, ist der beste Weg, um maximale Leistung, Kontrolle und Zuverlässigkeit für Ihre Anwendung zu gewährleisten. Während das Helius SDK einen praktischen Einstieg bietet, ist das Verständnis und die Implementierung dieses manuellen Workflows für Produktionssysteme sehr zu empfehlen. Diese Anleitung führt Sie durch die notwendigen Schritte, um Ihre eigene Lösung zu entwickeln.

Der manuelle Workflow

Das manuelle Senden einer Transaktion umfasst folgende Schritte:
1

Erstellen der anfänglichen Transaktion

Stellen Sie Ihre Anweisungen zusammen und signieren Sie die Transaktion, damit sie simuliert werden kann.
2

Optimierung der Recheneinheiten

Simulieren Sie die Transaktion, um die genauen CUs zu bestimmen und fügen Sie einen kleinen Puffer hinzu.
3

Hinzufügen von Prioritätsgebühren

Holen Sie eine Gebührenabschätzung von der Helius Priority Fee API ein und fügen Sie sie Ihrer Transaktion hinzu.
4

Senden und erneut senden

Senden Sie die endgültige Transaktion und implementieren Sie eine robuste Polling-Strategie, um die Bestätigung zu bearbeiten.
Die Helius SDKs sind Open Source. Sie können den zugrunde liegenden Code für die sendSmartTransaction-Methode in unserem TypeScript SDK und Rust SDK ansehen, um eine produktionsreife Implementierung dieses Workflows zu sehen.

1. Erstellen der anfänglichen Transaktion

Zuerst sammeln Sie alle Anweisungen, die Sie in Ihre Transaktion aufnehmen möchten. Erstellen Sie dann ein Transaction- oder VersionedTransaction-Objekt. Sie müssen auch einen aktuellen Blockhash abrufen. Dieses Beispiel bereitet eine versionierte Transaktion vor. In diesem Stadium müssen Sie sie auch signieren, damit sie im nächsten Schritt simuliert werden kann.

2. Optimierung der Nutzung von Recheneinheiten (CU)

Um unnötige Gebühren zu vermeiden oder das Scheitern Ihrer Transaktion zu verhindern, sollten Sie das Limit für die Recheneinheiten (CU) so präzise wie möglich festlegen. Sie können dies tun, indem Sie die Transaktion mit der simulateTransaction-RPC-Methode simulieren. Es ist eine bewährte Praxis, zuerst mit einem hohen CU-Limit zu simulieren, um sicherzustellen, dass die Simulation selbst erfolgreich ist, und dann den unitsConsumed aus der Antwort zu verwenden, um Ihr tatsächliches Limit festzulegen.
Jetzt haben Sie eine Anweisung, die das Berechnungslimit präzise festlegt. Sie werden dies zu Ihrer endgültigen Transaktion hinzufügen.

3. Festlegen der richtigen Prioritätsgebühr

Als nächstes bestimmen Sie die optimale Prioritätsgebühr, die Ihrer Transaktion hinzugefügt werden soll. Die Verwendung der Helius Priority Fee API ist der beste Weg, um eine Echtzeitschätzung basierend auf den aktuellen Netzwerkbedingungen zu erhalten. Sie müssen die getPriorityFeeEstimate-RPC-Methode aufrufen. Für die höchste Einbeziehungschance über die gestakten Verbindungen von Helius verwenden Sie die recommended: true-Option.

4. Erstellen, Senden und Bestätigen

Stellen Sie nun die endgültige Transaktion mit den neuen Budgetanweisungen für die Berechnung zusammen, senden Sie sie und implementieren Sie einen robusten Polling-Mechanismus, um ihre Bestätigung sicherzustellen.
Verlassen Sie sich nicht auf die Standard-Wiederholungslogik des RPC-Anbieters (maxRetries in sendTransaction). Während die gestakten Verbindungen von Helius Ihre Transaktion direkt an den Leader weiterleiten, kann sie dennoch fallengelassen werden. Sie müssen Ihre eigene Logik zur erneuten Aussendung implementieren, um eine zuverlässige Bestätigung zu gewährleisten.
Ein häufiges Muster ist es, dieselbe Transaktion periodisch erneut zu senden, bis der Blockhash abläuft. Signieren Sie die Transaktion nur dann erneut, wenn Sie auch einen neuen Blockhash abrufen. Ein erneutes Signieren mit demselben Blockhash kann dazu führen, dass doppelte Transaktionen bestätigt werden.
Dieses Beispiel bietet eine grundlegende Polling-Schleife. Eine produktionsreife Anwendung erfordert eine ausgefeiltere Logik, einschließlich der Handhabung unterschiedlicher Bestätigungsstatus und möglicher Zeitüberschreitungen.

Schutz vor Sandwich-Angriffen

Um Ihre Transaktion von Validatoren wegzuleiten, die statistisch mit Sandwich-Angriffen in Verbindung stehen, fügen Sie den mev-protect=true-Parameter zu Ihrer RPC-URL hinzu — keine Änderungen an Ihrer Transaktionslogik:

MEV Schutz

Sehen Sie, wie MEV Schutz funktioniert, welche Methoden er unterstützt und welche Kompromisse es gibt.

Verdienen Sie Rabatte auf Ihre Transaktionen

Sie können sich dafür entscheiden, einen Anteil des MEV zu verdienen, den Ihre Transaktionen erzeugen, automatisch in SOL bezahlt — ohne Änderungen an Ihrer Transaktionslogik.

Transaktionsrabatte

Fügen Sie einen Parameter zu Ihren sendTransaction-Aufrufen hinzu, um SOL-Rabatte zu verdienen.

Verwandte Methoden

sendTransaction

Senden Sie eine signierte Transaktion an das Netzwerk

simulateTransaction

Simulieren Sie eine Transaktion, um Recheneinheiten zu schätzen

getSignatureStatuses

Bestätigungsstatus von Transaktionen überprüfen

getLatestBlockhash

Abrufen eines aktuellen Blockhashes zur Transaktionssignierung

getBlockHeight

Aktuelle Blockhöhe für Ablaufprüfungen abrufen