Skip to main content

Warum migrieren?

Die Standardmethode, um die Transaktionshistorie einer Adresse auf Solana abzurufen, erfolgt in zwei Schritten: Aufruf von getSignaturesForAddress, um Signaturen aufzulisten, dann Aufruf von getTransaction einmal pro Signatur, um die Details abzurufen. Für 1.000 Transaktionen sind das 1.001 HTTP-Anfragen. getTransactionsForAddress ist eine Helius-exklusive RPC-Methode, die beide Schritte in einen Aufruf zusammenfasst. Sie liefert bis zu 1.000 vollständige Transaktionen pro Anfrage, mit Filterung, bidirektionaler Sortierung und Token-Account-Unterstützung, die die Standardmethoden nicht bieten. Das Ergebnis: etwa 10x weniger Credits, 1.000x weniger Rundreisen und keine clientseitige Bündelung, Ratenbegrenzungsbehandlung oder Wiederholungslogik für das getTransaction Fan-Out.

Vorher und nachher

Hier ist dieselbe Aufgabe — Abrufen der letzten 1.000 Transaktionen für eine Adresse mit vollständigen Details — in beiden Mustern:
getTransactionsForAddress ist kein Teil des standardmäßigen Solana RPC, daher hat @solana/web3.js keinen Connection Helfer dafür. Rufe es mit einer rohen JSON-RPC-Anfrage auf, wie oben gezeigt – es funktioniert im selben Helius-Endpunkt wie der Rest deines RPC-Verkehrs.

Parameterzuordnung

Jede Option aus dem alten Zweischritt-Flow hat ein direktes Äquivalent. Die meisten Namen bleiben unverändert – nur die Paginierung funktioniert anders.

Von getSignaturesForAddress

Von getTransaction

Zwei Fähigkeiten haben überhaupt kein altes Äquivalent:
  • filters — schränkt Ergebnisse nach blockTime, slot, status, tokenTransfer oder tokenAccounts serverseitig ein, anstatt alles abzurufen und im Code zu filtern.
  • sortOrder: "asc" — chronologisch (älteste zuerst) Ergebnisse, die die Standardmethoden nicht zurückgeben können, ohne die gesamte Historie abzurufen und umzukehren.

Migrationsschritte

1

Bestätige, dass du auf einem Helius-Endpunkt bist

getTransactionsForAddress ist Helius-exklusiv. Es funktioniert auf https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY (und Devnet) – derselbe Endpunkt, den deine bestehenden Aufrufe bereits nutzen, wenn du ein Helius-Kunde bist. Keine API-Schlüssel- oder Planänderungen erforderlich.
2

Ersetze den Zweischritt-Abruf durch einen Aufruf

Lösche den getSignaturesForAddress Aufruf und die getTransaction Schleife. Mache eine einzelne getTransactionsForAddress Anfrage mit transactionDetails: "full" und übertrage deine encoding, maxSupportedTransactionVersion und commitment Werte, wie in der Parameterzuordnung gezeigt.Wenn du nur Signaturen benötigst (zum Beispiel, um eine bestehende Pipeline zu versorgen), verwende stattdessen transactionDetails: "signatures" – es kostet 10 Credits pauschal pro Aufruf.
3

Aktualisiere die Antwortverarbeitung

Die Antwortstruktur ändert sich in drei Punkten:
  • Ergebnisse befinden sich in result.data (ein Array), nicht direkt in result.
  • Jeder Eintrag im Vollmodus ist { slot, transactionIndex, blockTime, transaction, meta }. Die transaction und meta Objekte sind in der Struktur identisch zu dem, was getTransaction zurückgibt, sodass dein Parser-Code unverändert bleibt.
  • Einträge im Signaturenmodus entsprechen der getSignaturesForAddress Ausgabe (signature, slot, err, memo, blockTime, confirmationStatus) plus einem neuen transactionIndex Feld.
Ein Verhaltensunterschied, den du beachten solltest: Mit dem alten Muster konnte ein getTransaction Aufruf null für eine Signatur zurückgeben. Mit getTransactionsForAddress ist jeder Eintrag in result.data eine vollständige Transaktion – entferne jegliche Nullbehandlung für fehlende Details.
4

Ersetze die signaturbasierte Paginierung

Tausche die before Cursor-Schleife gegen paginationToken aus:
Die Schleife endet, wenn paginationToken null ist – keine vergleichenden Signaturlisten mehr oder Selbstverfolgung der letzten Signatur erforderlich.Wenn du until verwendet hast, um bei einer bekannten Signatur zu stoppen, ersetze es durch filters.signature: { gt: "KNOWN_SIGNATURE" }. Wenn du es verwendet hast, um zu einem Zeitpunkt zu stoppen, ist filters.blockTime oder filters.slot normalerweise eine sauberere Lösung.
5

Optional: vollständige Token-Historie aktivieren

Das alte Muster verpasst die Aktivitäten des zugehörigen Token-Accounts (ATA) vollständig, es sei denn, du hast auch getTokenAccountsByOwner aufgerufen und Signaturen für jedes Token-Konto abgerufen. Um es einzuschließen, füge einen Filter hinzu:
balanceChanged gibt Transaktionen zurück, die sich auf die Brieftasche beziehen oder das Guthaben eines von ihr besessenen Token-Kontos ändern, wobei Spam herausgefiltert wird. Sieh dir zugehörige Token-Konten für die none/balanceChanged/all Optionen und das Vor-2022-Argument an.
6

Verifiziere gegen die alte Ausgabe

Für eine Beispieladresse, hole die Historie auf beide Arten ab und vergleiche die Signatursätze. Mit filters.tokenAccounts nicht gesetzt (der Standard none), gibt getTransactionsForAddress dieselben Transaktionen wie getSignaturesForAddress für denselben Bereich zurück. Dann bereitstellen und den alten Codepfad entfernen.

Verhaltensunterschiede überprüfen

Die meisten Migrationen sind ein nahtloser Ersatz, aber überprüfe diese Punkte vor dem Versand:
  • Engagement. processed wird nicht unterstützt; verwende confirmed oder finalized. Wenn dein alter Code habe aktuelle Historie bei processed abgerufen, wechsle zu confirmed.
  • Messung. Volltransaktionsantworten kosten 10 Credits pro 100 zurückgegebenen Transaktionen (10-Credit-Mindestbetrag); reine Signaturantworten kosten 10 Credits pauschal. Das alte Muster kostete 1 Credit pro Aufruf – günstiger pro Anfrage, aber viel teurer pro abgerufene Transaktion. Fehlgeschlagene Antworten sind kostenlos. Siehe Messung.
  • Netzwerkunterstützung. Mainnet hat unbegrenzte Aufbewahrung. Devnet wird mit 2 Wochen Aufbewahrung unterstützt. Testnet wird nicht unterstützt.
  • Reservierte Adressen. Eine kleine Anzahl von Systemadressen (Vote Program, System Program, sysvars) umleiten zu Fallback-Archivpfaden oder geben nichts zurück. Wenn du diese indizierst, überprüfe Einschränkungen und Sonderfälle.
  • Mehrere Adressen. Wie beim alten Flow deckt eine Anfrage eine Adresse ab. Anfrage parallelisieren und zusammenführen; siehe mehrere Adressen.

Häufig gestellte Fragen

Ist getTransactionsForAddress eine standardmäßige Solana RPC-Methode?

Nein. Es ist eine Helius-exklusive Methode, die auf Helius RPC-Endpunkten verfügbar ist. Standardmäßige Solana RPC und andere Anbieter bieten nur getSignaturesForAddress und getTransaction an. Deine anderen RPC-Aufrufe sind nicht betroffen – die Methode lebt am selben Endpunkt neben der gesamten standardmäßigen RPC-Oberfläche.

Benötige ich nach der Migration immer noch getTransaction?

Nur für einmalige Abfragen, bei denen du bereits eine Signatur und keinen Adresskontext hast, z. B. um eine spezifische Transaktion zu überprüfen, die ein Benutzer eingegeben hat. Für alle adressbasierten Historien – Backfills, Indizierung, Wallet-Aktivitätsfeeds – ersetzt getTransactionsForAddress beide Methoden.

Funktioniert es mit @solana/web3.js?

Die Methode ist nicht in der Connection Klasse, aber sie funktioniert mit jedem HTTP-Client gegen deine Helius RPC-URL. Verwende fetch (oder das Äquivalent deiner Sprache) mit einem standardmäßigen JSON-RPC-Body, wie in den obigen Beispielen gezeigt. Du kannst Connection für alles andere weiterhin verwenden.

Gibt es dieselben Transaktionen zurück wie getSignaturesForAddress?

Ja. Mit Standardeinstellungen (filters.tokenAccounts: "none") gibt es Transaktionen zurück, die sich auf die abgefragte Adresse beziehen – dasselbe wie getSignaturesForAddress. Das Setzen von tokenAccounts auf balanceChanged oder all gibt mehr zurück: Es fügt Aktivitäten aus den mit der Brieftasche verbundenen Token-Konten hinzu, die die Standardmethode nicht sehen kann.

Wie viel kostet es im Vergleich zum alten Muster?

Das Abrufen von 1.000 vollständigen Transaktionen kostet 100 Credits mit getTransactionsForAddress im Vergleich zu etwa 1.001 Credits (und 1.001 Anfragen) mit getSignaturesForAddress + getTransaction. Nur Signaturantworten kosten 10 Credits pauschal pro Aufruf. Siehe Helius Credits für vollständige Preisangaben.

Lass einen KI-Agenten die Migration durchführen

Wenn du Claude Code, Cursor oder einen anderen Coding-Agenten verwendest, füge die Eingabeaufforderung unten in die Agentensitzung deines Repositories ein. Er findet das alte Muster in deinem Code und schreibt es um.
Die Eingabeaufforderung ist eigenständig – der Agent benötigt keinen Zugriff auf diese Seite. Für agentenbereite Dokumente, MCP-Suche und Fähigkeiten siehe Helius für KI-Agenten.

Nächste Schritte

getTransactionsForAddress Anleitung

Vollständiges Tutorial zu Filtern, Sortieren, Paginierung und Token-Konten.

API-Referenz

Vollständiges Anforderungs- und Antwortschema.

Indizierungsanleitung

Verwende getTransactionsForAddress, um einen Solana-Index zu füllen und zu synchronisieren.

Überblick über historische Daten

Vergleiche alle Solana-Historien-Datenmethoden.