概要
getTransactionsForAddress はHelius専用のRPCメソッドで、アドレスのトランザクション履歴を高度なフィルタリング、柔軟なソート、効率的なページネーションを使用して返します。これが標準のSolana RPCの一部ではありません。
getSignaturesForAddress とは異なり、署名のみを返し、関連トークンアカウントをスキップしますが、getTransactionsForAddress はウォレットの関連トークンアカウント(ATA)のアクティビティを含む完全なトランザクションデータを1回の呼び出しで返すことができます。それにより、バックフィル、インデックス作成、および分析のための完全なアドレス履歴への最速の経路となります。
このメソッドは、1回の呼び出しで最大1,000の完全なトランザクションを返します。
柔軟なソート
時系列(古い順)または逆(新しい順)でソートします。
高度なフィルタリング
時間範囲、スロット、署名、ステータス、トークン転送でフィルタリングします。
完全なトランザクションデータ
完全なトランザクションの詳細を一回の呼び出しで取得します。追跡getTransactionは不要です。
トークンアカウント
アドレスの関連トークンアカウントに対するトランザクションを含めます。
いつ使用するか
getTransactionsForAddress を使用するとき:
- 関連トークンアカウントを含む完全なウォレットトークン履歴が必要な場合
- インデクサーやデータパイプラインのために単一呼び出しの高速バックフィルが必要な場合
- 時間ベースまたはスロットベースのトランザクション分析と報告が必要な場合
- 成功したトランザクションまたは失敗したトランザクションのみを保持するためのステータスフィルタリングが必要な場合
- 時系列履歴再生(古い順序)の場合
- トークン発行分析:最初のミントトランザクションと初期ホルダー
- ウォレット資金提供履歴およびカウンターパーティの発見
- 特定の期間のコンプライアンスおよび監査報告が必要な場合
getTransfersByAddress を使用します。
ネットワークサポート
クイックスタート
1
APIキーの取得
Helius Dashboard からAPIキーを取得します。
2
高度な機能を使ってクエリを行います
2つの日付の間で、ウォレットのすべての成功したトランザクションを取得し、時系列に並べます:
3
パラメータを理解します
この例では、主要な機能を示しています:
- transactionDetails: 完全なトランザクションデータを1回の呼び出しで取得するために
'full'に設定 - sortOrder: 時系列順(古い順)のために
'asc'、または新しい順のために'desc'を使用 - filters.blockTime:
gte(以上)およびlte(以下)で時間範囲を設定 - filters.status:
'succeeded'または'failed'のトランザクションに限定 - filters.tokenAccounts: 関連トークンアカウントの転送、ミント、およびバーンを含める
リクエストパラメータ
トランザクション履歴をクエリするアカウントのBase-58エンコードされた公開鍵
返すトランザクション詳細のレベル:
signatures: 基本的な署名情報(高速)full: 完全なトランザクションデータ(getTransaction呼び出しの必要をなくし、最大1,000件をサポート)
結果のソート順:
desc: 新しい順(デフォルト)asc: 古い順(時系列、履歴分析向け)
返すトランザクションの最大数:
transactionDetails: "signatures"で最大1000件transactionDetails: "full"で最大1000件
前回の応答からのページネーショントークン(形式:
"slot:position")コミットメントレベル:
finalized または confirmed。processed コミットメントはサポートされていません。結果を絞り込むための高度なフィルタリングオプション。
比較演算子を使用してスロット番号でフィルタリング:
gte, gt, lte, lt例: { "slot": { "gte": 1000, "lte": 2000 } }比較演算子を使用してUnixタイムスタンプでフィルタリング:
gte, gt, lte, lt, eq例: { "blockTime": { "gte": 1640995200, "lte": 1641081600 } }比較演算子を使用してトランザクション署名でフィルタリング:
gte, gt, lte, lt例: { "signature": { "lt": "SIGNATURE_STRING" } }トランザクションの成功/失敗ステータスでフィルタリング:
succeeded: 成功したトランザクションのみfailed: 失敗したトランザクションのみany: 成功および失敗の両方(デフォルト)
{ "status": "succeeded" }関連トークンアカウントのトランザクションでフィルタリング:
none: 提供されたアドレスを参照するトランザクションのみを返す(デフォルト)balanceChanged: 提供されたアドレスまたは提供されたアドレスが所有するトークンアカウントの残高を変更するトランザクションを返す(推奨)all: 提供されたアドレスまたは提供されたアドレスが所有する任意のトークンアカウントを参照するトランザクションを返す
{ "tokenAccounts": "balanceChanged" }クエリされたアドレスがカウンターパーティ、方向、ミント、または生の量範囲に一致するトークン転送に参加したトランザクションにフィルタリングします。すべてのフィールドはオプションであり、ANDセマンティクスで組み合わされます。例:
{ "tokenTransfer": { "direction": "in", "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v" } }カウンターパーティのアドレス。このアドレスを他方の側とする転送に一致します。
クエリされたアドレスに対する転送方向でフィルタリング:
in: クエリされたアドレスが受け取った転送out: クエリされたアドレスが送信した転送any: 入出転送
フィルタリングするトークンミント。
UIや小数点調整された量ではなく、生のオンチェーン量を使用して量を比較します。
gt, gte, lt, lteをサポートします。トランザクションデータのエンコーディング形式(
transactionDetails: "full"時にのみ適用されます)。getTransaction APIと同じです。オプション: json, jsonParsed, base64, base58返す最大トランザクションバージョンを設定します。省略した場合、レガシートランザクションのみが返されます。すべてのバージョン化されたトランザクションを含めるには、
0 に設定します。リクエストを評価できる最小スロット
メータリング
成功した応答は返されるものによってメーターされます:応答
応答の形式はtransactionDetails に依存します。署名モードは軽量な署名レコードを返し、完全モードは完全なトランザクションとメタデータオブジェクトを返します。
- 署名応答
- 完全なトランザクション応答
応答フィールド
transactionIndex フィールドは、getTransactionsForAddress に限定されます。他の類似のエンドポイントである getSignaturesForAddress, getTransaction, and getTransactions にはこのフィールドが含まれていません。
フィルタ
slot, blockTime, signature に対して比較演算子を使用でき、特別な status, tokenAccounts, tokenTransfer フィルタもあります。複数のフィルタを組み合わせることで、結果をそれらの交差部分に絞り込みます。
比較演算子
これらの演算子はデータベースクエリのように機能し、データ範囲に対する正確なコントロールを提供します。列挙フィルタ
組み合わせたフィルタの例:
関連トークンアカウント
Solanaでは、ウォレットはトークンを直接保持しません。その代わり、ウォレットはトークンアカウントを所有し、そのトークンアカウントがトークンを保持します。誰かがあなたにUSDCを送ると、それはあなたのUSDCトークンアカウントに送られ、メインのウォレットアドレスには送られません。 このメソッドはユニークで、関連トークンアカウント(ATAs)を含む完全なトークン履歴をクエリすることができます。getSignaturesForAddress のようなネイティブRPCメソッドはATAsを含みません。
この動作を制御するのがtokenAccounts フィルタです:
none(デフォルト): 直接ウォレットアドレスを参照するトランザクションのみを返します。直接のウォレットインタラクションのみを気にする場合に使用します。balanceChanged(推奨): ウォレットアドレスまたはウォレットが所有するトークンアカウントの残高を変更するトランザクションを返します。スパムや関連のない操作(手数料の回収やデリゲーションなど)を除外し、有意義なウォレット活動をクリーンに表示します。all: ウォレットアドレスまたはウォレットが所有する任意のトークンアカウントを参照するすべてのトランザクションを返します。
tokenAccounts フィルタは2022年12月以前のトランザクションをサポートしていません。これは、Solanaにトークントランスファーメタデータが導入されたスロット111,491,819に依存しています。以前のアクティビティをカバーするには、歴史的トークンアカウントの回避策 を参照してください。
トークン転送フィルタ
tokenTransfer フィルタは、クエリされたアドレスが特定の基準に一致するトークン転送に参加したトランザクションに結果を絞り込みます: 特定のカウンターパーティ、ミント、方向、または量範囲。
次のような質問に答えるために使用します:
- このウォレットは特定のカウンターパーティからいつUSDCを受け取りましたか?
- 1,000トークン以上のすべての送信転送を表示します。
- このウォレットがこの特定のミントに一度でも触れたのはいつですか?
filters オブジェクト内のオプションフィールドです:
tokenTransfer 内のすべてのフィールドはオプションです。複数のフィールドを組み合わせるとANDとして扱われます。
量の範囲演算子:
量演算子を組み合わせることができます。たとえば、
{ "gte": 1000000, "lte": 5000000 } は閉じた範囲です。tokenTransfer は他のトップレベルフィルタ(slot, blockTime, status, and tokenAccounts)と組み合わせて使用できます。最終結果は交差部分です。
例
時間ベースの分析
月次トランザクションレポートを生成する:トークンミントの作成
特定のトークンのミント作成トランザクションを見つける:資金提供トランザクション
特定のアドレスを誰が資金提供したかを見つける:トークン転送
tokenTransfer でフィルタリングして特定のトークン移動を分離します。
アドレスへのUSDC流入:
ページネーション
トランザクションが制限を超える場合、応答からpaginationToken を使用して次のページをフェッチします。トークンは単純な文字列で、APIにどこから続けるべきかを伝えます。
各応答からのページネーショントークンを使用して次のページをフェッチします:
複数アドレス
一度に複数のアドレスをクエリすることはできません。各アドレスクエリは個別のAPIリクエストとみなされ、それに応じてメーターされます。複数のアドレスのトランザクションをフェッチするためには、同じ時間またはスロットウィンドウ内で各アドレスをクエリし、次にそれをマージし、ソートします:ベストプラクティス
パフォーマンス。 完全なトランザクションデータが不要な場合はtransactionDetails: "signatures"を使用してください。合理的なページサイズを使用して応答時間を改善し、時間範囲または特定のスロットでフィルタリングして、よりターゲットを絞ったクエリを行います。
フィルタリング。 広範なフィルタから始め、徐々に絞り込んでいきます。分析や報告ワークフローには時間ベースのフィルタを使用し、複数のフィルタを組み合わせて特定のトランザクションタイプや期間をターゲットにした正確なクエリを実行します。
ページネーション。 大規模なクエリを後で再開する必要がある場合は、ページネーショントークンを保存します。パフォーマンス計画のためにページネーションの深さを監視し、歴史的イベントを時系列順に再生する必要がある場合は昇順を使用します。
エラーハンドリング。 レート制限に対処するには指数関数的バックオフを使用して優雅に処理します。リクエストを行う前にアドレスを検証し、APIの使用を減らすために適切な場合は結果をキャッシュします。
制限事項とエッジケース
少数のアドレスはレガシーアーカイブにルーティングされ、スロットスキャンのフォールバックに制限されるか、空のまま返されます。スロット111,491,819以前のトークンアカウントの発見にはワークアラウンドが必要です。完全な詳細については、以下のセクションを展開してください。サポートされていないおよび特別ルートのアドレス
サポートされていないおよび特別ルートのアドレス
古いアーカイブにルーティング。 これらのアドレスに対するリクエストは、私たちの古いアーカイブシステムにルーティングされます。
スロットスキャンフォールバック。 これらのアドレスに対するリクエストは、新しいアーカイブシステムに転送され、スロットごとのスキャンアプローチ(最大100スロット)によってクエリ可能です。ただし、このデータはインデックス化されていません。
空を返す(
is_reserved_address)。 リクエストは新しいアーカイブシステムに転送されますが、データはインデックス化されておらず、クエリは空を返します。回避策: 歴史的トークンアカウントの発見(スロット111,491,819以前)
回避策: 歴史的トークンアカウントの発見(スロット111,491,819以前)
スロット111,491,819より前にトークンアカウント活動のある住所について、
tokenAccounts フィルタは所有権を特定できません。これは、トークンのバランスメタデータにowner フィールドが存在しなかったためです。完全な結果を得るには、初期のトランザクション命令を解析してこれらのトークンアカウントを手動で発見し、それぞれ並行してgetTransactionsForAddress をクエリします。getSignaturesForAddressとの違いは何ですか?
標準のgetSignaturesForAddress メソッドに精通している場合、getTransactionsForAddress はマルチステップワークフローを単一の呼び出しに統合し、フィルタリング、ソート、トークンアカウントのサポートを追加します。
1回の呼び出しで完全なトランザクションを取得
getSignaturesForAddress を使用すると、2ステップ必要です:
getTransactionsForAddress では、1回の呼び出しです:
1回の呼び出しでトークン履歴を取得
getSignaturesForAddress を使用すると、最初にgetTokenAccountsByOwner を呼び出し、すべてのトークンアカウントをクエリする必要があります:
getTransactionsForAddress では、filters.tokenAccounts を設定するだけです:
追加機能
時系列ソート
sortOrder: 'asc' で古い順から新しい順にトランザクションをソートします。時間ベースのフィルタリング
blockTime フィルタを使用して時間範囲でフィルタリングします。ステータスフィルタリング
status フィルタで成功したトランザクションまたは失敗したトランザクションのみを取得します。よりシンプルなページネーション
paginationToken を使用して、混乱する before/until 署名の代わりにします。次のステップ
インデクシングガイド
getTransactionsForAddress を使用してSolanaインデックスのバックフィルと同期を行います。
getTransfersByAddress
支払いと調整用の解析され、転送のみの履歴。
APIリファレンス
getTransactionsForAddress の完全なリクエストと応答のスキーマ。
歴史的データの概要
すべてのSolana歴史的データメソッドを比較します。