Zum Hauptinhalt springen
POST
Request-Body, response-Schema und Beispiele auf dieser Seite werden aus der OpenAPI-Definition generiert. Scan durchsucht den Verlauf einer Adresse, behält die Transaktionen, die deinen Kriterien in match entsprechen, und parst nur diese. Verwende Scan, statt den geparsten Transaktionsverlauf seitenweise abzurufen und clientseitig zu filtern. Standardmäßig verwendet jedes Element in data dieselbe TransactionResult-Struktur, die Transaktionen parsen zurückgibt. Setze returnShape, um nur die übereinstimmenden Signaturen oder nur eine Anzahl zu erhalten. Die response enthält außerdem eine scan-Zusammenfassung. Sie zeigt dir, wie weit der Scan gekommen ist und warum er beendet wurde.

So funktioniert Scan

  1. Scan ruft den Verlauf der Adresse in Seiten mit bis zu 1.000 Transaktionen ab. Dabei gelten sortOrder sowie die von dir festgelegten Grenzen für slot, time und Signaturen.
  2. Scan behält die Transaktionen, die allen in match festgelegten Kriterien entsprechen.
  3. Scan stoppt beim ersten dieser Ereignisse: limit Treffer gefunden (nur bei der standardmäßigen transactions-Struktur), budget.maxScannedTransactions gescannt, Ende des Verlaufs oder Zeitfensters erreicht oder Zeitlimit des request erreicht.
Ein vorzeitig beendeter Scan ist dennoch ein 200. Rufe ihn erneut mit dem zurückgegebenen paginationToken auf, solange eines vorhanden ist. Das gilt auch, wenn data leer ist.

Trefferkriterien

match ist erforderlich. Lege programs, mints oder beides fest. Wenn du beides festlegst, muss eine Transaktion beiden Kriterien entsprechen.

Nach Programm abgleichen

programs listet bis zu 20 Programme auf, jedes höchstens einmal. Eine Transaktion stimmt überein, wenn sie eine Anweisung eines dieser Programme enthält, entweder auf oberster Ebene oder intern (CPI), und diese im scope des Programms liegt. Du kannst den Treffer für jedes Programm eingrenzen:
  • instructions: Anweisungsnamen aus einer beliebigen IDL-Version des Programms, wie sie in der IDL geschrieben sind oder in snake_case. Wenn ein Name in den IDLs des Programms nicht gefunden wird, wird 400 zurückgegeben.
  • discriminators: Präfixe der Anweisungsdaten mit jeweils 1 bis 8 hexadezimal codierten Bytes und einem optionalen 0x-Präfix. Verwende sie für Programme ohne IDL.
  • Lege eine oder beide Listen fest. Bei beiden stimmt eine Anweisung überein, wenn sie eine der benannten Anweisungen ist oder ihre Daten mit einem der Diskriminatoren beginnen. Lasse beide weg, um jede Anweisung des Programms abzugleichen.
  • Jede Liste akzeptiert höchstens 50 Einträge pro Programm.
Verwende die Methode describeProgram von Parsed Streams, um die Namen der decodierten Anweisungen eines Programms zu prüfen.

Nach Mint abgleichen

mints listet bis zu 20 Objekte der Form { "mint": "...", "scope": "address" } auf, jede Mint höchstens einmal. Eine Transaktion stimmt überein, wenn einer ihrer Token-Salden vor oder nach der Transaktion zu einer dieser Mints gehört und im scope der Mint liegt. Wenn du eine Wallet nach einer Mint durchsuchst, setze tokenAccounts auf balanceChanged. Standardmäßig lässt der Verlauf Transaktionen aus, die nur die Token-Konten der Wallet und nicht die Wallet selbst betreffen. Dazu gehören viele eingehende Token-Übertragungen.

Nativen SOL abgleichen

Nativer SOL hat keine Token-Salden. Deshalb gleicht Scan ihn anhand von Lamports ab. Verwende die native SOL-Mint So11111111111111111111111111111111111111111 (Wrapped SOL ist So11111111111111111111111111111111111111112):
  • Beim address-Bereich stimmt eine Transaktion überein, wenn sich die Lamports der gescannten Adresse geändert haben.
  • Beim transaction-Bereich stimmt sie überein, wenn sich die Lamports eines beliebigen Kontos geändert haben.
Die dem Gebührenzahler berechnete Gebühr zählt nicht. Jedes Konto wird einzeln verglichen. Lamports, die ein Konto verlassen und in derselben Transaktion zurückkehren, zählen daher nicht. Der Abgleich von nativem SOL erfasst SOL, den ein Programm ohne Übertragungsanweisung auszahlt, etwa bei einem Verkauf auf Pump.fun. Er erfasst auch beiläufige Bewegungen wie Jito-Trinkgelder und Mieten, die für Konten gezahlt oder von ihnen erstattet werden.

Abgleichbereich

Jedes Programm und jede Mint verwendet einen scope: Verwende den transaction-Bereich, wenn die gescannte Adresse in der Transaktion vorkommt, aber nicht in der Anweisung oder dem Saldo, die du abgleichst. Die Adresse bezahlt beispielsweise nur die Gebühr, führt eine Multisig-Transaktion aus oder fehlt in einem Anchor-Event-CPI. Wenn du die Mint eines Tokens nach Transaktionen durchsuchst, die auch USDC enthalten, benötigt der USDC-Eintrag den transaction-Bereich. Der Besitz eines Token-Kontos ergibt sich aus owner, das für jeden Token-Saldo gespeichert ist. Ältere Transaktionen ohne diese Angabe stimmen im address-Bereich nur mit address selbst überein.

Rückgabeformate

returnShape legt fest, was die response für die Treffer enthält: signatures und count ignorieren limit und rawTransaction. Sie geben jeden Treffer in dem Bereich zurück, den ein request scannt. Daher stoppen sie nur bei windowEnd, budget oder deadline. Um einen gesamten Verlauf zu zählen, rufe Scan weiter mit paginationToken auf und addiere scan.matchedTransactions. Jedes Element in data mit returnShape: "signatures" sieht so aus:
Alle drei Formate kosten gleich viel, da die Credits von den gescannten Verlaufsseiten und nicht von den zurückgegebenen Daten abhängen.

Beispiel-Requests

Käufe und Verkäufe auf Pump.fun

Durchsuche den Verlauf des Pump.fun-Programms nach den Anweisungen buy und sell:
Pump.fun hat auch Varianten wie buy_exact_sol_in, buy_v2 und sell_v2. Liste alle Anweisungsnamen auf, die du abgleichen möchtest.

Käufe und Verkäufe eines Tokens

Um die Pump.fun-Handelstransaktionen eines Tokens abzurufen, durchsuche statt der Programmadresse die Mint-Adresse des Tokens. Der Verlauf der Mint enthält nur die Aktivität dieses Tokens. Jede Kauf- oder Verkaufsanweisung listet die Mint als Konto auf und stimmt daher mit dem standardmäßigen address-Bereich überein:
Um nur die Transaktionen des Tokens zu behalten, die auch ein USDC-Token-Konto betreffen, füge USDC mit dem transaction-Bereich hinzu. Beim standardmäßigen address-Bereich müsste ein USDC-Saldo zur Mint-Adresse gehören. Daher würde nichts übereinstimmen:

Handelstransaktionen einer Wallet über zwei Programme

Liste mehrere Programme auf, um einen Aufruf eines beliebigen dieser Programme abzugleichen. Dieser request gibt die Pump.fun- und PumpSwap-Handelstransaktionen einer Wallet nur als Signaturen zurück:

USDC-Aktivität einer Wallet in einem Zeitraum

Durchsuche den Verlauf einer Wallet nach Transaktionen, die 2025 USDC betrafen. tokenAccounts: "balanceChanged" schließt Übertragungen ein, die nur das USDC-Token-Konto der Wallet betrafen:
Füge "returnShape": "count" hinzu, um nur die Anzahl der übereinstimmenden Transaktionen zu erhalten.

SOL-Bewegungen einer Wallet

Durchsuche eine Wallet nach Transaktionen, die 2025 ihren SOL-Saldo über die bezahlte Gebühr hinaus geändert haben. Dazu gehört SOL, den ein Programm ohne Übertragungsanweisung ausgezahlt hat:

Paginierung und Stoppgründe

scan.stoppedOn zeigt dir, warum der request beendet wurde: scan.scannedThrough enthält den slot und die Blockzeit der zuletzt gescannten Transaktion. So kannst du den Fortschritt bei langen Verläufen melden. Ein Scan nach einer seltenen Anweisung kann sein Budget aufbrauchen, ohne einen Treffer zu finden. Die response enthält dann ein leeres data-Array und gibt trotzdem ein paginationToken zurück. Scanne daher weiter:
Diese Schleife scannt weiter, bis der Verlauf vollständig durchsucht ist:
scan-pumpfun-trades.js
Scanne die spezifischste mögliche Adresse. Jede Transaktion im Verlauf der Adresse zählt zum Budget. Je weniger irrelevante Transaktionen eine Adresse enthält, desto mehr Treffer findet jeder request.

Credits

Jeder Scan kostet 10 Credits plus 1 Credit pro gescannter Verlaufsseite. Eine Seite enthält bis zu 1.000 Transaktionen. Ein Scan mit dem Standardbudget von 10.000 Transaktionen kostet daher höchstens 20 Credits. Eine wegen der Frist abgebrochene Seite wird weder gescannt noch berechnet. Jede response gibt die Kosten in scan.creditsCharged an. Unter Credits findest du die Preise der Tarife.

Fehler

Fehler auf request-Ebene geben einen JSON-Body mit einer error-Meldung zurück, etwa {"error": "limit must be between 1 and 100"}. Ein Body mit einem unbekannten Feld wie includeRawTransaction (verwende rawTransaction) oder mit mints als einfache Strings statt { "mint": "..." }-Objekten gibt {"error": "invalid request payload"} zurück.

Request-Parameter

string
erforderlich
Adresse, deren Verlauf gescannt wird.
object
erforderlich
Kriterien, denen eine Transaktion entsprechen muss. Lege programs, mints oder beides fest. Wenn du beides festlegst, muss eine Transaktion beiden Kriterien entsprechen.
array
Abzugleichende Programme, höchstens 20 und jedes höchstens einmal. Eine Transaktion stimmt überein, wenn sie eine Anweisung eines dieser Programme enthält, entweder auf oberster Ebene oder intern (CPI), und diese im scope des Programms liegt.
string
erforderlich
Programmadresse.
array
Anweisungsnamen aus einer beliebigen IDL-Version des Programms, wie sie in der IDL geschrieben sind oder in snake_case. Höchstens 50. Kann mit discriminators kombiniert werden.
array
Präfixe der Anweisungsdaten mit jeweils 1 bis 8 hexadezimal codierten Bytes und einem optionalen 0x-Präfix. Höchstens 50. Kann mit instructions kombiniert werden.
string
Standard:"address"
Legt fest, welche Anweisungen des Programms zählen. address zählt nur Anweisungen mit einem Konto, das address ist, einem Token-Konto, das address gehört, oder einem Token-Konto, dessen Mint address ist. Wenn address das Programm ist, zählt jede Anweisung. transaction zählt jede Anweisung des Programms in der Transaktion.
  • address
  • transaction
array
Abzugleichende Mints, höchstens 20 und jede höchstens einmal. Eine Transaktion stimmt überein, wenn einer ihrer Token-Salden vor oder nach der Transaktion zu einer dieser Mints gehört und im scope der Mint liegt.
string
erforderlich
Token-Mint-Adresse. Die native SOL-Mint So11111111111111111111111111111111111111111 gleicht statt Token-Salden Änderungen an Lamports ab. Die Gebühr zählt nicht.
string
Standard:"address"
Legt fest, welche Token-Salden der Mint zählen. address zählt nur Salden, deren Token-Konto address ist oder dieser Adresse gehört, oder deren Mint address ist. Bei nativem SOL zählen nur Änderungen an den Lamports von address. transaction zählt jeden Saldo der Mint in der Transaktion. Bei nativem SOL zählt eine Änderung an den Lamports eines beliebigen Kontos.
  • address
  • transaction
string
Standard:"transactions"
Legt fest, was die response für die Treffer enthält: transactions (geparste Treffer in data, bis zu limit), signatures (signature, slot, transactionIndex und blockTime pro Treffer in data) oder count (kein data; scan.matchedTransactions ist die Anzahl der Treffer). signatures und count ignorieren limit und rawTransaction.
  • transactions
  • signatures
  • count
number
Standard:"100"
Maximale Anzahl der Treffer, die mit der transactions-Struktur zurückgegeben werden. Zulässig sind 1 bis 100.
object
Begrenzt, wie viel Verlauf ein request scannt.
number
Standard:"10000"
Maximale Anzahl der Transaktionen, die in diesem request gescannt werden. Zulässig sind 1 bis 10.000.
string
Scannt Transaktionen vor dieser Signatur.
string
Scannt Transaktionen nach dieser Signatur.
string
Cursor, den ein vorheriger Scan zurückgegeben hat. Die Struktur ist slot:transactionIndex.
string
Standard:"desc"
Reihenfolge, in der der Verlauf gescannt und Treffer zurückgegeben werden.
  • asc
  • desc
string
Standard:"confirmed"
Commitment-Stufe für den Abruf des Verlaufs. processed wird nicht unterstützt.
  • confirmed
  • finalized
string
Standard:"succeeded"
Einzuschließendes Ausführungsergebnis. Die Filterung erfolgt vor dem Abgleich. Ausgeschlossene Transaktionen zählen daher nicht zum Budget.
  • succeeded
  • failed
  • any
string
Standard:"none"
Legt fest, ob Transaktionen eingeschlossen werden, die nur auf ein Token-Konto verweisen, das address gehört, aber nicht auf address selbst: none lässt sie aus, balanceChanged schließt diejenigen ein, die den Saldo des Token-Kontos ändern, und all schließt alle ein. Verwende balanceChanged, wenn du eine Wallet nach einer Mint durchsuchst.
  • none
  • balanceChanged
  • all
number
Minimaler slot, bei dem der request ausgewertet werden kann.
string
Standard:"none"
Codierung der ursprünglichen Solana-Transaktion, die bei jedem erfolgreichen Ergebnis als rawTransaction in der getTransaction-Struktur zurückgegeben wird. Gilt nur für die transactions-Struktur.
  • none
  • json
  • jsonParsed
  • base64
object
Vergleichsgrenzen für den slot. Jede Grenze ist optional.
number
Gleicht Werte ab, die größer als dieser Wert sind.
number
Gleicht Werte ab, die größer oder gleich diesem Wert sind.
number
Gleicht Werte ab, die kleiner als dieser Wert sind.
number
Gleicht Werte ab, die kleiner oder gleich diesem Wert sind.
object
Vergleichsgrenzen für die Blockzeit in Unix-Sekunden. Jede Grenze ist optional.
number
Gleicht Werte ab, die größer als dieser Wert sind.
number
Gleicht Werte ab, die größer oder gleich diesem Wert sind.
number
Gleicht Werte ab, die kleiner als dieser Wert sind.
number
Gleicht Werte ab, die kleiner oder gleich diesem Wert sind.

Autorisierungen

api-key
string
query
erforderlich

Body

application/json

Request-Body zum Durchsuchen des Verlaufs einer Adresse nach passenden Transaktionen.

address
string
erforderlich

Adresse, deren Verlauf durchsucht wird.

match
object
erforderlich

Kriterien, die eine Transaktion erfüllen muss. Lege programs, mints oder beides fest. Wenn du beides festlegst, muss eine Transaktion beide Kriterien erfüllen.

returnShape
enum<string>
Standard:transactions

Legt fest, was die response für die Treffer enthält: transactions (geparste Treffer in data, bis zu limit), signatures (signature, slot, transactionIndex und blockTime für jeden Treffer in data) oder count (kein data; scan.matchedTransactions ist die Anzahl der Treffer). signatures und count ignorieren limit und rawTransaction.

Verfügbare Optionen:
transactions,
signatures,
count
limit
integer
Standard:100

Maximale Anzahl der Treffer, die im transactions-Format zurückgegeben werden, von 1 bis 100.

Erforderlicher Bereich: 1 <= x <= 100
budget
object

Begrenzt, wie viel Verlauf ein einzelner request durchsucht.

beforeSignature
string

Durchsuche Transaktionen vor dieser Signatur.

afterSignature
string

Durchsuche Transaktionen nach dieser Signatur.

paginationToken
string

Cursor, den ein vorheriger Scan zurückgegeben hat. Das Format ist slot:transactionIndex.

sortOrder
enum<string>
Standard:desc

Reihenfolge, in der der Verlauf durchsucht und Treffer zurückgegeben werden.

Verfügbare Optionen:
asc,
desc
commitment
enum<string>
Standard:confirmed

Commitment-Stufe zum Abrufen des Verlaufs. processed wird nicht unterstützt.

Verfügbare Optionen:
confirmed,
finalized
status
enum<string>
Standard:succeeded

Einzubeziehendes Ausführungsergebnis. Die Filterung erfolgt vor dem Abgleich. Ausgeschlossene Transaktionen werden daher nicht auf das Budget angerechnet.

Verfügbare Optionen:
succeeded,
failed,
any
tokenAccounts
enum<string>
Standard:none

Legt fest, ob Transaktionen einbezogen werden, die nur ein Token-Konto referenzieren, das address gehört, aber nicht address selbst: none schließt sie aus, balanceChanged schließt diejenigen ein, die den Saldo des Token-Kontos ändern, und all schließt alle ein. Verwende balanceChanged, wenn du eine Wallet nach Mint durchsuchst.

Verfügbare Optionen:
none,
balanceChanged,
all
minContextSlot
integer

Minimaler slot, bei dem der request ausgewertet werden kann.

rawTransaction
enum<string>
Standard:none

Codierung der ursprünglichen Solana-Transaktion, die bei jedem erfolgreichen Ergebnis als rawTransaction im getTransaction-Format zurückgegeben wird. Gilt nur für das transactions-Format.

Verfügbare Optionen:
none,
json,
jsonParsed,
base64
slot
object

Vergleichsgrenzen für den slot. Jede Grenze ist optional.

time
object

Vergleichsgrenzen für die Blockzeit in Unix-Sekunden. Jede Grenze ist optional.

Antwort

Die Treffer im angeforderten returnShape und eine Zusammenfassung des Scans. Auch ein Teilergebnis erhält den Status 200. Fahre mit paginationToken fort, solange einer zurückgegeben wird.

Die Treffer im angeforderten returnShape und eine Zusammenfassung des Scans.

data
object

Parser-Ergebnis pro Signatur.

paginationToken
string

Cursor, an dem der nächste Scan fortgesetzt wird. Fehlt, wenn der Scan das Ende des Verlaufs oder Zeitfensters erreicht hat.

scan
object

Gibt an, wie weit der Scan gekommen ist und warum er beendet wurde.