Skip to main content
Two queries return onchain transaction history for wallet accounts in your organization: list_eth_transaction_history for EVM chains and list_sol_transaction_history for Solana. Full request/response schemas, cURL examples, and SDK snippets can be found in the API reference.

Prerequisites

  • The queried address must belong to a Turnkey wallet account. Standalone private-key addresses are not supported.
  • Pass the network as a CAIP-2 identifier (caip2). For Solana, human-readable aliases such as solana:mainnet and solana:devnet are accepted and normalized to canonical CAIP-2 values by the API.

History coverage

Turnkey indexes onchain transaction history from a fixed start date for each supported network. The table below lists that date for every network available through list_eth_transaction_history and list_sol_transaction_history. For a given wallet account, the effective history start date is the later of:
  1. The network start date in the table below, and
  2. When the wallet account was added to Turnkey — either when it was created in a Turnkey wallet or when an existing address was imported.
Transactions that occurred onchain before the effective start date are not returned, even if they involved the address.

EVM transaction history

list_eth_transaction_history takes an organization ID, wallet account address, and EVM caip2 chain ID (for example eip155:1 for Ethereum mainnet or eip155:8453 for Base). Supported chains are listed in the API reference. Each item in transactions is ordered newest first and includes:
  • transactionHash, block (number, hash, RFC 3339 timestamp), and status (CONFIRMED or FINALIZED)
  • from, optional to, and origin (for example TURNKEY for Turnkey-submitted transactions)
  • fee with atomic amount and caip19 asset identifier
  • transfers[] with direction (IN / OUT relative to the queried address), asset, atomic amount, counterparty, and optional display strings for UI
  • Optional turnkey metadata when Turnkey submitted the transaction: sponsored, activityFingerprint, and submittedAt
Use transfers[] for value movement; to reflects the transaction destination (such as a called contract) and may differ from transfer counterparties.

Solana transaction history

list_sol_transaction_history uses the same request shape: organization ID, wallet account address, and Solana caip2 (canonical mainnet/devnet IDs or solana:mainnet / solana:devnet aliases). Solana responses mirror EVM items where applicable, with chain-specific fields:
  • signature instead of transactionHash
  • feePayer — the account that paid the transaction fee (first signer in the message)
  • signers[] — each signer’s address and whether the account was writable in the message
transfers, fee, and turnkey follow the same semantics as EVM history.

Pagination

Results are cursor-paginated via optional paginationOptions (limit between 1 and 100, default 10). Each response includes a pageInfo block:
  • hasNextPage / hasPreviousPage indicate whether more results exist in either direction.
  • Pass pageInfo.endCursor as the next request’s paginationOptions.after to fetch older transactions (continue paging down the newest-first list).
  • Pass pageInfo.startCursor as paginationOptions.before to fetch newer transactions.
  • Cursors are opaque and valid only for the same address and caip2 query. Do not construct or modify them.
Example pagination loop with @turnkey/sdk-server:
For Solana, call listSolTransactionHistory with the same pagination pattern.

SDK example

See the with-transaction-history example in the SDK repo for runnable EVM and Solana scripts with interactive prompts and multi-page fetching.

Next steps