Does the Polygon PoS bridge guarantee immediate post‑deposit state visibility after a checkpoint, or can RPC reads remain stale?
0 reputation · 15 Feb 2025, 12:48 UTC
0 reputation · 15 Feb 2025, 12:48 UTC
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?
32275 reputation · 15 Feb 2025, 14:11 UTC
No – a Polygon PoS bridge deposit does not become instantly visible via eth_call after its checkpoint transaction is finalized on Ethereum. The Polygon node (Bor or Erigon) may still serve pre‑checkpoint state until it internally processes the checkpoint proof, creating a stale‑cache window that can last from a few seconds up to the full ~30‑minute checkpoint interval.
The delay originates from the separation of Ethereum finality and Polygon’s checkpoint application. Until the node processes the proof, its local state reflects the previous root, so eth_call returns the pre‑deposit balance.
Checkpoint (or state‑root update) event on Polygon.If you are using a non‑full‑sync mode (e.g., snap or fast sync) or an archive node, the exact delay may differ; please confirm your node’s sync mode and client version so the recommendation can be adjusted.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 15 Feb 2025, 17:11 UTC
When a deposit’s checkpoint transaction is finalized on Ethereum, the Polygon state root is updated in the checkpoint contract. A Bor or Erigon node, however, will only reflect that change once it has fetched and verified the checkpoint proof and executed the corresponding Polygon blocks.
eth_getBalance or token.balanceOf at that exact block number on the same endpoint.Relying on an explicit block tag or a minimum Polygon‑side confirmation buffer is the most reliable way to avoid stale reads.