Skip to main content

Übersicht

getTransactionsForAddress ist eine exklusive Helius-RPC-Methode, die die Transaktionshistorie einer Adresse mit fortschrittlicher Filterung, flexibler Sortierung und effizienter Paginierung zurückgibt. Es ist nicht Teil des standardmäßigen Solana-RPC. Im Gegensatz zu getSignaturesForAddress, das nur Signaturen zurückgibt und zugehörige Token-Konten überspringt, kann getTransactionsForAddress vollständige Transaktionsdaten zurückgeben, einschließlich der Aktivität eines Wallets im zugehörigen Token-Konto (ATA), in einem einzigen Aufruf. Das macht es zum schnellsten Weg, um eine vollständige Adresshistorie für Backfilling, Indexierung und Analysen zu erhalten. Diese Methode gibt bis zu 1.000 vollständige Transaktionen pro Aufruf zurück.

Flexible Sortierung

Chronologisch (älteste zuerst) oder umgekehrt (neueste zuerst) sortieren.

Fortschrittliche Filterung

Nach Zeitbereichen, Slots, Signaturen, Status und Token-Transfers filtern.

Vollständige Transaktionsdaten

Erhalten Sie vollständige Transaktionsdetails in einem Aufruf, kein Folgeaufruf von getTransaction nötig.

Token-Konten

Transaktionen für die zugehörigen Token-Konten einer Adresse einbeziehen.

Wann man dies benutzt

Verwenden Sie getTransactionsForAddress, wenn Sie benötigen:
  • Vollständige Wallet-Token-Historie, einschließlich zugehöriger Token-Konten
  • Ein schnelles Single-Call-Backfill für einen Indexer oder eine Datenpipeline
  • Zeitbasierte oder Slot-basierte Transaktionsanalyse und Berichterstellung
  • Statusfilterung, um nur erfolgreiche oder nur fehlgeschlagene Transaktionen beizubehalten
  • Chronologische historische Wiedergabe (älteste zuerst Sortierung)
  • Token-Startanalyse: erste Prägungstransaktionen und frühe Halter
  • Wallet-Finanzierungshistorie und Kontrahentenerkennung
  • Compliance- und Prüfberichte für einen bestimmten Zeitraum
Für eine analysierte, nur auf Übertragungen basierende Historie (Zahlungen, Saldenabgleich) verwenden Sie stattdessen getTransfersByAddress.

Netzwerkunterstützung

Schnellstart

1

Holen Sie sich Ihren API-Schlüssel

Holen Sie sich Ihren API-Schlüssel vom Helius Dashboard.
2

Abfrage mit erweiterten Funktionen

Holen Sie sich alle erfolgreichen Transaktionen für ein Wallet zwischen zwei Daten, chronologisch sortiert:
3

Verstehen der Parameter

Dieses Beispiel zeigt die Schlüsselmerkmale:
  • transactionDetails: auf 'full' setzen, um vollständige Transaktionsdaten in einem Aufruf zu erhalten
  • sortOrder: verwenden Sie 'asc' für chronologische Reihenfolge (älteste zuerst) oder 'desc' für die neuesten zuerst
  • filters.blockTime: Zeitbereiche mit gte (größer oder gleich) und lte (kleiner oder gleich) festlegen
  • filters.status: filtern, um nur 'succeeded' oder 'failed' Transaktionen zu behalten
  • filters.tokenAccounts: Transfers, Prägungen und Verbrennungen für zugehörige Token-Konten einbeziehen

Anforderungsparameter

string
erforderlich
Base-58 kodierter öffentlicher Schlüssel des Kontos, für das die Transaktionshistorie abgefragt werden soll
string
Standard:"signatures"
Detailebene der zurückzugebenden Transaktionen:
  • signatures: Basis-Signaturinformationen (schneller)
  • full: Vollständige Transaktionsdaten (eliminiert den Bedarf an getTransaction-Aufrufen, unterstützt Limit bis zu 1.000)
string
Standard:"desc"
Sortierreihenfolge für Ergebnisse:
  • desc: Neueste zuerst (Standard)
  • asc: Älteste zuerst (chronologisch, ideal für historische Analysen)
number
Standard:"1000"
Maximale Anzahl von Transaktionen zur Rückgabe:
  • Bis zu 1000, wenn transactionDetails: "signatures"
  • Bis zu 1000, wenn transactionDetails: "full"
string
Paginierungstoken aus vorheriger Antwort (Format: "slot:position")
string
Standard:"finalized"
Commitment-Level: finalized oder confirmed. Das processed-Commitment wird nicht unterstützt.
object
Erweiterte Filteroptionen zur Eingrenzung der Ergebnisse.
object
Nach Slotnummer mit Vergleichsoperatoren filtern: gte, gt, lte, ltBeispiel: { "slot": { "gte": 1000, "lte": 2000 } }
object
Nach Unix-Zeitstempel mit Vergleichsoperatoren filtern: gte, gt, lte, lt, eqBeispiel: { "blockTime": { "gte": 1640995200, "lte": 1641081600 } }
object
Nach Transaktionssignatur mit Vergleichsoperatoren filtern: gte, gt, lte, ltBeispiel: { "signature": { "lt": "SIGNATURE_STRING" } }
string
Nach Erfolg/Misserfolg-Status der Transaktion filtern:
  • succeeded: Nur erfolgreiche Transaktionen
  • failed: Nur fehlgeschlagene Transaktionen
  • any: Sowohl erfolgreiche als auch fehlgeschlagene (Standard)
Beispiel: { "status": "succeeded" }
string
Standard:"none"
Transaktionen für zugehörige Token-Konten filtern:
  • none: Nur Transaktionen zurückgeben, die die angegebene Adresse referenzieren (Standard)
  • balanceChanged: Transaktionen zurückgeben, die entweder die angegebene Adresse referenzieren oder das Guthaben eines Token-Kontos ändern, das der angegebenen Adresse gehört (empfohlen)
  • all: Transaktionen zurückgeben, die entweder die angegebene Adresse referenzieren oder ein beliebiges Token-Konto ändern, das der angegebenen Adresse gehört
Beispiel: { "tokenAccounts": "balanceChanged" }
object
Auf Transaktionen filtern, bei denen die abgefragte Adresse an einem Token-Transfer teilgenommen hat, der zu einem Kontrahenten passt, der Richtung, Prägung oder einem Rohmengenbereich entspricht. Alle Felder sind optional und werden mit UND-Semantik kombiniert.Beispiel: { "tokenTransfer": { "direction": "in", "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" } }
string
Kontrahentenadresse. Passt zu Transfers, deren andere Seite diese Adresse ist.
string
Standard:"any"
Nach Transferrichtung relativ zur abgefragten Adresse filtern:
  • in: Transfers, die von der abgefragten Adresse empfangen wurden
  • out: Transfers, die von der abgefragten Adresse gesendet wurden
  • any: Ein- und ausgehende Transfers
string
Token-Prägung, nach der gefiltert werden soll.
object
Mengengegenüberstellung unter Verwendung der rohen On-Chain-Menge, nicht der UI- oder dezimalangepaßten Menge. Unterstützt gt, gte, lt und lte.
string
Kodierungsformat für Transaktionsdaten (gilt nur, wenn transactionDetails: "full"). Gleich wie getTransaction API. Optionen: json, jsonParsed, base64, base58
number
Maximal zurückzugebende Transaktionsversion festlegen. Wenn weggelassen, werden nur Legacy-Transaktionen zurückgegeben. Auf 1 setzen, um Legacy-, v0- und v1-Transaktionen einzuschließen.
number
Der minimale Slot, bei dem die Anfrage ausgewertet werden kann

Messung

Erfolgreiche Antworten werden nach dem zurückgegebenen Inhalt gemessen:

Antwort

Die Antwortform ist abhängig von transactionDetails. Signaturen-Modus gibt leichte Signaturdatensätze zurück; Vollständiger Modus gibt vollständige Transaktionen und Metadatenobjekte zurück.

Antwortfelder

Das Feld transactionIndex ist exklusiv für getTransactionsForAddress. Andere ähnliche Endpunkte wie getSignaturesForAddress, getTransaction und getTransactions enthalten dieses Feld nicht. Im vollständigen Modus ist meta das vollständige Transaktionsmetadata-Objekt — identisch in der Form wie getTransaction. Es enthält preTokenBalances und postTokenBalances, sodass Sie Token-Guthabenänderungen (z. B. um Swaps zu erkennen) direkt aus der Antwort berechnen können, ohne weitere Aufrufe.

Filter

Sie können Vergleichsoperatoren für slot, blockTime und signature verwenden, zusätzlich zu den speziellen status, tokenAccounts und tokenTransfer Filtern. Die Kombination mehrerer Filter grenzt das Ergebnis auf deren Schnittmenge ein.

Vergleichsoperatoren

Diese Operatoren funktionieren wie Datenbankabfragen und geben Ihnen präzise Kontrolle über Ihren Datenbereich.

Enum-Filter

Beispiele für kombinierte Filter:

Zugehörige Token-Konten

Auf Solana hält ein Wallet keine Token direkt. Stattdessen besitzt das Wallet Token-Konten, und diese Token-Konten halten die Tokens. Wenn Ihnen jemand USDC sendet, geht es an Ihr USDC-Token-Konto, nicht an Ihre Haupt-Wallet-Adresse. Diese Methode ist einzigartig, da sie eine vollständige Token-Historie abfragen kann, einschließlich der zugehörigen Token-Konten (ATAs) eines Wallets. Native RPC-Methoden wie getSignaturesForAddress enthalten keine ATAs. Der tokenAccounts Filter steuert dieses Verhalten:
  • none (Standard): Gibt nur Transaktionen zurück, die die Wallet-Adresse direkt referenzieren. Verwenden Sie dies, wenn Sie sich nur für direkte Wallet-Interaktionen interessieren.
  • balanceChanged (empfohlen): Gibt Transaktionen zurück, die entweder die Wallet-Adresse referenzieren oder das Guthaben eines Token-Kontos ändern, das dem Wallet gehört. Dies filtert Spam und nicht zusammenhängende Vorgänge wie Gebührensammlungen oder Delegationen aus und bietet Ihnen einen klaren Überblick über die sinnvolle Wallet-Aktivität.
  • all: Gibt alle Transaktionen zurück, die die Wallet-Adresse oder ein beliebiges Token-Konto, das der Wallet gehört, referenzieren.
Der tokenAccounts Filter unterstützt keine Transaktionen vor Dezember 2022. Er ist abhängig von Metadaten der Token-Transfers, die in Solana auf Slot 111,491,819 eingeführt wurden. Um frühere Aktivitäten abzudecken, siehe das historische Workaround für Token-Konten.

Token-Transfer-Filter

Der tokenTransfer Filter grenzt Ergebnisse auf Transaktionen ein, bei denen die abgefragte Adresse an einem Token-Transfer teilgenommen hat, der bestimmten Kriterien entspricht: einem bestimmten Kontrahenten, Prägung, Richtung oder einem Mengenumfang. Verwenden Sie ihn, um Fragen wie:
  • Wann hat diese Wallet USDC von einem bestimmten Kontrahenten erhalten?
  • Zeige alle ausgehenden Transfers über 1.000 Token.
  • Wann hat diese Wallet jemals diese bestimmte Prägung berührt?
Der Filter ist ein optionales Feld innerhalb des filters Objekts der Anfragekonfiguration:
Alle Felder innerhalb tokenTransfer sind optional. Die Kombination mehrerer Felder wird als UND behandelt. Mengengrenzenoperatoren: Sie können Mengenoperatoren kombinieren, wie { "gte": 1000000, "lte": 5000000 } für einen geschlossenen Bereich. tokenTransfer fügt sich mit den anderen obersten Filtern (slot, blockTime, status, und tokenAccounts); das Endergebnis ist der Schnittpunkt.

Beispiele

Zeitbasierte Analysen

Monatliche Transaktionsberichte generieren:
Vorgehensweise für Analysen:

Token-Prägungserstellung

Finden Sie die Transaktion zur Prägungserstellung für ein bestimmtes Token:
Für die Erstellung eines Liquiditätspools, fragen Sie die Pool-Adresse ab:
Dies findet den genauen Moment, in dem eine Token-Prägung oder ein Liquiditätspool erstellt wurde, einschließlich der Erstelleradresse und der Anfangsparameter.

Finanzierungstransaktionen

Finden Sie heraus, wer eine bestimmte Adresse finanziert hat:
Analysieren Sie dann die Transaktionsdaten, um SOL-Transfers zu finden:
Die ersten paar Transaktionen offenbaren oft die Finanzierungsquelle und können helfen, verwandte Adressen oder Finanzierungsmuster zu identifizieren.

Token-Transfers

Mit tokenTransfer filtern, um spezifische Token-Bewegungen zu isolieren. USDC-Zuflüsse zu einer Adresse:
Große ausgehende Transfers zu einem bestimmten Kontrahenten:
Kombiniert mit Slot-Bereich und Status:

Paginierung

Wenn Sie mehr Transaktionen haben als Ihr Limit, verwenden Sie paginationToken aus der Antwort, um die nächste Seite abzurufen. Das Token ist ein einfacher String im Format "slot:position", der der API mitteilt, wo sie fortfahren soll. Verwenden Sie das Paginierungstoken aus jeder Antwort, um die nächste Seite abzurufen:

Mehrere Adressen

Sie können nicht mehrere Adressen in einer einzigen Anfrage abfragen. Jede Adressabfrage zählt als separate API-Anfrage und wird entsprechend gemessen. Um Transaktionen für mehrere Adressen abzurufen, fragen Sie jede Adresse im gleichen Zeit- oder Slotfenster ab und fügen Sie sie dann zusammen und sortieren Sie sie:
Für größere Historienabfragen iterieren Sie durch Zeit- oder Slotfenster (z. B. 1000 Slots auf einmal) und wiederholen Sie dieses Muster.

Beste Praktiken

Leistung. Verwenden Sie transactionDetails: "signatures", wenn Sie keine vollständigen Transaktionsdaten benötigen. Verwenden Sie angemessene Seitengrößen für bessere Antwortzeiten und filtern Sie nach Zeitbereichen oder spezifischen Slots für gezieltere Abfragen. Filterung. Beginnen Sie mit breiten Filtern und engen Sie sich schrittweise ein. Verwenden Sie zeitbasierte Filter für Analyse und Berichterstellungs-Workflows und kombinieren Sie mehrere Filter für präzise Abfragen, die auf bestimmte Transaktionstypen oder Zeiträume abzielen. Paginierung. Speichern Sie Paginierungstokens, wenn Sie große Abfragen später wieder aufnehmen müssen. Überwachen Sie die Paginierungstiefe für die Leistungsplanung und verwenden Sie die aufsteigende Reihenfolge, wenn Sie historische Ereignisse chronologisch wiedergeben müssen. Fehlerbehandlung. Behandeln Sie Rate Limits mit exponentiellem Backoff. Validieren Sie Adressen, bevor Sie Anfragen stellen, und cachen Sie Ergebnisse, wenn passend, um die API-Nutzung zu reduzieren.

Einschränkungen und Randfälle

Ein kleiner Satz von Adressen wird zu Legacy-Archiv-Ressourcen geroutet, ist auf Slot-Scan-Fallback beschränkt oder gibt leere Ergebnisse zurück. Die Entdeckung von Token-Konten vor Slot 111,491,819 erfordert ebenfalls einen Workaround. Erweitern Sie die folgenden Abschnitte für die vollständigen Details.
Zu altem Archiv geroutet. Anfragen für diese Adressen werden zu unserem alten Archivsystem geroutet.Slot-Scan-Fallback. Anfragen für diese Adressen werden zu unserem neuen Archivsystem weitergeleitet und sind durch einen Slot-Scan-Ansatz (maximal 100 Slots) abfragbar. Diese Daten sind jedoch nicht indexiert.Gibt leer zurück (is_reserved_address). Anfragen werden zu unserem neuen Archivsystem weitergeleitet, jedoch sind die Daten nicht indexiert und Abfragen geben leer zurück.
Für Adressen mit Token-Kontoaktivität vor Slot 111,491,819 kann der tokenAccounts Filter die Zugehörigkeit nicht bestimmen, da das Feld owner in Token-Guthabenmetadaten damals nicht existierte. Um vollständige Ergebnisse zu erhalten, können Sie diese Token-Konten manuell entdecken, indem Sie frühe Transaktionsanweisungen analysieren und dann getTransactionsForAddress parallel für jedes Konto abfragen.

Wie unterscheidet sich dies zu getSignaturesForAddress?

Wenn Sie mit der standardmäßigen getSignaturesForAddress Methode vertraut sind, fasst getTransactionsForAddress mehrstufige Abläufe in einem einzigen Aufruf zusammen und fügt Filterung, Sortierung und Unterstützung für Token-Konten hinzu. Für eine schrittweise Umstellung des bestehenden Codes siehe den Migrationsleitfaden.

Vollständige Transaktionen in einem Aufruf erhalten

Mit getSignaturesForAddress benötigen Sie zwei Schritte:
Mit getTransactionsForAddress ist es ein Aufruf:

Token-Historie in einem Aufruf erhalten

Mit getSignaturesForAddress müssen Sie zuerst getTokenAccountsByOwner aufrufen und dann für jedes Token-Konto abfragen:
Mit getTransactionsForAddress müssen Sie nur filters.tokenAccounts setzen:

Zusätzliche Funktionen

Chronologische Sortierung

Sortieren Sie Transaktionen von ältesten zu neuesten mit sortOrder: 'asc'.

Zeitbasierte Filterung

Nach Zeitbereichen mit blockTime Filtern.

Statusfilterung

Holen Sie sich nur erfolgreiche oder fehlgeschlagene Transaktionen mit dem status Filter.

Einfachere Paginierung

Verwenden Sie paginationToken anstelle der verwirrenden before/until Signaturen.

Weitere Schritte

Indexierungsleitfaden

Verwenden Sie getTransactionsForAddress zum Auffüllen und Synchronisieren eines Solana-Index.

getTransfersByAddress

Analysierte, nur auf Übertragungen basierende Historie für Zahlungen und Abgleich.

API-Referenz

Vollständiges Anfrage- und Antwortschema für getTransactionsForAddress.

Übersicht über historische Daten

Vergleichen Sie alle Solana-Historische Datenmethoden.