Zum Hauptinhalt springen
Best Practices und empfohlene Muster für Agenten, die das Helius TypeScript SDK verwenden. Informationen zur Installation und zu den ersten Schritten findest du in der Übersicht.

Empfehlungen für Agenten

Verwende getTransactionsForAddress statt einer zweistufigen Abfrage

getTransactionsForAddress kombiniert die Signatursuche und das Abrufen von Transaktionen in einem einzigen Aufruf mit serverseitiger Filterung. Die Methode unterstützt Zeit- und slot-Bereiche, die Filterung nach token-Konten und Paginierung.

Verwende sendSmartTransaction für standardmäßige Sendevorgänge

Die Methode simuliert automatisch, schätzt Compute Units, ruft Priority Fees ab und bestätigt die Transaktion. Erstelle ComputeBudget-Anweisungen nicht manuell — das SDK fügt sie automatisch hinzu.

Verwende Helius Sender für extrem niedrige Latenz

Verwende für zeitkritische Transaktionen wie Arbitrage, Sniping und Liquidationen sendTransactionWithSender. Die Methode leitet sie über die Multi-Region-Infrastruktur von Helius und Jito weiter.

Verwende getAssetBatch für mehrere Assets

Fasse das Abrufen mehrerer Assets zu einem Batch zusammen. Rufe getAsset nicht in einer Schleife auf.

Verwende webhook oder WebSockets statt Polling

Frage getTransactionsForAddress nicht wiederholt in einer Schleife ab. Verwende webhook für Server-zu-Server-Benachrichtigungen oder WebSockets für clientseitiges Echtzeit-Streaming.

Paginierung

Das SDK verwendet je nach Methode unterschiedliche Paginierungsstrategien.

token-/Cursor-basiert (RPC-V2-Methoden)

Seitenbasiert (DAS API)

tokenAccounts-Filter

Wenn du getTransactionsForAddress abfragst, steuert der Filter tokenAccounts, ob Aktivitäten von token-Konten enthalten sind:

changedSinceSlot — Inkrementelles Abrufen von Konten

changedSinceSlot gibt nur Konten zurück, die nach einem bestimmten slot geändert wurden. Das ist für Workflows zur Synchronisierung oder Indexierung nützlich. Unterstützt von getProgramAccountsV2, getTokenAccountsByOwnerV2, getAccountInfo, getMultipleAccounts, getProgramAccounts und getTokenAccountsByOwner.

Häufige Fehler

  1. transactionDetails: "full" ist nicht der Standardwert — Standardmäßig gibt getTransactionsForAddress nur Signaturen zurück. Setze transactionDetails: "full", um die vollständigen Transaktionsdaten abzurufen.
  2. Füge bei sendSmartTransaction keine ComputeBudget-Anweisungen hinzu — Das SDK fügt sie automatisch hinzu. Wenn du eigene Anweisungen hinzufügst, entstehen Duplikate und die Transaktion schlägt fehl.
  3. Priority Fees werden in Mikrolamports pro Compute Unit angegeben — Nicht in Lamports. Die Werte aus getPriorityFeeEstimate haben bereits die richtige Einheit für SetComputeUnitPrice.
  4. Die DAS-Paginierung beginnt bei 1 — page: 1 ist die erste Seite, nicht page: 0.
  5. blockTime verwendet Unix-Sekunden, nicht Millisekunden — Verwende Math.floor(Date.now() / 1000), wenn du nach blockTime filterst.
  6. getAsset blendet fungible token standardmäßig aus — Übergib options: { showFungible: true }, um sie einzuschließen.
  7. WebSocket-streams müssen bereinigt werden — Verwende immer ein AbortController-Signal und rufe anschließend helius.ws.close() auf, um Verbindungslecks zu vermeiden.
  8. Setze beim Abrufen von Transaktionen maxSupportedTransactionVersion: 1. Andernfalls schlagen getTransaction, getBlock und getTransactionsForAddress mit transactionDetails: "full" bei v1-Transaktionen mit dem Fehler -32015 fehl. Bei v1-Transaktionen ist die Priority Fee message.transactionConfig.priorityFee, also ein Gesamtbetrag in Lamports. Es gibt keine ComputeBudget-Anweisungen, die durchsucht werden können. Weitere Informationen findest du unter Unterstützung für Transaction v1.

Fehlerbehandlung und Wiederholungsversuche

Das SDK löst native Error-Objekte aus, bei denen der HTTP-Statuscode in der Meldungszeichenfolge enthalten ist, zum Beispiel "API error (429): ...". Das Fehlerobjekt besitzt keine .status-Eigenschaft. Um den Status zu erkennen, musst du daher die Meldung parsen.