Ü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
VerwendegetTransactionsForAddress, 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
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) undlte(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 Transaktionenfailed: Nur fehlgeschlagene Transaktionenany: Erfolgreiche und fehlgeschlagene Transaktionen (Standard)
{ "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
{ "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 Übertragungenout: Von der abgefragten Adresse gesendete Übertragungenany: 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, base58number
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 vontransactionDetails ab. Der Signaturmodus gibt kompakte Signaturdatensätze zurück. Der vollständige Modus gibt vollständige Transaktions- und Metadatenobjekte zurück.
- Signatures Response
- Full Transaction Response
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ürslot, 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 wiegetSignaturesForAddress 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.
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 FiltertokenTransfer 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?
filters der request-Konfiguration:
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:Erstellung einer Mint für Token
Finde die Transaktion, mit der die Mint für einen bestimmten Token erstellt wurde:Finanzierungstransaktionen
Finde heraus, wer eine bestimmte Adresse finanziert hat:Übertragungen von Token
Filtere nachtokenTransfer, um bestimmte Bewegungen von Token zu isolieren.
USDC-Zuflüsse an eine Adresse:
Paginierung
Wenn du mehr Transaktionen als dein Limit hast, verwendepaginationToken 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:Best Practices
Performance. VerwendetransactionDetails: "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.Unsupported and specially-routed addresses
Unsupported and specially-routed addresses
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.Workaround: historical token account discovery (before slot 111,491,819)
Workaround: historical token account discovery (before slot 111,491,819)
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 StandardmethodegetSignaturesForAddress 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
MitgetSignaturesForAddress brauchst du zwei Schritte:
getTransactionsForAddress genügt ein Aufruf:
Verlauf von Token mit einem Aufruf abrufen
MitgetSignaturesForAddress musst du zuerst getTokenAccountsByOwner aufrufen und anschließend jedes Konto für Token abfragen:
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.