JSON-RPC batching and Multicall solve different problems

JSON-RPC batching groups requests in one transport message. Multicall groups contract calls inside one EVM execution. They reduce different forms of overhead and have different semantics.

Geth's batching guide demonstrates independent requests sent as an array. Match responses by request ID rather than relying on arrival order. A batch alone does not turn several latest-state queries into one atomic contract read.

The Multicall3 project describes collecting contract read results through one eth_call, with a shared block context and per-call success handling for supported methods.

Choose by dependency

Multicall changes call context. A target sees the calling contract according to CALL or DELEGATECALL semantics, so a function depending on msg.sender may behave differently from a direct call. Do not generalize a read optimization into a wallet authorization mechanism.

Handle partial failure

One broken metadata method should not necessarily hide every balance. Select an aggregation method whose failure behavior matches the task, inspect each result and decode only successful return data. Bound batch size so one oversized request does not exceed node limits.

Verify the actual deployment on the selected chain. A familiar address string is not a guarantee of identical code. Fixtures should include reordered RPC responses, one failed subcall and a sender-sensitive function. These cases reveal semantic differences that a latency-only comparison misses.