Does the Polygon PoS bridge guarantee immediate post‑deposit state visibility after a checkpoint, or can RPC reads remain stale?

The goal is to determine whether, once a deposit transaction is included in a Polygon PoS checkpoint and that checkpoint is finalized on Ethereum, a read‑only eth_call to the user’s address on a Polygon node will always reflect the deposited balance, or whether a temporary stale‑cache window can still cause pre‑deposit reads.

This depends on factors such as the node client (Bor, Erigon) and its sync mode, the ~30‑minute checkpoint frequency, the typical 2‑second block interval, and whether developers wait for a certain number of confirmations or rely on the bridge’s exit event logs. The ongoing governance discussion about shortening the withdrawal challenge period highlights that the timing of state finality remains an unresolved design decision.

Does waiting for one Ethereum confirmation after the checkpoint transaction eliminate the stale‑cache window for eth_call? Is configuring the bridge to emit a finality signal sufficient for developers to trust immediate RPC reads, or must they rely on application‑level retries?