Why Polygon Exit Proofs Can Go Stale

A Polygon exit proof can fail when its data does not match the burn transaction and the checkpoint recorded on Ethereum. That does not mean every proof expires with age. In the Polygon PoS bridge, a withdrawal starts by burning tokens on Polygon. To finish, you submit proof on Ethereum that the burn happened in a block covered by a checkpoint, a record of Polygon blocks posted to Ethereum.

What does an exit proof need to show?

It must connect the burn to a block and show that block belongs to a checkpoint. The proof includes data from the Polygon block and receipt, plus a Merkle proof, a path that shows an item belongs to a larger set. Ethereum’s RootChainManager checks the data before the bridge releases the matching tokens.

That is why a Polygon withdrawal has a wait between burning and claiming: the burn’s block must first be checkpointed. For a closer look at how token routes affect this process, see this guide to how Polygon Bridge routes depend on the token. Once a checkpoint covers the block, the proof can be assembled for the Ethereum claim.

Why can a proof seem stale?

Often, “stale” describes a payload that no longer matches the transaction or the data used by the Ethereum contract. A proof requested before the burn is checkpointed may not be available yet. A payload built for the wrong burn, event, or token can also fail verification. And if another transaction already completed the exit, trying the same claim again will fail.

A checkpoint moving forward does not, by itself, make a proof for an older covered block expire. The block and its receipt are fixed once recorded. The useful question is whether the payload still matches the burn and checkpoint, and whether the exit has already been processed.

What should you check before trying again?

Start with the burn transaction on Polygon, then check its checkpoint and the status of the exit on Ethereum. If the block is not covered yet, wait and request the payload again after checkpointing. If it is covered, check the transaction hash and the event being claimed before submitting.

• Confirm the burn transaction succeeded on Polygon.
• Check that its block is included in an Ethereum checkpoint.
• Make sure the payload refers to the right burn and token event.
• Check Ethereum activity to see whether the exit already went through.

Rebuilding a payload is sensible when the block is checkpointed but the proof fails or its source data may be mismatched. Keep the original burn transaction hash: it is the reference point for generating the exit proof again. The main trade-off is time. Waiting for a checkpoint adds delay, but it lets Ethereum verify the withdrawal against an on-chain record rather than trusting a bridge operator’s say-so.