Skip to main content
Logs don’t carry their transaction’s sender, input or gas. With joinTransactions, the response also contains the transaction of every matched log:
The response has a transactions stream (52 rows here) and a logs stream (72 rows). Several logs can belong to one transaction, which appears once.

​
Rules

  • It needs at least one logs filter object and at least one fields.transaction field (400 otherwise).
  • If you also send transactions filters, the transactions stream is the union: the filter’s matches plus the matched logs’ transactions, each once.
  • Transactions come back in the usual (block_number, transaction_index) order.
  • Joined transactions count toward maxObjects and are billed like any other row.
  • A transactions[].status filter, if present, applies to the joined transactions too. A transactions[].type filter doesn’t: it only narrows its own object’s matches.

​
Joining in your client

Match rows on (block_number, transaction_index). Select those two fields on both row types:
You can also join on transaction_hash (log) = hash (transaction), but hashes are 32 bytes each; two integers are smaller and faster.

​
The other direction

Matching a transaction does not pull in its logs. To get a transaction’s logs, filter logs too (for example on the contract it called) and join client-side on (block_number, transaction_index).