Skip to main content
A wallet’s history has two parts:
  • Transactions it sent (from) or received (to): ETH transfers and contract calls.
  • Token transfers in and out, which live in logs (Transfer events) of the token contracts, not in the wallet’s own transactions. A wallet can receive tokens without ever sending a transaction.
One request gets both. With the Python client:
How the filters combine:
  • Two transaction objects: a transaction matches if it’s from or to the wallet.
  • Two log objects: a Transfer matches if the wallet is the sender or the receiver.
  • address is not set on the logs, so transfers of every token are included. address in the output tells you which token.
The wallet in a topic must be padded to 32 bytes. 0x + 24 zeros + the 40 hex characters of the address. A 20-byte value in a topic filter is a 400.

Many wallets

Put several wallets in each list ("from": [w1, w2, …], "topic1": [t1, t2, …]). For thousands, create two sets: an address set for the transaction filters (fromSet, toSet) and a topic set of the padded wallets for the log filters (topic1Set, topic2Set).

What this doesn’t cover

  • Internal ETH transfers (ETH moved by a contract during a call) aren’t transactions or logs. Bloklake has no traces, so they aren’t visible.
  • Tokens that don’t emit standard Transfer events, and native-token movements on L2s that use other events. Add their events as more log filter objects.
  • Approvals, NFT transfers (ERC-721/1155): add their event signatures. ERC-721 Transfer shares topic0 with ERC-20 and is already included; ERC-1155 uses TransferSingle and TransferBatch, where the wallet is in topic2/topic3.

Reverted transactions

A reverted transaction still appears in the transactions stream with status = 0; its logs don’t exist (a revert discards them). Add "status": 1 to both transaction objects if you only want successful ones.