Einführung der Parsed Events Scan API

Nach Anweisungen eines Solana-Programms scannen

Die folgende Anfrage scannt den Verlauf des Pump.fun-Programms und gibt geparste Transaktionen zurück, die eine buy- oder sell-Anweisung enthalten:

curl --request POST \
  --url "https://mainnet.helius-rpc.com/v1/parsed-events/scan?api-key=$HELIUS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "address": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
    "match": {
      "programs": [
        {
          "programId": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
          "instructions": ["buy", "sell"]
        }
      ]
    },
    "limit": 100
  }'

Mit dieser Anfrage scannte das Parsed Events Scan-Demotool 261 Datensätze und fand 100 Treffer. Es gab die neuesten 100 Ereignisse in 182 ms zurück. Die Gesamtkosten betrugen nur 11 Credits:

Anweisungsnamen können die Schreibweise aus einer beliebigen bekannten Version der IDL des Programms oder die snake_case-Form verwenden. Die Parsed Events Scan API prüft sowohl Anweisungen auf oberster Ebene als auch innere Anweisungen, die über programmübergreifende Aufrufe (CPI) aufgerufen werden.

Programme haben oft mehrere Versionen einer bestimmten Aktion. Die IDL von Pump.fun enthält beispielsweise die Anweisungen buy, buy_exact_sol_in, buy_v2, buy_exact_quote_in_v2, sell und sell_v2. Mit der Scan API kannst du alle Anweisungsnamen auflisten, nach denen du suchen möchtest.

Käufe und Verkäufe machen einen großen Teil der Aktivität von Pump.fun aus. Daher findet die API Treffer sehr schnell. Scan spart mehr, wenn die gesuchte Aktivität selten ist. Creator Fees machen beispielsweise nur einen kleinen Teil der Transaktionen des Programms aus:

curl --request POST \
  --url "https://mainnet.helius-rpc.com/v1/parsed-events/scan?api-key=$HELIUS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "address": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
    "match": {
      "programs": [
        {
          "programId": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
          "instructions": ["collect_creator_fee"]
        }
      ]
    },
    "limit": 10
  }'

Wenn wir mit dem Parsed Events Scan-Demotool nach den zehn neuesten Claims suchen, sehen wir, dass das Tool für diese Anfrage 3.402 Transaktionen in 182 ms gescannt hat. Die Kosten betrugen 14 Credits:

Der vergleichbare Aufruf mit getTransactionsForAddress würde 350 Credits kosten, also 25-mal so viel wie der Scan-Endpunkt.

Was ist, wenn ein Solana-Programm keine IDL mit benannten Anweisungen hat?

Um die Parsed Events Scan API mit Solana-Programmen ohne IDL zu verwenden, kannst du stattdessen Präfixe der Anweisungsdaten abgleichen.

Jeder Diskriminator kann ein bis acht hexadezimal kodierte Bytes enthalten. Du kannst Namen und Diskriminatoren für ein einzelnes Programm kombinieren. Eine Anweisung stimmt überein, wenn eines der Kriterien erfüllt ist. Beispiel:

{
  "match": {
    "programs": [
      {
        "programId": "<PROGRAM_ADDRESS>",
        "discriminators": ["0x66063d1201daebea"]
      }
    ]
  }
}

Mehrere Solana-Programme gleichzeitig scannen

Du kannst in einer einzelnen Anfrage an die Parsed Events Scan API bis zu 20 Programme auflisten. Eine Transaktion gilt als Treffer, wenn sie eines davon aufruft.

Diese Anfrage scannt beispielsweise die Trades einer Wallet in einem Durchlauf nach Treffern bei Jupiter, DFlow und Pump.fun:

{
  "address": "<WALLET_ADDRESS>",
  "match": {
    "programs": [
      {
        "programId": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4",
        "instructions": ["route", "shared_accounts_route", "route_v2", "shared_accounts_route_v2"]
      },
      { "programId": "DF1ow4tspfHX9JwWJsAb9epbkA8hmpSEAtxXy1V27QBH" },
      {
        "programId": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
        "instructions": ["buy", "buy_exact_sol_in", "buy_v2", "sell", "sell_v2"]
      }
    ]
  }
}

Nach Token-Mint scannen

Die Scan API kann auch Transaktionen finden, die einen bestimmten Token-Mint berührt haben. Dazu prüft sie die Token-Guthaben vor und nach jeder Transaktion auf die Mint-Adresse. Standardmäßig berücksichtigt sie nur Guthaben, die zur gescannten Adresse gehören.

Wenn du eine Wallet nach einem Token scannst, setze tokenAccounts auf balanceChanged. Bei eingehenden Token-Transfers wird in vielen Fällen nur das Token-Konto der Wallet berührt, nicht die Wallet selbst. Daher enthält der Verlauf der Wallet diese Transaktionen standardmäßig nicht.

Diese Anfrage findet beispielsweise Ansems wSOL-Aktivität im September 2026:

curl --request POST \
  --url "https://mainnet.helius-rpc.com/v1/parsed-events/scan?api-key=$HELIUS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "address": "<ANSEM_WALLET_ADDRESS>",
    "match": {
      "mints": [{ "mint": "So11111111111111111111111111111111111111112" }]
    },
    "tokenAccounts": "balanceChanged",
    "time": {
      "gte": 1788220800,
      "lte": 1790812800
    }
  }'

Die Scan API fand nach dem Scannen von insgesamt 7.555 Transaktionen 53 übereinstimmende Transaktionen:

Programme und Mints kombinieren

Entwickler können sowohl programs als auch mints festlegen, um die Ergebnisse einzugrenzen. Bei einer Kombination muss eine Transaktion beide Kriterien erfüllen. Wenn du die Aktivität eines Programms auf einen einzelnen Token eingrenzen möchtest, ist die gescannte Adresse jedoch wichtiger als die Filter.

Scanne beispielsweise die Mint-Adresse eines Tokens statt des Pump.fun-Programms, um jeden Pump.fun-Trade eines bestimmten Tokens zu finden. Bei jedem Kauf oder Verkauf wird der Mint als Konto aufgeführt, sodass er standardmäßig übereinstimmt:

{
  "address": "<MINT_ADDRESS>",
  "match": {
    "programs": [
      {
        "programId": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
        "instructions": ["buy", "buy_exact_sol_in", "buy_v2", "sell", "sell_v2"]
      }
    ]
  }
}

Der Verlauf des Mints enthält nur die Aktivität dieses Tokens. Der Verlauf des Programms enthält dagegen Trades für jeden Token. Ein Scan des Programmverlaufs würde daher Budget für irrelevante Transaktionen verbrauchen.

Umfang des Abgleichs auswählen

Standardmäßig zählen die Anweisungen eines Programms und die Token-Guthaben eines Mints nur, wenn sie die gescannte Adresse betreffen. Ein Token-Guthaben betrifft die Adresse, wenn die Adresse das Token-Konto besitzt oder wenn die Adresse der Mint des Guthabens ist. Eine Anweisung betrifft die Adresse, wenn:

• Eines ihrer Konten die Adresse ist
• Eines ihrer Konten ein Token-Konto ist, das der Adresse gehört
• Die Adresse ein Mint ist und eines der Konten der Anweisung ein Token-Konto für diesen Mint ist
• Die Adresse das aufgerufene Programm ist

Setze "scope": "transaction" für ein Programm oder einen Mint, um es bzw. ihn überall in der Transaktion zu berücksichtigen. Verwende diese Option, wenn die Adresse nur die Gebühr bezahlt, eine Multisig-Transaktion ausführt oder kein Konto der abzugleichenden Anweisung ist.

Diese Anfrage findet beispielsweise Transaktionen eines Tokens, bei denen auch USDC bewegt wurde. Beim standardmäßigen Umfang müssten die USDC-Guthaben zur Mint-Adresse gehören. Deshalb würde es keine Treffer geben:

{
  "address": "<MINT_ADDRESS>",
  "match": {
    "mints": [
      { "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "scope": "transaction" }
    ]
  },
  "returnShape": "signatures"
}

Für Programme gilt derselbe Abgleichsumfang. Diese Anfrage findet die Jupiter-Swaps, für die ein Relayer Gebühren bezahlt hat.

Der Relayer signiert die Transaktionen nur als Gebührenzahler. Er gehört daher nicht zu den Konten der Routing-Anweisung. Beim standardmäßigen Umfang würde keine dieser Transaktionen übereinstimmen:

{
  "address": "<RELAYER_ADDRESS>",
  "match": {
    "programs": [
      {
        "programId": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4",
        "instructions": ["route", "shared_accounts_route", "route_v2", "shared_accounts_route_v2"],
        "scope": "transaction"
      }
    ]
  },
  "returnShape": "signatures"
}

Dieselbe Logik gilt für ein Multisig-Mitglied, das einen Vorschlag ausführt. Die vom Multisig ausgeführte Anweisung wirkt auf die Konten des Vaults, nicht auf die des Mitglieds. Um den Verlauf des Mitglieds danach zu scannen, ist daher der Umfang transaction erforderlich.

Natives SOL verfolgen

Natives SOL hat keine Token-Guthaben. Daher gleicht der Scan es anhand von Lamports ab.

Übergib den Mint von nativem SOL (So11111111111111111111111111111111111111111), der sich von Wrapped SOL unterscheidet. Eine Transaktion stimmt überein, wenn sich das SOL-Guthaben der gescannten Adresse geändert hat. Die von ihr bezahlte Gebühr wird dabei nicht berücksichtigt:

{
  "address": "<WALLET_ADDRESS>",
  "match": {
    "mints": [{ "mint": "So11111111111111111111111111111111111111111" }]
  },
  "time": { "gte": 1788220800, "lt": 1790812800 }
}

Damit werden SOL-Zahlungen eines Programms ohne Transferanweisung erfasst, etwa bei einem Pump.fun-Verkauf. Auch beiläufige Bewegungen wie Jito-Trinkgelder und für Konten gezahlte oder zurückerstattete Miete werden erfasst.

Geparste Transaktionen, Signaturen oder eine Anzahl abrufen

returnShape legt fest, was die Antwort für die Treffer enthält:

Diese Anfrage zählt beispielsweise die Pump.fun-Käufe eines Traders im September 2026, ohne Transaktionen zurückzugeben:

{
  "address": "<WALLET_ADDRESS>",
  "match": {
    "programs": [
      {
        "programId": "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
        "instructions": ["buy", "buy_exact_sol_in", "buy_v2"]
      }
    ]
  },
  "returnShape": "count",
  "time": { "gte": 1788220800, "lt": 1790812800 }
}

Beim Zählen ignorieren signatures und count den Wert limit und erfassen jeden Treffer in dem von einer Anfrage gescannten Bereich. Um einen langen Verlauf zu zählen, rufe weitere Seiten ab und summiere scan.matchedTransactions.

Alle drei Antwortformen kosten gleich viel.

Festlegen, wie viel Verlauf jede Anfrage scannt

Ein Scan kann pro Anfrage bis zu 10.000 Transaktionen prüfen und bis zu 100 Treffer zurückgeben.

Das Feld budget.maxScannedTransactions steuert dieses Limit und hat den Standardwert 10.000. Das Feld limit steuert, wie viele Treffer der Endpunkt zurückgibt. Es akzeptiert Werte von 1 bis 100 und hat den Standardwert 100.

Die beiden Einstellungen sind getrennt, weil Treffer selten sein können. Eine Anfrage kann also Tausende Transaktionen scannen und nur wenige Treffer zurückgeben.

Standardmäßig enthalten Scan-Anfragen nur erfolgreiche Transaktionen.

Setze status auf failed oder any, um fehlgeschlagene Transaktionen einzubeziehen. Fehlgeschlagene Transaktionen enthalten dekodierte Programmfehler, wenn diese in der IDL des Programms definiert sind.

Scan-Zusammenfassungen

Jede Antwort enthält eine scan-Zusammenfassung:

{
  "data": [],
  "paginationToken": "460903064:422",
  "scan": {
    "stoppedOn": "budget",
    "scannedTransactions": 2000,
    "matchedTransactions": 0,
    "scannedThrough": {
      "slot": 460903064,
      "blockTime": 1792856105
    },
    "creditsCharged": 12
  }
}

Die Zusammenfassung zeigt dir:

• Warum der Scan beendet wurde
• Wie viele Transaktionen gescannt wurden
• Wie viele Transaktionen übereinstimmten
• Den letzten gescannten Slot und die letzte gescannte Blockzeit
• Wie viele Credits die Anfrage verbraucht hat

So funktioniert die Scan-Paginierung

Wenn ein Scan beendet wird, gibt das Feld scan.stoppedOn den Grund an:

• windowEnd: Der Scan hat das Ende des Verlaufs oder Zeitfensters erreicht
• limit: Die Antwort enthält die angeforderte Anzahl von Treffern
• budget: Die Anfrage hat ihr Budget für gescannte Transaktionen erreicht
• deadline: Die Anfrage hat ihr Zeitlimit erreicht

Wenn die Antwort ein paginationToken enthält, sende dieses Token in der nächsten Anfrage. Fahre auch dann fort, wenn das aktuelle data-Array leer ist. Ein leeres Ergebnis kann bedeuten, dass die Anfrage ihr Budget aufgebraucht hat, bevor sie einen Treffer fand. Es bedeutet nicht, dass keine späteren Treffer existieren.

Diese Schleife erfasst beispielsweise die Pump.fun-Trades der letzten Stunde.

Beachte, dass die Grenze time und das Anfragelimit verhindern, dass der gesamte Verlauf durchlaufen wird:

const PUMP_PROGRAM = "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P";
const ONE_HOUR_AGO = Math.floor(Date.now() / 1000) - 3600;
const MAX_REQUESTS = 50;

let paginationToken;
let requests = 0;

async function scanHistory() {
  const response = await fetch(
    `https://mainnet.helius-rpc.com/v1/parsed-events/scan?api-key=${process.env.HELIUS_API_KEY}`,
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        address: PUMP_PROGRAM,
        match: {
          programs: [{ programId: PUMP_PROGRAM, instructions: ["buy", "sell"] }],
        },
        time: { gte: ONE_HOUR_AGO },
        limit: 100,
        ...(paginationToken && { paginationToken }),
      }),
    }
  );

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}: ${await response.text()}`);
  }

  return response.json();
}

do {
  const page = await scanHistory();
  requests++;

  for (const transaction of page.data) {
    console.log(transaction.signature);
  }

  paginationToken = page.paginationToken;
} while (paginationToken && requests < MAX_REQUESTS);

Geparste Ergebnisse ohne clientseitige Pipeline

Jedes Element in data verwendet dasselbe TransactionResult-Format wie der Endpunkt Parsed Events Parse Transactions. Ergebnisse können dekodierte Anweisungen, Transfers, Kontoänderungen, Ereignisse, Transaktionszusammenfassungen und, sofern verfügbar, protokollspezifische geparste Daten enthalten. Wenn deine Anwendung auch die ursprünglichen Solana-Transaktionsdaten benötigt, setze rawTransaction auf "json", "jsonParsed" oder "base64".

Der Hauptunterschied liegt darin, wo der Verlaufs-Workflow ausgeführt wird.

Deine Anwendung definiert die Suche einmal. Die Parsed Events Scan API übernimmt die Paginierung des Verlaufs, den Abgleich und das Parsen, bevor sie die relevanten Transaktionen zurückgibt.

Verwende die neuesten Helius SDKs

Sowohl unser TypeScript- als auch unser Rust-SDK unterstützen unsere Parsed Events API und den neuen Scan-Endpunkt.

Das TypeScript-SDK stellt Scans als helius.parsedEvents.scan() bereit. Der Antworttyp richtet sich nach dem übergebenen returnShape:

const { scan } = await helius.parsedEvents.scan({
  address: "<WALLET_ADDRESS>",
  match: {
    programs: [{ programId: "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P", instructions: ["buy", "sell"] }],
  },
  returnShape: "count",
});

console.log(scan.matchedTransactions, scan.stoppedOn);

Das Rust-SDK stellt außerdem scan, scan_signatures und scan_count auf helius.parsed_events() bereit. Alle verwenden denselben ScanRequest.

Preise der Parsed Events Scan API

Jede Anfrage an die Parsed Events Scan API kostet 10 Credits plus 1 Credit für jede gescannte Verlaufsseite. Eine Verlaufsseite enthält bis zu 1.000 Transaktionen.

Eine Anfrage mit dem standardmäßigen Budget von 10.000 Transaktionen kostet beispielsweise höchstens 20 Credits. Die Antwort weist die genauen Kosten in scan.creditsCharged aus.

Zum Vergleich: Ein Scan kostet ein Zehntel der Paginierung desselben Verlaufs mit getTransactionsForAddress. Diese kostet 100 Credits pro Seite mit bis zu 1.000 Transaktionen.

Nutzung kontrollieren

Verwende die engstmögliche sinnvolle Adresse und füge nach Möglichkeit Slot- oder Zeitgrenzen hinzu, um die Nutzung zu kontrollieren. Weniger irrelevante Transaktionen bedeuten mehr nützliche Treffer pro Anfrage.

Die Enhanced Transactions API durch die Parsed Events API ersetzen

Die Enhanced Transactions API bleibt im Wartungsmodus verfügbar, erhält jedoch keine neuen Parsertypen oder Funktionen. Parsed Events ist ihr Nachfolger und nutzt den IDL-Katalog von Helius, um Anweisungen in Tausenden von Solana-Programmen zu dekodieren. Falls du es noch nicht getan hast, migriere zur Parsed Events API.

Was ist der Unterschied?

Die Enhanced Transactions API ordnet Aktivitäten einem festen Satz von Transaktionstypen zu, etwa Swaps, Transfers und NFT-Verkäufen. Die Parsed Events Scan API unterstützt dagegen präzisere Suchen nach Programmanweisung, Rohdaten-Diskriminator, Token-Mint oder einer Kombination dieser Kriterien. Helius wendet diese Filter beim Scannen des Adressverlaufs an und parst nur die übereinstimmenden Transaktionen.

Die Parsed Events API bietet Entwicklern eine breitere Programmabdeckung und mehr Kontrolle über historische Abfragen, ohne dass sie einen clientseitigen Scanner verwalten müssen.

Erste Schritte

Verwende die Parsed Events Scan API, wenn du weißt, welche Onchain-Aktivität du benötigst, aber keinen clientseitigen Verlaufsscanner erstellen und verwalten möchtest. In der API-Referenz zum Scannen des Transaktionsverlaufs findest du das vollständige Anfrageschema, die Antwortfelder, Limits, Fehler und weitere Beispiele.

Wenn du weiter erkunden möchtest, was die Scan API kann, probiere das neue Scan-Tool in deinem Helius-Dashboard aus. Scanne Adressen nach Programmen und Mints sowie mit Filtern.