Wallet transaction history for any address, on any chain
Query any address and get its history: token transfers, native and internal value, NFT movements, and contract calls, across 225+ networks through one query shape. Balances and portfolios are computed from that history, not read from a per-chain API.
Built for Wallets & Payments at scale
Address-keyed history
Filter logs, traces, and transactions by address in one query shape. Token transfers, native and internal value, NFT movements, and contract calls for any address, streamed with cursor pagination even for addresses with millions of transfers.
Multi-standard token data
ERC-20 transfers, ERC-721 ownership changes, and ERC-1155 batch transfers, decoded with token metadata. The same Transfer history is what you fold into per-token balances, so you control the reconstruction instead of trusting a cached snapshot.
One query shape, every chain
The same address-filtered query runs against Ethereum, Base, Arbitrum, Solana, and the rest. Point it at each dataset and merge, so a unified multi-chain feed is one integration instead of a separate client per network.
Transfer streaming for alerts
Stream Transfer, Approval, and ApprovalForAll events for monitored addresses as they confirm onchain. Build payment notifications, approval-revocation alerts, and activity feeds without managing WebSocket connections.
One query, keyed by address, not by block
A blockchain stores data by block and transaction; a wallet needs it by address. That re-keying is the whole problem, because a node's JSON-RPC has no eth_getTransactionsByAddress. The Portal indexes the chain ahead of time and lets you filter logs, traces, and transactions by address in one request shape.
We asked the Portal for vitalik.eth's last seven days (blocks 25,328,971 to 25,379,204). One address-keyed query returned 30 activity rows across transactions, token transfers, and NFT movements. The asset flow it summed:
- ETH+0.0001native
- USDC+5.541929token
- MOODENG+17,776token (airdrop)
- WARS+10token (airdrop)
A few real transfers (USDC, ETH) buried in airdrop spam (MOODENG, WARS, plus six unnamed tokens). Separating real holdings from spam is the wallet-history problem, and it starts with having every transfer in one place. The largest single inbound was 0xd6f1…d48f at block 25,373,139.
The primitive underneath is one log filter. Transfer puts the recipient in topic2; query it across every ERC-20 and ERC-721 token (which share the Transfer signature), with no contract filter, over any block window:
Swap topic2 for topic1 to get outgoing transfers. The log's address is the token contract; the amount is in data. Point the same body at base-mainnet or arbitrum-one for other chains.
A log-only feed silently drops value
The hardest part of a wallet history is the value that logs do not record. When a contract forwards ETH to an address mid-execution, a withdrawal, a disbursement, a batched payout, nothing appears in the transaction list or the event logs. It only exists in the execution trace. A feed built on logs alone returns a history that omits it, which is a correctness bug in a balance, not a gap in coverage. The Portal exposes traces filtered by callTo and callFrom in the same request shape as the logs query above:
Balances are derived, not returned
The Portal serves transfers, not balances. A balance is the sum of transfers in minus out per token, and a historical balance is that sum truncated at a block. You fold the transfer history into balances in a Squid SDK indexer, which keeps the reconstruction under your control.
The full three-query walk
Logs, traces, and transactions filtered by address, unioned by transaction hash, are the complete timeline. The wallet history guide shows each query and how balances fall out of the indexed result.
Everything a wallet feed reads from, in one API
Stop stitching together separate providers for transactions, token transfers, NFTs, approvals, and internal value. The Portal serves the full data surface a wallet renders from.
What teams build with SQD
Other ways teams use SQD
Each of these runs on the same SQD data layer.
A DEX swap settles its token movement in nested internal calls; an event-log-only feed sees the receipt, not the execution.
SQD sits at the extract-and-decode end of the analytics pipeline.
A raw event log is hex-encoded topics and data.
Onchain, every stablecoin movement is a Transfer event: a mint is a transfer from the zero address, a burn is a transfer to it, a payment is one between two wallets.
A tokenized treasury fund is a regulated security that lives on a public chain.
Most indexers give you event logs.
Bitcoin inputs and outputs are first-class in the same declarative query shape, so you trace UTXO flows from sender to recipient without running a node.
Address-keyed access to transaction history, balances, and token holdings. What wallets, accounting tools, and tax software need.
Frequently asked questions
How do I get a wallet's full transaction history?
Does the Portal return token balances directly?
Can one query return history across multiple chains?
How are internal transfers and contract-forwarded value handled?
Your blockchain data infrastructure, handled.
Private Portal. Dedicated. Validated. Managed. Tell us what you're building, we'll show you what it looks like on SQD.
validated data
for Enterprise
serving data