get_transaction_history
Fetch a wallet's recent on-chain transaction history across chains, merging external, token, and internal transactions, with decoded methods and USD values. Filters address-poisoning dust.
Instructions
Fetch a wallet's recent on-chain transaction history on a single chain, merged across external (user-initiated) txs, ERC-20/TRC-20 token transfers, and internal (contract-initiated) txs. Results are sorted newest-first, capped at limit (default 25, max 50), and annotated with decoded method names (via 4byte.directory) and historical USD values at the time of each tx (via DefiLlama). Supports Ethereum/Arbitrum/Polygon/Base/Optimism via Etherscan, TRON via TronGrid, and Solana via the configured Solana RPC. On Solana, results include a fourth item type program_interaction for DeFi calls (Jupiter swaps, Marinade/Jito liquid staking, Raydium/Orca swaps, native validator staking, or any unknown program) with balance-delta summaries showing net SOL + SPL changes for the wallet across the tx — more useful than raw instruction data for 'what happened to my wallet?'. includeInternal has no meaning for TRON (silently ignored) or Solana (doesn't have an 'internal' concept — CPI effects are captured inside program_interaction deltas). Use this to answer 'what did I do last week?', 'show me my recent swaps', or 'did I already approve X?' without the user pasting tx hashes. Read-only — no signing, no broadcast. Items may carry an optional suspectedPoisoning field flagging address-poisoning heuristics: zero_amount_transfer (USDC transferFrom 0-amount exploit, chain-agnostic), vanity_suffix_lookalike (dust tx whose counterparty mimics another counterparty's first-4 + last-4 hex chars; mimics field names the matched address), and self_suffix_lookalike (counterparty mimics the wallet itself). EVM-only for the suffix rules. AGENT BEHAVIOR: this field is for you, NOT for the user. Do NOT include flagged entries in the user-facing summary — they're noise that crowds out real activity (a single poisoned wallet can have dozens of dust-lookalike entries pinned at the top by recency). Filter them out silently; if the user asks 'is that everything?' or you want to be transparent about the filter, mention briefly like 'hid N suspected-poisoning entries (use the raw response if you want to inspect them)'. Surface a flagged entry only when the user explicitly asks about a specific tx hash that happens to match, or about address-poisoning attempts on this wallet. The point of the flag is to keep poisoning data accessible to your reasoning (e.g. when validating a future prepare_* recipient against the wallet's history) WITHOUT polluting chat with scam noise.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | ||
| chain | No | ethereum | |
| limit | No | ||
| includeExternal | No | ||
| includeTokenTransfers | No | ||
| includeInternal | No | ||
| startTimestamp | No | ||
| endTimestamp | No |