> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Von getSignaturesForAddress + getTransaction zu getTransactionsForAddress migrieren > Ersetze die getSignaturesForAddress + getTransaction Schleife durch einen einzigen getTransactionsForAddress Aufruf – Parameterzuordnung, Code davor/danach und Paginierung. ## Warum migrieren? Die Standardmethode, um die Transaktionshistorie einer Adresse auf Solana abzurufen, erfolgt in zwei Schritten: Aufruf von `getSignaturesForAddress`, um Signaturen aufzulisten, dann Aufruf von `getTransaction` einmal pro Signatur, um die Details abzurufen. Für 1.000 Transaktionen sind das 1.001 HTTP-Anfragen. [`getTransactionsForAddress`](/docs/de/rpc/gettransactionsforaddress) ist eine Helius-exklusive RPC-Methode, die beide Schritte in einen Aufruf zusammenfasst. Sie liefert bis zu 1.000 vollständige Transaktionen pro Anfrage, mit Filterung, bidirektionaler Sortierung und Token-Account-Unterstützung, die die Standardmethoden nicht bieten. | | `getSignaturesForAddress` + `getTransaction` | `getTransactionsForAddress` | | -------------------------------------------- | -------------------------------------------- | -------------------------------------- | | Anfragen für 1.000 Transaktionen | 1.001 | 1 | | Credits für 1.000 vollständige Transaktionen | \~1.001 (1 Credit pro Aufruf) | 100 (10 Credits pro 100 Transaktionen) | | Verlauf des zugehörigen Token-Accounts (ATA) | Nicht enthalten | Enthalten über `filters.tokenAccounts` | | Zeit- und Slotbereichs-Filter | Nein | Ja | | Statusfilter (erfolgreich/gescheitert) | Nein | Ja | | Sortierreihenfolge | Neueste zuerst | Neueste oder älteste zuerst | | Paginierung | `before`/`until` Signaturen | `paginationToken` | Das Ergebnis: etwa 10x weniger Credits, 1.000x weniger Rundreisen und keine clientseitige Bündelung, Ratenbegrenzungsbehandlung oder Wiederholungslogik für das `getTransaction` Fan-Out. ## Vorher und nachher Hier ist dieselbe Aufgabe — Abrufen der letzten 1.000 Transaktionen für eine Adresse mit vollständigen Details — in beiden Mustern: ```javascript Before (two methods) theme={"system"} const rpcUrl = 'https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY'; // Step 1: Get signatures (1 request) const sigResponse = await fetch(rpcUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getSignaturesForAddress', params: ['YOUR_ADDRESS_HERE', { limit: 1000 }] }) }); const { result: signatures } = await sigResponse.json(); // Step 2: Get transaction details (1,000 additional requests) const transactions = await Promise.all( signatures.map(async (sig) => { const txResponse = await fetch(rpcUrl, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransaction', params: [sig.signature, { maxSupportedTransactionVersion: 1 }] }) }); const { result } = await txResponse.json(); return result; }) ); ``` ```javascript After (one method) theme={"system"} const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransactionsForAddress', params: [ 'YOUR_ADDRESS_HERE', { transactionDetails: 'full', maxSupportedTransactionVersion: 1, limit: 1000 } ] }) }); const { result } = await response.json(); const transactions = result.data; // Full transactions, same shape as getTransaction ``` `getTransactionsForAddress` ist kein Teil des standardmäßigen Solana RPC, daher hat `@solana/web3.js` keinen `Connection` Helfer dafür. Rufe es mit einer rohen JSON-RPC-Anfrage auf, wie oben gezeigt – es funktioniert im selben Helius-Endpunkt wie der Rest deines RPC-Verkehrs. ## Parameterzuordnung Jede Option aus dem alten Zweischritt-Flow hat ein direktes Äquivalent. Die meisten Namen bleiben unverändert – nur die Paginierung funktioniert anders. ### Von getSignaturesForAddress | Alte Option | Neues Äquivalent | | ---------------- | ----------------------------------------------------------------------------------- | | `limit` | `limit` – gleiches Maximum von 1.000 | | `before` | `paginationToken` aus der vorherigen Antwort | | `until` | `filters.signature.gt` | | `commitment` | `commitment` – `confirmed` oder `finalized` nur; `processed` wird nicht unterstützt | | `minContextSlot` | `minContextSlot` – unverändert | ### Von getTransaction | Alte Option | Neues Äquivalent | | -------------------------------- | --------------------------------------------------------- | | `encoding` | `encoding` – gilt, wenn `transactionDetails` `"full"` ist | | `maxSupportedTransactionVersion` | `maxSupportedTransactionVersion` – unverändert | | `commitment` | `commitment` – gleiche Regel wie oben | Zwei Fähigkeiten haben überhaupt kein altes Äquivalent: * `filters` — schränkt Ergebnisse nach `blockTime`, `slot`, `status`, `tokenTransfer` oder `tokenAccounts` serverseitig ein, anstatt alles abzurufen und im Code zu filtern. * `sortOrder: "asc"` — chronologisch (älteste zuerst) Ergebnisse, die die Standardmethoden nicht zurückgeben können, ohne die gesamte Historie abzurufen und umzukehren. ## Migrationsschritte `getTransactionsForAddress` ist Helius-exklusiv. Es funktioniert auf `https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY` (und Devnet) – derselbe Endpunkt, den deine bestehenden Aufrufe bereits nutzen, wenn du ein Helius-Kunde bist. Keine API-Schlüssel- oder Planänderungen erforderlich. Lösche den `getSignaturesForAddress` Aufruf und die `getTransaction` Schleife. Mache eine einzelne `getTransactionsForAddress` Anfrage mit `transactionDetails: "full"` und übertrage deine `encoding`, `maxSupportedTransactionVersion` und `commitment` Werte, wie in der [Parameterzuordnung](#parameterzuordnung) gezeigt. Wenn du nur Signaturen benötigst (zum Beispiel, um eine bestehende Pipeline zu versorgen), verwende stattdessen `transactionDetails: "signatures"` – es kostet 10 Credits pauschal pro Aufruf. Die Antwortstruktur ändert sich in drei Punkten: * Ergebnisse befinden sich in `result.data` (ein Array), nicht direkt in `result`. * Jeder Eintrag im Vollmodus ist `{ slot, transactionIndex, blockTime, transaction, meta }`. Die `transaction` und `meta` Objekte sind in der Struktur identisch zu dem, was `getTransaction` zurückgibt, sodass dein Parser-Code unverändert bleibt. * Einträge im Signaturenmodus entsprechen der `getSignaturesForAddress` Ausgabe (`signature`, `slot`, `err`, `memo`, `blockTime`, `confirmationStatus`) plus einem neuen `transactionIndex` Feld. Ein Verhaltensunterschied, den du beachten solltest: Mit dem alten Muster konnte ein `getTransaction` Aufruf `null` für eine Signatur zurückgeben. Mit `getTransactionsForAddress` ist jeder Eintrag in `result.data` eine vollständige Transaktion – entferne jegliche Nullbehandlung für fehlende Details. Tausche die `before` Cursor-Schleife gegen `paginationToken` aus: ```javascript theme={"system"} let paginationToken = null; const allTransactions = []; do { const response = await fetch('https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransactionsForAddress', params: [ 'YOUR_ADDRESS_HERE', { transactionDetails: 'full', maxSupportedTransactionVersion: 1, limit: 1000, ...(paginationToken && { paginationToken }) } ] }) }); const { result } = await response.json(); allTransactions.push(...result.data); paginationToken = result.paginationToken; } while (paginationToken); ``` Die Schleife endet, wenn `paginationToken` `null` ist – keine vergleichenden Signaturlisten mehr oder Selbstverfolgung der letzten Signatur erforderlich. Wenn du `until` verwendet hast, um bei einer bekannten Signatur zu stoppen, ersetze es durch `filters.signature: { gt: "KNOWN_SIGNATURE" }`. Wenn du es verwendet hast, um zu einem Zeitpunkt zu stoppen, ist `filters.blockTime` oder `filters.slot` normalerweise eine sauberere Lösung. Das alte Muster verpasst die Aktivitäten des zugehörigen Token-Accounts (ATA) vollständig, es sei denn, du hast auch `getTokenAccountsByOwner` aufgerufen und Signaturen für jedes Token-Konto abgerufen. Um es einzuschließen, füge einen Filter hinzu: ```json theme={"system"} { "filters": { "tokenAccounts": "balanceChanged" } } ``` `balanceChanged` gibt Transaktionen zurück, die sich auf die Brieftasche beziehen oder das Guthaben eines von ihr besessenen Token-Kontos ändern, wobei Spam herausgefiltert wird. Sieh dir [zugehörige Token-Konten](/docs/de/rpc/gettransactionsforaddress#zugehörige-token-konten) für die `none`/`balanceChanged`/`all` Optionen und das Vor-2022-Argument an. Für eine Beispieladresse, hole die Historie auf beide Arten ab und vergleiche die Signatursätze. Mit `filters.tokenAccounts` nicht gesetzt (der Standard `none`), gibt `getTransactionsForAddress` dieselben Transaktionen wie `getSignaturesForAddress` für denselben Bereich zurück. Dann bereitstellen und den alten Codepfad entfernen. ## Verhaltensunterschiede überprüfen Die meisten Migrationen sind ein nahtloser Ersatz, aber überprüfe diese Punkte vor dem Versand: * **Engagement.** `processed` wird nicht unterstützt; verwende `confirmed` oder `finalized`. Wenn dein alter Code habe aktuelle Historie bei `processed` abgerufen, wechsle zu `confirmed`. * **Messung.** Volltransaktionsantworten kosten 10 Credits pro 100 zurückgegebenen Transaktionen (10-Credit-Mindestbetrag); reine Signaturantworten kosten 10 Credits pauschal. Das alte Muster kostete 1 Credit pro Aufruf – günstiger pro Anfrage, aber viel teurer pro abgerufene Transaktion. Fehlgeschlagene Antworten sind kostenlos. Siehe [Messung](/docs/de/rpc/gettransactionsforaddress#messung). * **Netzwerkunterstützung.** Mainnet hat unbegrenzte Aufbewahrung. Devnet wird mit 2 Wochen Aufbewahrung unterstützt. Testnet wird nicht unterstützt. * **Reservierte Adressen.** Eine kleine Anzahl von Systemadressen (Vote Program, System Program, sysvars) umleiten zu Fallback-Archivpfaden oder geben nichts zurück. Wenn du diese indizierst, überprüfe [Einschränkungen und Sonderfälle](/docs/de/rpc/gettransactionsforaddress#einschränkungen-und-randfälle). * **Mehrere Adressen.** Wie beim alten Flow deckt eine Anfrage eine Adresse ab. Anfrage parallelisieren und zusammenführen; siehe [mehrere Adressen](/docs/de/rpc/gettransactionsforaddress#mehrere-adressen). ## Häufig gestellte Fragen ### Ist getTransactionsForAddress eine standardmäßige Solana RPC-Methode? Nein. Es ist eine Helius-exklusive Methode, die auf Helius RPC-Endpunkten verfügbar ist. Standardmäßige Solana RPC und andere Anbieter bieten nur `getSignaturesForAddress` und `getTransaction` an. Deine anderen RPC-Aufrufe sind nicht betroffen – die Methode lebt am selben Endpunkt neben der gesamten standardmäßigen RPC-Oberfläche. ### Benötige ich nach der Migration immer noch getTransaction? Nur für einmalige Abfragen, bei denen du bereits eine Signatur und keinen Adresskontext hast, z. B. um eine spezifische Transaktion zu überprüfen, die ein Benutzer eingegeben hat. Für alle adressbasierten Historien – Backfills, Indizierung, Wallet-Aktivitätsfeeds – ersetzt `getTransactionsForAddress` beide Methoden. ### Funktioniert es mit @solana/web3.js? Die Methode ist nicht in der `Connection` Klasse, aber sie funktioniert mit jedem HTTP-Client gegen deine Helius RPC-URL. Verwende `fetch` (oder das Äquivalent deiner Sprache) mit einem standardmäßigen JSON-RPC-Body, wie in den obigen Beispielen gezeigt. Du kannst `Connection` für alles andere weiterhin verwenden. ### Gibt es dieselben Transaktionen zurück wie getSignaturesForAddress? Ja. Mit Standardeinstellungen (`filters.tokenAccounts: "none"`) gibt es Transaktionen zurück, die sich auf die abgefragte Adresse beziehen – dasselbe wie `getSignaturesForAddress`. Das Setzen von `tokenAccounts` auf `balanceChanged` oder `all` gibt mehr zurück: Es fügt Aktivitäten aus den mit der Brieftasche verbundenen Token-Konten hinzu, die die Standardmethode nicht sehen kann. ### Wie viel kostet es im Vergleich zum alten Muster? Das Abrufen von 1.000 vollständigen Transaktionen kostet 100 Credits mit `getTransactionsForAddress` im Vergleich zu etwa 1.001 Credits (und 1.001 Anfragen) mit `getSignaturesForAddress` + `getTransaction`. Nur Signaturantworten kosten 10 Credits pauschal pro Aufruf. Siehe [Helius Credits](/docs/de/billing/credits) für vollständige Preisangaben. ## Lass einen KI-Agenten die Migration durchführen Wenn du Claude Code, Cursor oder einen anderen Coding-Agenten verwendest, füge die Eingabeaufforderung unten in die Agentensitzung deines Repositories ein. Er findet das alte Muster in deinem Code und schreibt es um. ````markdown theme={"system"} Migrate this codebase from the two-step Solana transaction history pattern (getSignaturesForAddress followed by getTransaction) to the single Helius RPC method getTransactionsForAddress. ## Background getTransactionsForAddress is a Helius-exclusive JSON-RPC method served on standard Helius RPC endpoints (https://mainnet.helius-rpc.com/?api-key=...). It returns up to 1,000 full transactions per call, replacing one getSignaturesForAddress call plus one getTransaction call per signature. Docs: https://www.helius.dev/docs/rpc/gettransactionsforaddress.md ## Step 1: Find the old pattern Search for: - getSignaturesForAddress calls (via @solana/web3.js Connection, raw JSON-RPC, or another SDK) whose signatures are then passed to getTransaction / getParsedTransaction / getTransactions - Pagination loops using `before` or `until` signature cursors - getTokenAccountsByOwner calls used only to fetch per-token-account signature history Leave standalone getTransaction calls (single-signature lookups with no address context) unchanged. ## Step 2: Rewrite each call site Replace the two-step flow with one raw JSON-RPC request (web3.js has no Connection helper for this method): ```javascript const response = await fetch(HELIUS_RPC_URL, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getTransactionsForAddress', params: [ address, // base-58 string { transactionDetails: 'full', // or 'signatures' if only signatures were used maxSupportedTransactionVersion: 1, // carry over from the old getTransaction options encoding: 'json', // carry over ('json', 'jsonParsed', 'base64', 'base58') limit: 1000, // up to 1,000 // paginationToken: '...', // from the previous response, for page 2+ // sortOrder: 'desc', // 'desc' (default, newest first) or 'asc' // filters: { ... } // optional, see mapping below } ] }) }); const { result } = await response.json(); // result.data -> array of transactions // result.paginationToken -> string cursor, or null when done ``` Parameter mapping: - limit -> limit - before: -> paginationToken (preferred) or filters: { signature: { lt: } } - until: -> filters: { signature: { gt: } } - commitment -> commitment ('confirmed' or 'finalized' only; if the old code used 'processed', use 'confirmed') - minContextSlot -> minContextSlot - encoding / maxSupportedTransactionVersion (from getTransaction) -> same names, top level of the config object Response shape: - Full mode: each entry is { slot, transactionIndex, blockTime, transaction, meta }. transaction and meta are identical in shape to getTransaction results, so existing parsing code carries over. Entries are never null - remove null-handling that existed for missing getTransaction results. - Signatures mode: entries match getSignaturesForAddress output ({ signature, slot, err, memo, blockTime, confirmationStatus }) plus transactionIndex. Pagination: loop while result.paginationToken is non-null, passing it back as paginationToken. Remove manual last-signature tracking. If the old code fetched signatures for the wallet's token accounts too (getTokenAccountsByOwner + per-account getSignaturesForAddress), replace all of it with one call using filters: { tokenAccounts: 'balanceChanged' } and delete the merge/dedupe logic. ## Step 3: Constraints and cleanup - The endpoint must be a Helius RPC URL; other providers do not serve this method. Do not change endpoints for other RPC calls. - Remove now-unused batching, throttling, and retry helpers that existed only for the getTransaction fan-out. - One request covers one address; keep parallel queries for multi-address code. - Preserve the surrounding code style and error handling conventions. ## Step 4: Verify - Run the project's type checks and tests. - Do NOT make any RPC calls yourself. Instead, write a standalone script (e.g. scripts/verify-gtfa-migration.mjs) that fetches history for one address both ways - the old getSignaturesForAddress + getTransaction flow and the new getTransactionsForAddress call with default filters - and prints whether the signature sets match, listing any differences. Read the RPC URL from an environment variable and the address from a CLI argument; never hardcode an API key. - Tell the user how to run it, for example: HELIUS_RPC_URL="https://mainnet.helius-rpc.com/?api-key=..." \ node scripts/verify-gtfa-migration.mjs
- Summarize every call site changed and flag any you were unsure about. ```` Die Eingabeaufforderung ist eigenständig – der Agent benötigt keinen Zugriff auf diese Seite. Für agentenbereite Dokumente, MCP-Suche und Fähigkeiten siehe [Helius für KI-Agenten](/docs/de/agents/overview). ## Nächste Schritte Vollständiges Tutorial zu Filtern, Sortieren, Paginierung und Token-Konten. Vollständiges Anforderungs- und Antwortschema. Verwende getTransactionsForAddress, um einen Solana-Index zu füllen und zu synchronisieren. Vergleiche alle Solana-Historien-Datenmethoden.