get_transaction_history

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. It is categorised as a Read tool in the VaultPilot MCP MCP Server, which means it retrieves data without modifying state.

get_transaction_history accepts 8 parameters: chain, limit, wallet, endTimestamp, startTimestamp, includeExternal, includeInternal, includeTokenTransfers. Required: wallet. The full parameter table on this page comes from the server's own tool schema.

Register the VaultPilot MCP server in PolicyLayer and add a rule for get_transaction_history: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.

get_transaction_history is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Yes. Add a rate_limit block to the get_transaction_history rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for get_transaction_history. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

get_transaction_history is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.