Skip to main content

Übersicht

getTransfersByAddress ist eine Helius-exklusive RPC-Methode, die geparste, menschenlesbare Token- und native SOL-Transferobjekte für eine Wallet-Adresse zurückgibt. Es ist nicht Teil der standardmäßigen Solana RPC. Es konzentriert sich auf Transferaktivitäten und gibt daher prägnante Transferdatensätze statt vollständiger Transaktionspayloads zurück. Jeder Datensatz wird normalisiert mit geparsten Besitzer- und Tokenkonten, Mints, Rohbeträgen, Dezimalzahlen, UI-Beträgen, Instruktionspositionen und Bestätigungsstatus, sodass Sie Bewegungen im Saldo ohne erneute Implementierung der Solana-Token-Parsierung nachvollziehen können. Diese Methode erfordert einen Developer-Plan oder höher und kostet 10 Credits pro Anfrage.

Geparste Transferobjekte

Gibt menschenlesbare Transferdatensätze mit geparsten Konten, Beträgen, Dezimalzahlen und Transferarten zurück.

Bereit zur Abstimmung

Modellieren Sie SOL, WSOL, Token-2022-Gebühren, Mints, Burns und Kontoinhaberwechsel, damit Salden genau abgestimmt werden können.

Mint-, Zeit- und Betragsfilter

Engen Sie die Transferhistorie nach Mint-Adresse, Blockzeitrange oder Rohebetragsbereich ein.

Gegenparteifilter

Filtern Sie Transfers nach Absender oder Empfänger mit with und direction.

Wann zu verwenden

Verwenden Sie getTransfersByAddress, wenn Sie benötigen:
  • Wallet-Transferhistorie für Zahlungen oder Transferüberwachung
  • Portfolioaktivität und Tokenbewegungsanalysen
  • Vertrauenswürdige Saldoabstimmung für Bücher und Buchhaltung
  • Gegenparteispezifische Transferberichte (wer hat was gesendet oder empfangen)
  • Normalisierte SOL/WSOL-, Token-2022-Gebühren-, Mint- und Burn-Behandlung ohne einen Parser zu schreiben
Verwenden Sie getTransactionsForAddress stattdessen, wenn Sie vollständige Transaktionsdaten, nur Signaturhistorie oder nicht-Transferaktivitäten benötigen. Ein allgemeines Muster ist, hier durch Transfers zu blättern und dann die zugrundeliegenden vollständigen Transaktionen mit gebündelten getTransaction Aufrufen abzurufen (siehe Vollständige Transaktionen für Transferreihen abrufen).

Genauigkeit und Abstimmung

getTransfersByAddress ist für Anwendungen entwickelt, die eine vertrauenswürdige Transferhistorie für Bücher, Zahlungsnachverfolgung, Portfolioaktivität und Saldoabstimmung benötigen. Anstatt rohe Transaktionspayloads zurückzugeben und jeden Sonderfall Ihrem Parser zu überlassen, gibt die API normalisierte Transferobjekte zurück. Die Antwort bildet explizit die Transferfälle ab, die die Solana-Historie häufig schwer nachvollziehbar machen:
  • Standard-SPL-Token und native SOL-Transfers.
  • Token-2022-Transfers mit einbehaltenen Gebühren, dargestellt als gewöhnliche transfer Zeilen mit separaten Gebührenfeldern.
  • Mints und Burns, dargestellt als Transfers mit einem null Absender oder Empfänger.
  • SOL-Einpack- und Auspackverhalten, mit einem Standardmodus, der darauf ausgelegt ist, geräuschvolle Lebenszyklusreihen zu vermeiden.
  • Tokenkontoinhaberwechsel über SetAuthority.
  • Token-2022 einbehaltene Gebührenabhebungen.
  • Zwischenkontoflüsse, die als zugrunde liegende Transferdatensätze zurückgegeben werden, anstatt als geschätzte Nettobewegung zusammengefasst zu werden.
Für unterstützte sichtbare Transferereignisse können Sie so Bewegungen im Saldo nachvollziehen, ohne die Solana-Token-Pasrlogik neu implementieren zu müssen. Bekannte Ausschlüsse, wie versteckte SOL-Bewegungen, die nur aus Saldoänderungen abgeleitet werden können, werden unter Einschränkungen erwähnt.

Schnellstart

Anfrageparameter

Übergeben Sie die Wallet-Inhaberadresse, nicht ein zugehöriges Tokenkonto (ATA). Die API sucht nach Transferaktivitäten für Tokenkonten, die von dieser Wallet-Inhaberin gehalten werden.
string
erforderlich
Base58-kodierte Besitzer-Wallet-Adresse zur Abfrage von Transfers. Übergeben Sie die Wallet-Inhaberadresse, nicht ein zugehöriges Tokenkonto (ATA).
object
Optionales Konfigurationsobjekt für Filterung, Paginierung, Engagement, Sortierung und SOL/WSOL-Verhalten.
string
Nach Gegenpartei-Adresse filtern. Gibt nur Transfers zu oder von dieser Adresse zurück.
string
Standard:"any"
Filtern Sie nach Transferrichtung relativ zu address.
  • in: Transfers, die von address empfangen wurden
  • out: Transfers, die von address gesendet wurden
  • any: Eingehende und ausgehende Transfers
string
Nach Token-Mint-Adresse filtern. Verwenden Sie So11111111111111111111111111111111111111111 für native SOL und So11111111111111111111111111111111111111112 für WSOL.
string
Standard:"merged"
Steuert, wie native SOL und WSOL dargestellt werden.
  • merged: WSOL wird als native SOL behandelt. Ein- und Auspack-Lebenszyklusreihen werden ausgeschlossen, und WSOL-Mint-Werte werden in den nativen SOL-Mint umgeschrieben.
  • separate: WSOL wird als eigener Mint beibehalten, und Ein- und Auspack-Lebenszyklusreihen sind enthalten.
object
Zusätzliche Filter für Betrag, Blockzeit und Slot.
number
Standard:"100"
Maximale Anzahl der zurückzugebenden Transfers. Bereich: 1 bis 100.
string
Cursor aus der vorherigen Antwort für Paginierung.
string
Standard:"finalized"
Daten-Commitment-Level.
  • finalized
  • confirmed
number
Der minimale Slot, bei dem die Anfrage ausgewertet werden kann
string
Standard:"desc"
Ergebnisreihenfolge.
  • desc: neueste zuerst
  • asc: älteste zuerst

Antwort

Antwortfeld Details

  • fromUserAccount und toUserAccount sind immer vorhanden. Wenn eine Seite nicht existiert, ist der Wert null.
  • fromTokenAccount und toTokenAccount sind nur enthalten, wenn Token-Kontopunkte für die Zeile von Bedeutung sind. Sie werden vollständig für native SOL-Transfers weggelassen.
  • Mint-Transfers sind einseitig: fromUserAccount ist null, und sie können nur als eingehende Transfers für den Empfänger zurückgegeben werden.
  • Burn-Transfers sind einseitig: toUserAccount ist null, und sie können nur als ausgehende Transfers für den brennenden Besitzer zurückgegeben werden.

Filter

Verwenden Sie Vergleichsfilter für numerische Bereichsabfragen. Alle Vergleichsfelder sind optional und können kombiniert werden.

Transferarten

Das Feld type identifiziert das durch jede Reihe dargestellte Transferverhalten.

Transferarten und Anweisungen

SOL und wSOL Verhalten

SOL existiert auf Solana in zwei Formen, die häufig zusammen in realen Benutzeraktivitäten auftreten:
  • Native SOL ist das native Asset der Chain. Es existiert direkt in einer Wallet oder einem Konto als Lamports. Ein SOL sind 1.000.000.000 Lamports.
  • Wrapped SOL (WSOL, oft als wSOL geschrieben) ist eine SPL-Token-Darstellung von SOL. Es verwendet den WSOL-Mint So11111111111111111111111111111111111111112 und lebt in einem Tokenkonto, wie USDC oder jeder andere SPL-Token.
Benutzer und Anwendungen wickeln SOL ein, wenn sie SOL benötigen, um sich wie ein SPL-Token zu verhalten, normalerweise für DeFi, Swaps, tokenkontenbasierte Buchhaltung oder Programmschnittstellen, die nur SPL-Tokens akzeptieren. Das Einwickeln finanziert typischerweise ein Tokenkonto mit nativem SOL und synchronisiert es in WSOL. Das Auswickeln schließt das WSOL-Tokenkonto und gibt das SOL an ein Lamport-Ziel zurück. Dieser Lebenszyklus kann eine verwirrende Historie schaffen, wenn Sie versuchen, eine einfache Frage zu beantworten wie “Wie viel SOL wurde zwischen dieser Wallet und jemand anderem bewegt?”. Ein Ein- oder Auswickeln bewegt oft SOL zwischen von demselben Besitzer kontrollierten Konten. Wenn diese Lebenszyklusreihen standardmäßig als gewöhnliche Transfers gezeigt werden, können Anwendungen die Aktivität doppelt zählen oder interne Buchungen als externe Zahlungen anzeigen. Standardmäßig verwendet getTransfersByAddress solMode: "merged". In diesem Modus:
  • Native SOL und WSOL werden als ein SOL-Asset betrachtet, wenn nach So11111111111111111111111111111111111111111 abgefragt wird.
  • WSOL-Transferreihen werden auf den nativen SOL-Mint normalisiert, sodass SOL-nominierte Historie einfacher abzustimmen ist.
  • Ein- und Auspack-Lebenszyklusreihen sind ausgeschlossen, da sie normalerweise Bewegungen zwischen von demselben Besitzer kontrollierten Konten darstellen, nicht eine Zahlung an einen anderen Benutzer.
  • SOL- und WSOL-Transfers zwischen verschiedenen Besitzern werden dennoch als Transfers dargestellt.
  • Miete, die von CloseAccount zurückgewonnen wurde, wird als native SOL-unwrap-Reihe dargestellt, wenn Schließungskonto-Lebenszyklusreihen zurückgegeben werden.
Verwenden Sie solMode: "separate", wenn Sie WSOL als eigenständigen SPL-Token-Mint benötigen oder Ein- und Auspack-Lebenszyklusdatensätze inspizieren möchten. In diesem Modus behält WSOL den Mint So11111111111111111111111111111111111111112, und Ein-/Auspackdatensätze werden mit type: "wrap" oder type: "unwrap" zurückgegeben. Bei WSOL-Kontenschließungen in solMode: "separate" stellen unwrap-Datensätze für den WSOL-Mint das verbleibende WSOL-Token-Guthaben dar, das als SOL zurückgegeben wird. Miete, die vom geschlossenen Tokenkonto zurückerstattet wird, wird als separate native SOL-unwrap-Reihe zurückgegeben.

Token-2022 Transfergebühren

Token-2022 TransferCheckedWithFee Anweisungen werden als ein Transferdatensatz mit type: "transfer" dargestellt. Der Zielbetrag wird in amount zurückgegeben; einbehaltene Gebührendetails werden in feeAmount und feeUiAmount zurückgegeben. Bei Transfers mit Gebühren wird die Quelle amount + feeAmount belastet, während das Ziel amount gutgeschrieben wird.

Beispiele

Nach USDC filtern

Eingehende Transfers von einem Absender

Betrag und Zeitbereich

Paginierte Anfrage

Vollständige Transaktionen für Transferreihen abrufen

getTransfersByAddress gibt geparste Transferreihen zurück, nicht vollständige Transaktionspayloads. Wenn Sie die vollständige Transaktion für jeden Transfer benötigen, blättern Sie zuerst durch die Transfers, deduplizieren Sie nach signature, und rufen Sie dann die vollständigen Transaktionen mit gebündelten getTransaction-Aufrufen ab. getTransfersByAddress ist nicht verarbeitbar über mehrere Besitzeradressen hinweg. Abfragen Sie eine Besitzeradresse nach der anderen, dann bündeln Sie die resultierenden getTransaction-Anfragen nach Signatur. Eine einzelne Transaktion kann mehrere Transferreihen auslösen, daher deduplizieren Sie immer Signaturen, bevor Sie Transaktionen abrufen.

Einschränkungen

  • Fehlgeschlagene Transaktionen sind in V1 nicht enthalten.
  • Verborgene SOL-Bewegungen, die nur aus Saldoänderungen abgeleitet werden, werden in V1 nicht unterstützt.
  • harvestWithheldTokensToMint wird in V1 nicht unterstützt, da es den gesammelten Betrag nicht angibt.
  • Zwischenkontoflüssen wird nicht reduziert. Wenn eine Transaktion Mittel durch Zwischenkonten bewegt, werden die zugrunde liegenden Transferdatensätze zurückgegeben.
  • Nicht verarbeitbar über mehrere Besitzeradressen hinweg. Abfragen Sie einen Besitzer nach dem anderen.

Nächste Schritte

getTransactionsForAddress

Vollständige Transaktionshistorie mit Filterung, Sortierung und Tokenkonto-Unterstützung.

API-Referenz

Vollständiges Anfragen- und Antwortschema für getTransfersByAddress.

Indexierungsanleitung

Füllen Sie die Transferdaten nach und synchronisieren Sie sie in Ihren eigenen Index.

Überblick über historische Daten

Vergleichen Sie alle Solana-Historische-Daten-Methoden.