Crypto gives developers superpowers - seamless payment acceptance and instant network effects. And while AI has made crypto development easier, one of the pain points is still at the data layer - fundamentally, your agent still needs data from transactions, logs, etc.

Right now the query patterns are messy and incur a ton of waste. As one simple example, you might need data from logs, but you need one field from the transaction itself, so you pull a lot of data for both, filter them client-side, and join them.

MIP-16 is @category_xyz and @monad 's attempt to address longstanding problems in the RPC data interface by adding a new `eth_query` family of methods that allow for
- Filtering
- Relations (joins)
- Field selection (only request what you need)
- Better pagination

Filtering: The eth_getLogs method supports log filtering, but there is no way to filter transactions or traces. To query all transactions sent to a specific address, the user must fetch entire blocks and filter client-side

Relations: There is no way to join related objects in a single request. To fetch a set of logs and related transaction inputs, the user must make N+1 RPC requests (one to fetch logs, then one per unique transaction)

Field selection: Every RPC method returns a fixed object schema. Users that only need block number and timestamp have no choice but to fetch large unrelated fields like logsBloom, only to immediately discard them

Pagination: The eth_getLogs pagination design causes frequent timeouts and client-side workarounds. The RPC methods for blocks, transactions, and traces don't support range queries at all

We're excited to propose and ship this. We believe in repeatedly and iteratively giving developers better tools. Excellent effort from @typedarray @kyscott18 @andrthesnek and Jay Miller to make this happen