Zum Hauptinhalt springen

Übersicht

getTransactionsForAddress ist eine exklusive RPC-Methode von Helius. Sie gibt den Transaktionsverlauf einer Adresse mit erweiterten Filtern, flexibler Sortierung und effizienter Paginierung zurück. Sie gehört nicht zum standardmäßigen Solana RPC. Im Gegensatz zu getSignaturesForAddress, das nur Signaturen zurückgibt und zugehörige Konten für Token überspringt, kann getTransactionsForAddress vollständige Transaktionsdaten zurückgeben. Dazu gehören auch Aktivitäten in den zugehörigen Konten für Token (ATA) eines Wallets. Dafür genügt ein einziger Aufruf. So erhältst du am schnellsten einen vollständigen Adressverlauf für backfill, Indizierung und Analysen. Diese Methode gibt pro Aufruf bis zu 1.000 vollständige Transaktionen zurück.

Flexible sorting

Sortiere chronologisch (älteste zuerst) oder umgekehrt (neueste zuerst).

Advanced filtering

Filtere nach Zeiträumen, slots, Signaturen, Status und Übertragungen von Token.

Full transaction data

Rufe vollständige Transaktionsdetails mit einem einzigen Aufruf ab. Ein nachfolgender getTransaction-Aufruf ist nicht nötig.

Token accounts

Schließe Transaktionen für die zugehörigen Konten für Token einer Adresse ein.

Wann du diese Methode verwenden solltest

Verwende getTransactionsForAddress, wenn du Folgendes brauchst:
  • Vollständiger Verlauf der Token eines Wallets, einschließlich der zugehörigen Konten für Token
  • Schneller backfill mit einem einzigen Aufruf für einen Indexer oder eine Datenpipeline
  • Zeit- oder slot-basierte Transaktionsanalyse und Berichterstellung
  • Statusfilter, um nur erfolgreiche oder nur fehlgeschlagene Transaktionen zu behalten
  • Chronologische Wiedergabe historischer Daten (älteste zuerst)
  • Analyse von Token-Launches: erste Mint-Transaktionen und frühe Inhaber
  • Finanzierungsverlauf eines Wallets und Ermittlung von Gegenparteien
  • Compliance- und Prüfberichte für einen bestimmten Zeitraum
Verwende stattdessen getTransfersByAddress, wenn du einen geparsten Verlauf ausschließlich für Übertragungen brauchst, etwa für Zahlungen oder den Saldenabgleich.

Netzwerkunterstützung

Schnellstart

1

Get your API key

Rufe deinen API key im Helius Dashboard ab.
2

Query with advanced features

Rufe alle erfolgreichen Transaktionen für ein Wallet zwischen zwei Datumsangaben ab und sortiere sie chronologisch:
3

Understand the parameters

Dieses Beispiel zeigt die wichtigsten Funktionen:
  • transactionDetails: Setze den Wert auf 'full', um vollständige Transaktionsdaten mit einem einzigen Aufruf abzurufen
  • sortOrder: Verwende 'asc' für die chronologische Reihenfolge (älteste zuerst) oder 'desc' für die neuesten zuerst
  • filters.blockTime: Lege Zeiträume mit gte (größer oder gleich) und lte (kleiner oder gleich) fest
  • filters.status: Filtere ausschließlich nach 'succeeded' oder 'failed' Transaktionen
  • filters.tokenAccounts: Schließe Übertragungen, Mints und Burns für zugehörige Konten für Token ein

Request-Parameter

string
erforderlich
Base58-codierter öffentlicher Schlüssel des Kontos, dessen Transaktionsverlauf du abfragen möchtest
string
Standard:"signatures"
Detailstufe der zurückgegebenen Transaktionen:
  • signatures: Grundlegende Signaturinformationen (schneller)
  • full: Vollständige Transaktionsdaten (macht getTransaction-Aufrufe überflüssig und unterstützt ein Limit von bis zu 1.000)
string
Standard:"desc"
Sortierreihenfolge der Ergebnisse:
  • desc: Neueste zuerst (Standard)
  • asc: Älteste zuerst (chronologisch, ideal für historische Analysen)
number
Standard:"1000"
Maximale Anzahl zurückgegebener Transaktionen:
  • Bis zu 1000 bei transactionDetails: "signatures"
  • Bis zu 1000 bei transactionDetails: "full"
string
Paginierungs-token aus der vorherigen response (Format: "slot:position")
string
Standard:"finalized"
commitment-Stufe: finalized oder confirmed. Das commitment processed wird nicht unterstützt.
object
Erweiterte Filteroptionen zum Eingrenzen der Ergebnisse.
object
Filtere mit Vergleichsoperatoren nach der slot-Nummer: gte, gt, lte, ltBeispiel: { "slot": { "gte": 1000, "lte": 2000 } }
object
Filtere mit Vergleichsoperatoren nach dem Unix-Zeitstempel: gte, gt, lte, lt, eqBeispiel: { "blockTime": { "gte": 1640995200, "lte": 1641081600 } }
object
Filtere mit Vergleichsoperatoren nach der Transaktionssignatur: gte, gt, lte, ltBeispiel: { "signature": { "lt": "SIGNATURE_STRING" } }
string
Filtere nach dem Erfolgs- oder Fehlerstatus der Transaktion:
  • succeeded: Nur erfolgreiche Transaktionen
  • failed: Nur fehlgeschlagene Transaktionen
  • any: Erfolgreiche und fehlgeschlagene Transaktionen (Standard)
Beispiel: { "status": "succeeded" }
string
Standard:"none"
Filtere Transaktionen für zugehörige Konten für Token:
  • none: Gibt nur Transaktionen zurück, die auf die angegebene Adresse verweisen (Standard)
  • balanceChanged: Gibt Transaktionen zurück, die entweder auf die angegebene Adresse verweisen oder den Saldo eines Kontos für Token ändern, das der angegebenen Adresse gehört (empfohlen)
  • all: Gibt Transaktionen zurück, die entweder auf die angegebene Adresse oder auf ein beliebiges Konto für Token verweisen, das der angegebenen Adresse gehört
Beispiel: { "tokenAccounts": "balanceChanged" }
object
Filtere nach Transaktionen, bei denen die abgefragte Adresse an einer Übertragung von Token beteiligt war, die einer Gegenpartei, Richtung, Mint oder einem Bereich von Rohbeträgen entspricht. Alle Felder sind optional und werden mit einer UND-Verknüpfung kombiniert.Beispiel: { "tokenTransfer": { "direction": "in", "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" } }
string
Adresse der Gegenpartei. Entspricht Übertragungen, deren andere Seite diese Adresse ist.
string
Standard:"any"
Filtere nach der Übertragungsrichtung relativ zur abgefragten Adresse:
  • in: Von der abgefragten Adresse empfangene Übertragungen
  • out: Von der abgefragten Adresse gesendete Übertragungen
  • any: Eingehende und ausgehende Übertragungen
string
Mint des Token, nach dem gefiltert werden soll.
object
Betragsvergleich anhand des unverarbeiteten On-Chain-Betrags, nicht anhand des UI-Betrags oder des um Dezimalstellen angepassten Betrags. Unterstützt gt, gte, lt und lte.
string
Codierungsformat für Transaktionsdaten (gilt nur bei transactionDetails: "full"). Entspricht der API getTransaction. Optionen: json, jsonParsed, base64, base58
number
Lege die maximale zurückzugebende Transaktionsversion fest. Wenn du den Wert weglässt, werden nur Legacy-Transaktionen zurückgegeben. Setze ihn auf 1, um Legacy-, v0- und v1-Transaktionen einzuschließen.
number
Der minimale slot, an dem der request ausgewertet werden kann

Abrechnung

Erfolgreiche responses werden nach den zurückgegebenen Daten abgerechnet:

Response

Die Struktur der response hängt von transactionDetails ab. Der Signaturmodus gibt kompakte Signaturdatensätze zurück. Der vollständige Modus gibt vollständige Transaktions- und Metadatenobjekte zurück.

Response-Felder

Das Feld transactionIndex gibt es nur bei getTransactionsForAddress. Andere ähnliche endpoints wie getSignaturesForAddress, getTransaction und getTransactions enthalten dieses Feld nicht. Im vollständigen Modus ist meta das vollständige Objekt mit Transaktionsmetadaten. Seine Struktur entspricht exakt der response von getTransaction. Es enthält preTokenBalances und postTokenBalances. So kannst du Änderungen am Saldo von Token direkt aus der response berechnen, etwa um Swaps zu erkennen. Weitere Aufrufe sind nicht nötig.

Filter

Du kannst Vergleichsoperatoren für slot, blockTime und signature sowie die speziellen Filter status, tokenAccounts und tokenTransfer verwenden. Wenn du mehrere Filter kombinierst, wird das Ergebnis auf ihre Schnittmenge eingegrenzt.

Vergleichsoperatoren

Diese Operatoren funktionieren wie Datenbankabfragen und geben dir präzise Kontrolle über deinen Datenbereich.

Enum-Filter

Beispiele für kombinierte Filter:

Zugehörige Konten für Token

Auf Solana hält ein Wallet Token nicht direkt. Stattdessen besitzt das Wallet Konten für Token, in denen die Token liegen. Wenn dir jemand USDC sendet, wird es an dein USDC-Konto gesendet, nicht an deine primäre Wallet-Adresse. Diese Methode ist einzigartig, weil sie den vollständigen Verlauf von Token einschließlich der zugehörigen Konten für Token (ATAs) eines Wallets abfragen kann. Native RPC-Methoden wie getSignaturesForAddress schließen ATAs nicht ein. Der Filter tokenAccounts steuert dieses Verhalten:
  • none (Standard): Gibt nur Transaktionen zurück, die direkt auf die Wallet-Adresse verweisen. Verwende diese Option, wenn dich nur direkte Interaktionen mit dem Wallet interessieren.
  • balanceChanged (empfohlen): Gibt Transaktionen zurück, die auf die Wallet-Adresse verweisen oder den Saldo eines Kontos für Token ändern, das dem Wallet gehört. Dadurch werden Spam und nicht zugehörige Vorgänge wie das Einziehen von Gebühren oder Delegierungen herausgefiltert. Du erhältst eine übersichtliche Darstellung relevanter Wallet-Aktivitäten.
  • all: Gibt alle Transaktionen zurück, die auf die Wallet-Adresse oder ein beliebiges Konto für Token verweisen, das dem Wallet gehört.
Der Filter tokenAccounts unterstützt keine Transaktionen vor Dezember 2022. Er basiert auf Metadaten zu Übertragungen von Token, die mit slot 111.491.819 in Solana eingeführt wurden. Informationen zu früheren Aktivitäten findest du in der Behelfslösung für historische Konten für Token.

Filter für Übertragungen von Token

Der Filter tokenTransfer grenzt die Ergebnisse auf Transaktionen ein, bei denen die abgefragte Adresse an einer Übertragung von Token beteiligt war, die bestimmten Kriterien entspricht: einer bestimmten Gegenpartei, Mint, Richtung oder einem Betragsbereich. Damit kannst du Fragen wie diese beantworten:
  • Wann hat dieses Wallet USDC von einer bestimmten Gegenpartei empfangen?
  • Zeige alle ausgehenden Übertragungen über 1.000 Token.
  • Wann hat dieses Wallet mit dieser bestimmten Mint interagiert?
Der Filter ist ein optionales Feld im Objekt filters der request-Konfiguration:
Alle Felder in tokenTransfer sind optional. Mehrere Felder werden mit UND kombiniert. Operatoren für Betragsbereiche: Du kannst Betragsoperatoren kombinieren, beispielsweise { "gte": 1000000, "lte": 5000000 } für einen geschlossenen Bereich. tokenTransfer lässt sich mit den anderen Filtern der obersten Ebene kombinieren (slot, blockTime, status und tokenAccounts). Das Endergebnis ist die Schnittmenge.

Beispiele

Zeitbasierte Analysen

Erstelle monatliche Transaktionsberichte:
Verarbeitung für Analysen:

Erstellung einer Mint für Token

Finde die Transaktion, mit der die Mint für einen bestimmten Token erstellt wurde:
Frage für die Erstellung eines Liquiditätspools die Pool-Adresse ab:
So findest du den exakten Zeitpunkt, zu dem eine Mint für Token oder ein Liquiditätspool erstellt wurde, einschließlich der Erstelleradresse und der anfänglichen Parameter.

Finanzierungstransaktionen

Finde heraus, wer eine bestimmte Adresse finanziert hat:
Analysiere anschließend die Transaktionsdaten, um SOL-Übertragungen zu finden:
Die ersten Transaktionen zeigen häufig die Finanzierungsquelle. Sie können dir helfen, zugehörige Adressen oder Finanzierungsmuster zu erkennen.

Übertragungen von Token

Filtere nach tokenTransfer, um bestimmte Bewegungen von Token zu isolieren. USDC-Zuflüsse an eine Adresse:
Große ausgehende Übertragungen an eine bestimmte Gegenpartei:
Kombiniert mit slot-Bereich und Status:

Paginierung

Wenn du mehr Transaktionen als dein Limit hast, verwende paginationToken aus der response, um die nächste Seite abzurufen. Der token ist ein einfacher String im Format "slot:position". Er teilt der API mit, an welcher Stelle sie fortfahren soll. Verwende den Paginierungs-token aus jeder response, um die nächste Seite abzurufen:

Mehrere Adressen

Du kannst nicht mehrere Adressen in einem einzigen request abfragen. Jede Adressabfrage zählt als separater API-request und wird entsprechend abgerechnet. Um Transaktionen für mehrere Adressen abzurufen, frage jede Adresse innerhalb desselben Zeit- oder slot-Fensters ab. Führe die Ergebnisse dann zusammen und sortiere sie:
Unterteile umfangreichere Verlaufsscans in Zeit- oder slot-Fenster, beispielsweise jeweils 1000 slots, und wiederhole dieses Muster.

Best Practices

Performance. Verwende transactionDetails: "signatures", wenn du keine vollständigen Transaktionsdaten brauchst. Verwende sinnvolle Seitengrößen, um bessere response-Zeiten zu erreichen. Filtere nach Zeiträumen oder bestimmten slots, um Abfragen gezielter auszuführen. Filterung. Beginne mit breiten Filtern und grenze sie schrittweise ein. Verwende zeitbasierte Filter für Analyse- und Berichtsabläufe. Kombiniere mehrere Filter für präzise Abfragen, die auf bestimmte Transaktionstypen oder Zeiträume zielen. Paginierung. Speichere Paginierungs-token, wenn du umfangreiche Abfragen später fortsetzen möchtest. Überwache die Paginierungstiefe für deine Performance-Planung. Verwende eine aufsteigende Reihenfolge, wenn du historische Ereignisse chronologisch wiedergeben möchtest. Fehlerbehandlung. Behandle rate limits mit exponentiellem Backoff. Validiere Adressen, bevor du requests sendest. Speichere Ergebnisse bei Bedarf im Cache, um die API-Nutzung zu reduzieren.

Einschränkungen und Sonderfälle

Eine kleine Gruppe von Adressen wird an das Legacy-Archiv weitergeleitet, ist auf einen slot-basierten Scan als Fallback beschränkt oder gibt leere Ergebnisse zurück. Das Ermitteln von Konten für Token vor slot 111.491.819 erfordert ebenfalls eine Behelfslösung. Klappe die folgenden Abschnitte auf, um alle Details anzuzeigen.
An das alte Archiv weitergeleitet. Requests für diese Adressen werden an unser altes Archivsystem weitergeleitet.slot-basierter Scan als Fallback. Requests für diese Adressen werden an unser neues Archivsystem weitergeleitet. Du kannst sie mit einem Scan von slot zu slot abfragen (maximal 100 slots). Diese Daten sind jedoch nicht indiziert.Gibt ein leeres Ergebnis zurück (is_reserved_address). Requests werden an unser neues Archivsystem weitergeleitet. Die Daten sind jedoch nicht indiziert, sodass Abfragen ein leeres Ergebnis zurückgeben.
Bei Adressen mit Aktivitäten in Konten für Token vor slot 111.491.819 kann der Filter tokenAccounts den Eigentümer nicht bestimmen. Das Feld owner war damals in den Metadaten zum Saldo von Token noch nicht vorhanden. Für vollständige Ergebnisse kannst du diese Konten für Token manuell ermitteln, indem du die Anweisungen früher Transaktionen parst. Frage anschließend getTransactionsForAddress parallel für jedes Konto ab.

Wie unterscheidet sich diese Methode von getSignaturesForAddress?

Wenn du die Standardmethode getSignaturesForAddress kennst: getTransactionsForAddress fasst mehrstufige Abläufe in einem einzigen Aufruf zusammen und ergänzt Filterung, Sortierung sowie Unterstützung für Konten für Token. Eine schrittweise Umstellung vorhandenen Codes findest du im Migrationsleitfaden.

Vollständige Transaktionen mit einem Aufruf abrufen

Mit getSignaturesForAddress brauchst du zwei Schritte:
Mit getTransactionsForAddress genügt ein Aufruf:

Verlauf von Token mit einem Aufruf abrufen

Mit getSignaturesForAddress musst du zuerst getTokenAccountsByOwner aufrufen und anschließend jedes Konto für Token abfragen:
Mit getTransactionsForAddress musst du nur filters.tokenAccounts festlegen:

Zusätzliche Funktionen

Chronological sorting

Sortiere Transaktionen mit sortOrder: 'asc' von der ältesten zur neuesten.

Time-based filtering

Filtere mit blockTime-Filtern nach Zeiträumen.

Status filtering

Rufe mit dem Filter status nur erfolgreiche oder fehlgeschlagene Transaktionen ab.

Simpler pagination

Verwende paginationToken statt der verwirrenden Signaturen before/until.

Nächste Schritte

Indexing guide

Verwende getTransactionsForAddress für backfill und Synchronisierung eines Solana-Index.

getTransfersByAddress

Geparster Verlauf ausschließlich für Übertragungen, Zahlungen und den Abgleich.

API reference

Vollständiges request- und response-Schema für getTransactionsForAddress.

Historical data overview

Vergleiche alle Methoden für historische Solana-Daten.