ENSIP-21 is best understood as a transport and orchestration layer above ERC-3668, not as a resolver feature or a generic multicall. It standardizes how multiple OffchainLookup reverts can be turned into one batched gateway request.
The spec’s own analogy is unusually revealing: it is effectively Promise.allSettled() for OffchainLookup. That framing makes the control surface clear — batching, retry/failure handling, and gateway choice move into a reusable client/gateway layer.
The core mechanism is the IBatchGateway.query(Request[] requests) interface, where each request preserves the original sender, urls, and callData, while the response cleanly separates transport failure (failures[i] == true) from valid-but-erroring application responses (failures[i] == false, error bytes in responses[i]).
The x-batch-gateway:true pseudo-URL matters more than it first appears. It lets clients substitute a local BGOLP implementation, which the spec and Universal Resolver docs both frame as a privacy and latency improvement over using an external batch gateway service.
ENSIP-23 shows why ENSIP-21 belongs in the corpus: Universal Resolver folds ENSIP-21 directly into modern ENS resolution, especially for smart multicall and CCIP-Read-heavy resolution paths.
ERC-3668 remains the lower bound beneath ENSIP-21. ERC-3668 standardizes one offchain lookup plus callback validation; ENSIP-21 adds a batching layer for many such lookups without changing the requirement that each underlying protocol verifies its own response.
ENSIP-10 is useful context because wildcard and extended-resolution flows increase the practical importance of offchain lookup orchestration. ENSIP-21 is part of the stack that keeps those richer resolution patterns from exploding client complexity.
Specific source signals worth retaining
ENSIP-21 is the best direct source for the batch gateway interface, failure semantics, local-gateway substitution rule, and the statement that compliant BGOLP gateways are equivalent.
ENSIP-23 is the best source for downstream significance: Universal Resolver explicitly incorporates ENSIP-21 and warns that lacking local ENSIP-21 support leaks information and adds latency through external batch gateways.
ERC-3668 is the best source for the serial baseline — OffchainLookup, gateway transport, callback verification, and nested-call safety — that ENSIP-21 extends rather than replaces.
ENSIP-10 is the best nearby source for why ENS resolution now needs richer resolver/gateway coordination than old exact-match onchain lookups did.
Why this entry belongs in the corpus
It exposes a lower-layer control surface in ENS and offchain-read infrastructure that would be flattened if kept only as an implementation detail of Universal Resolver.
It helps separate three layers that often get blurred together: contract-thrown offchain read directives, batch gateway orchestration, and the application-specific proof/verification logic that still has to secure each response.
The durable insight is that offchain-read systems do not just depend on proof formats and gateways; they also depend on who controls batching, local-versus-remote gateway execution, retry/failure handling, and privacy defaults in client libraries.