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 LiquidationensendTransactionWithSender. 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
FragegetTransactionsForAddress 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
-
transactionDetails: "full"ist nicht der Standardwert — Standardmäßig gibtgetTransactionsForAddressnur Signaturen zurück. SetzetransactionDetails: "full", um die vollständigen Transaktionsdaten abzurufen. -
Füge bei
sendSmartTransactionkeine ComputeBudget-Anweisungen hinzu — Das SDK fügt sie automatisch hinzu. Wenn du eigene Anweisungen hinzufügst, entstehen Duplikate und die Transaktion schlägt fehl. -
Priority Fees werden in Mikrolamports pro Compute Unit angegeben — Nicht in Lamports. Die Werte aus
getPriorityFeeEstimatehaben bereits die richtige Einheit fürSetComputeUnitPrice. -
Die DAS-Paginierung beginnt bei 1 —
page: 1ist die erste Seite, nichtpage: 0. -
blockTimeverwendet Unix-Sekunden, nicht Millisekunden — VerwendeMath.floor(Date.now() / 1000), wenn du nachblockTimefilterst. -
getAssetblendet fungible token standardmäßig aus — Übergiboptions: { showFungible: true }, um sie einzuschließen. -
WebSocket-streams müssen bereinigt werden — Verwende immer ein AbortController-Signal und rufe anschließend
helius.ws.close()auf, um Verbindungslecks zu vermeiden. -
Setze beim Abrufen von Transaktionen
maxSupportedTransactionVersion: 1. Andernfalls schlagengetTransaction,getBlockundgetTransactionsForAddressmittransactionDetails: "full"bei v1-Transaktionen mit dem Fehler-32015fehl. Bei v1-Transaktionen ist die Priority Feemessage.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 nativeError-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.