> ## 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. # getSignaturesForAddress + getTransactionからgetTransactionsForAddressへの移行 > getSignaturesForAddress + getTransactionループを単一のgetTransactionsForAddress呼び出しに置き換えます。パラメータマッピング、前後のコード、ページネーションの変更、移行を自動化するコピーペースト用AIエージェントプロンプトを含みます。 ## なぜ移行するのか？ Solanaでアドレスのトランザクション履歴を取得する標準的な方法は二段階です。まず署名をリストするために`getSignaturesForAddress`を呼び出し、次に詳細を取得するために署名ごとに`getTransaction`を呼び出します。1,000件のトランザクションでは、1,001件のHTTPリクエストが必要です。 [`getTransactionsForAddress`](/docs/ja/rpc/gettransactionsforaddress)はHelius限定のRPCメソッドで、この2ステップを1つの呼び出しにまとめます。1リクエストあたり最大1,000件の完全なトランザクションを返します。フィルタリング、双方向ソート、トークンアカウントのサポートがあり、標準的な方法ではこれらがありません。 | | `getSignaturesForAddress` + `getTransaction` | `getTransactionsForAddress` | | ---------------------------- | -------------------------------------------- | ------------------------------- | | 1,000件のトランザクションに対するリクエスト数 | 1,001 | 1 | | 1,000件の完全なトランザクションに対するクレジット数 | 約1,001（1コールあたり1クレジット） | 100（100トランザクションあたり10クレジット） | | 関連トークンアカウント（ATA）履歴 | 含まれない | `filters.tokenAccounts`を介して含まれる | | 時間とスロット範囲フィルタ | なし | あり | | ステータスフィルタ（成功/失敗） | なし | あり | | 並べ替え順序 | 最新のものを最初にのみ | 最新または古いものを最初に | | ページネーション | `before`/`until`署名 | `paginationToken` | 結果：およそ10倍少ないクレジット、1,000倍少ないラウンドトリップ、そしてクライアント側でのバッチ処理、レート制限処理、再試行ロジックは不要です。 ## 前後の比較 ここで、アドレスの最後の1,000件のトランザクションを完全な詳細で取得するタスクを、両方のパターンで示します： ```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: 0 }] }) }); 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: 0, limit: 1000 } ] }) }); const { result } = await response.json(); const transactions = result.data; // Full transactions, same shape as getTransaction ``` `getTransactionsForAddress`は標準Solana RPCに含まれていないため、`@solana/web3.js`には`Connection`ヘルパーがありません。上記のように生のJSON-RPCリクエストで呼び出してください。他のRPCトラフィックと同じHeliusエンドポイントで動作します。 ## パラメータマッピング 古い2ステップのフローのすべてのオプションには直接の対応があります。ほとんどの名前は変更されずに引き継がれます—ページネーションだけが異なります。 ### getSignaturesForAddressから | 古いオプション | 新しい対応 | | ---------------- | ------------------------------------------------------------------- | | `limit` | `limit` — 同じ1,000の最大数 | | `before` | `paginationToken`前回の応答から | | `until` | `filters.signature.gt` | | `commitment` | `commitment` — `confirmed`または`finalized`のみ; `processed`はサポートされていません | | `minContextSlot` | `minContextSlot` — 変更なし | ### getTransactionから | 古いオプション | 新しい対応 | | -------------------------------- | ---------------------------------------------------- | | `encoding` | `encoding` — `transactionDetails`が`"full"`の場合に適用されます | | `maxSupportedTransactionVersion` | `maxSupportedTransactionVersion` — 変更なし | | `commitment` | `commitment` — 上記と同じルール | 2つの機能は、以前の対応が全くありません： * `filters` — 結果をサーバーサイドで`blockTime`、`slot`、`status`、`tokenTransfer`、または`tokenAccounts`で絞り込むか、すべてを取得してコード内でフィルタリングします。 - `sortOrder: "asc"` — 標準メソッドでは履歴全体を取得して逆にしないと返せない年代順（古いものを最初に）結果。 ## 移行手順 `getTransactionsForAddress`はHelius限定です。Heliusの顧客であれば、既存の呼び出しが使用するのと同じエンドポイントである`https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY`（およびdevnet）で動作します。APIキーやプランの変更は不要です。 `getSignaturesForAddress`の呼び出しと`getTransaction`ループを削除します。単一の`getTransactionsForAddress`リクエストを`transactionDetails: "full"`で行い、[パラメータマッピング](#パラメータマッピング)に示されるように、`encoding`、`maxSupportedTransactionVersion`、そして`commitment`の値を引き継ぎます。 署名のみが必要な場合は（たとえば、既存のパイプラインに供給するため）、代わりに`transactionDetails: "signatures"`を使用してください — これは1コールあたり10クレジットがかかります。 応答エンベロープが3つの方法で変わります： * 結果は`result`ではなく、`result.data`（配列）にあります。 * 各フルモードエントリは`{ slot, transactionIndex, blockTime, transaction, meta }`です。`transaction`と`meta`オブジェクトは、`getTransaction`が返すものと形状が同じなので、解析コードはそのまま持続します。 * 署名モードエントリは、`getSignaturesForAddress`出力（`signature`、`slot`、`err`、`memo`、`blockTime`、`confirmationStatus`）に加えて新しい`transactionIndex`フィールドと一致します。 古いパターンの場合、`getTransaction`の呼び出しで署名に対して`null`を返す可能性がありました。`getTransactionsForAddress`では、`result.data`内のエントリはすべて完全なトランザクションなので、不足している詳細のnull処理を削除します。 `before`カーソルループを`paginationToken`に置き換えます： ```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: 0, limit: 1000, ...(paginationToken && { paginationToken }) } ] }) }); const { result } = await response.json(); allTransactions.push(...result.data); paginationToken = result.paginationToken; } while (paginationToken); ``` ループは`paginationToken`が`null`になると終了します—署名リストの比較や、最後の署名を自分で追跡する必要はありません。 既知の署名で停止するために`until`を使用している場合は、`filters.signature: { gt: "KNOWN_SIGNATURE" }`に置き換えてください。特定の時点で停止するために使用している場合は、`filters.blockTime`または`filters.slot`を使用する方が通常は適しています。 古いパターンでは、すべてのトークンアカウントに対して署名を呼び出して取得しない限り、関連トークンアカウント（ATA）活動は完全に見逃されます。これを含めるには、1つのフィルタを追加します： ```json theme={"system"} { "filters": { "tokenAccounts": "balanceChanged" } } ``` `balanceChanged`は、スパムをフィルタリングして、ウォレットを参照するまたは所有する任意のトークンアカウントのバランスを変更するトランザクションを返します。[関連トークンアカウント](/docs/ja/rpc/gettransactionsforaddress#関連トークンアカウント)で`none`/`balanceChanged`/`all`のオプションと2022年前の注意事項を参照してください。 サンプルアドレスについて、両方の方法で履歴を取得し、署名セットを比較してください。`filters.tokenAccounts`未設定（デフォルトの`none`）では、`getTransactionsForAddress`は同じ範囲で`getSignaturesForAddress`と同じトランザクションを返します。その後デプロイし、古いコードパスを削除します。 ## 確認するべき動作の違い ほとんどの移行はそのまま置き換え可能ですが、出荷前に以下を確認してください： * **コミットメント。** `processed`はサポートされていません。`confirmed`または`finalized`を使用してください。古いコードで最近の履歴を`processed`でポーリングしていた場合、`confirmed`に切り替えてください。 - **メータリング。** 完全トランザクションの応答は、返された100トランザクションあたり10クレジット（最低10クレジット）かかります。署名のみの応答は10クレジットがフラットでかかります。古いパターンは1コールあたり1クレジット—1リクエストあたりのコストは安いですが、取得したトランザクションあたりのコストがはるかに高いです。失敗した応答は無料です。詳細は[メータリング](/docs/ja/rpc/gettransactionsforaddress#メータリング)を参照してください。 - **ネットワークサポート。** Mainnetは無制限の保持を持っています。Devnetは2週間の保持でサポートされています。Testnetはサポートされていません。 - **予約済みアドレス。** システムアドレスの小さなセット（Vote Program、System Program、sysvars）は、フォールバックアーカイブルートにルーティングされるか、空を返します。それをインデックスする場合は、[制約とエッジケース](/docs/ja/rpc/gettransactionsforaddress#制限とエッジケース)を参照してください。 - **複数のアドレス。** 古いフローと同様に、1リクエストで1アドレスをカバーします。アドレスを並行してクエリし、マージします。[複数のアドレス](/docs/ja/rpc/gettransactionsforaddress#複数のアドレス)を参照してください。 ## よくある質問 ### getTransactionsForAddressは標準的なSolana RPCメソッドですか？ 違います。これはHelius限定のメソッドで、Helius RPCエンドポイントで利用可能です。標準的なSolana RPCやその他のプロバイダは、`getSignaturesForAddress`と`getTransaction`のみを提供します。他のRPC呼び出しには影響しません—このメソッドは完全な標準的なRPCサーフェイスの隣で同じエンドポイントにあります。 ### 移行後もgetTransactionは必要ですか？ 既に署名を持っており、アドレスのコンテキストがないときに一度の検索が必要な場合のみ必要です。アドレスに基づく履歴（バックフィル、インデクシング、ウォレット活動フィード）については、`getTransactionsForAddress`が両方のメソッドを置き換えます。 ### @solana/web3.jsと一緒に動作しますか？ このメソッドは`Connection`クラスには含まれていませんが、Helius RPC URLに対して任意のHTTPクライアントで動作します。標準のJSON-RPCボディを用いて、`fetch`（またはお使いの言語の相当するもの）を使用してください。その他の処理には引き続き`Connection`を使用可能です。 ### getSignaturesForAddressと同じトランザクションを返しますか？ はい。デフォルト設定（`filters.tokenAccounts: "none"`）の場合、クエリされたアドレスを参照するトランザクションを返します—`getSignaturesForAddress`と同じセットです。`tokenAccounts`を`balanceChanged`または`all`に設定すると、ウォレットの関連トークンアカウントの活動も追加され、標準メソッドでは見えません。 ### 古いパターンと比べて費用はどれくらいかかりますか？ 1,000件の完全なトランザクションを取得するには`getTransactionsForAddress`で100クレジットがかかりますが、`getSignaturesForAddress` + `getTransaction`では約1,001クレジット（および1,001リクエスト）が必要です。署名のみによる応答は1コールあたり10クレジットがフラットでかかります。詳細な価格設定は[Heliusクレジット](/docs/ja/billing/credits)を参照してください。 ## AIエージェントに移行を任せる Claude Code、Cursor、その他のコーディングエージェントを使用している場合は、以下のプロンプトをリポジトリのエージェントセッションに貼り付けてください。コードベース内の古いパターンを見つけ出し、書き換えます。 ````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: 0, // 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. ```` このプロンプトは自己完結型です。このページへのアクセスがエージェントに必要ありません。エージェント対応ドキュメント、MCP検索とスキルは[Helius for AI agents](/docs/ja/agents/overview)を参照してください。 ## 次のステップ フィルター、ソート、ページネーション、トークンアカウントに関する完全なチュートリアル。 完全なリクエストと応答のスキーマ。 Solanaインデックスをバックフィルし同期するためにgetTransactionsForAddressを使用。 すべてのSolana履歴データメソッドを比較。 Full tutorial covering filters, sorting, pagination, and token accounts. Complete request and response schema. Use getTransactionsForAddress to backfill and sync a Solana index. Compare all Solana historical data methods.