A Polygon PoS withdrawal needs two transactions because the Polygon burn proves intent, while a separate Ethereum transaction verifies that burn and releases the escrowed asset. For an integrator using Polygon Bridge, the gap between them is an expected protocol state: the burn must first be included in a checkpoint posted to Ethereum. Track both transactions separately.
The Polygon transaction starts the withdrawal
The first transaction runs on Polygon PoS and burns the bridged token. For a standard ERC-20 withdrawal, the child token’s withdrawal logic destroys the Polygon representation and records the burn in the transaction’s logs. No asset has been released on Ethereum yet.
Save the Polygon transaction hash and wait for a successful receipt. A wallet reporting that the transaction was submitted is not enough: it may still be pending, or it may have reverted. Your backend should also confirm that the transaction concerns the expected token and destination before treating it as a withdrawal request.
A checkpoint makes the burn provable on Ethereum
Polygon validators periodically submit checkpoints to Ethereum. A checkpoint commits to a range of Polygon blocks, allowing a withdrawal’s block and transaction to be proven as part of that range. Until the burn’s block is checkpointed, the proof needed for the Ethereum release is not ready.
Polygon’s PoS bridge documentation and proof-generation tooling describe this checkpoint-and-proof flow. A proof service or your own integration can use the burn transaction and checkpoint data to assemble the proof. The proof is evidence for the Ethereum contract; it does not itself move the funds.
This waiting period is a useful edge case for status handling. If the Polygon burn succeeded but no checkpoint covers its block yet, show the withdrawal as pending proof generation, rather than failed. Checkpoint timing can vary, so avoid promising a fixed completion time based only on the Polygon receipt.
The Ethereum transaction completes the release
Once the proof is available, a second transaction on Ethereum submits it to the bridge’s exit contract. The contract checks that the burn is covered by a valid checkpoint and has not already been used, then releases the escrowed Ethereum asset to the designated recipient.
That Ethereum transaction requires ETH for gas, even if the Polygon burn used POL for gas. Treat the release as complete only after the Ethereum transaction succeeds and the expected asset transfer is visible in its receipt or the recipient’s balance. Ethereum.org’s proof-of-stake documentation explains why a confirmed transaction and a finalized block are different states; choose the confirmation policy appropriate to the value and risk of your application.
Model the withdrawal as distinct states
For an integrator, the cleanest approach is to persist each stage and make event processing idempotent, so retries cannot credit or release the same withdrawal twice. A compact state model is:
- Burn submitted: the Polygon transaction is pending.
- Burn confirmed: the Polygon receipt succeeded and matches the expected token and recipient.
- Proof ready: a checkpoint covers the burn and the inclusion proof is available.
- Released: the Ethereum exit transaction succeeded and the asset transfer was verified.
For example, if a user’s burn succeeds but your proof worker restarts before the next checkpoint, resume from the stored Polygon transaction hash. Do not ask the user to burn again; retry proof generation when the relevant checkpoint is available. Keep the source and destination chain IDs with the record, since transaction hashes alone are not a safe cross-chain identifier.
The key integration decision is to treat the Polygon burn and Ethereum release as one withdrawal with two independently observed transactions. For the route choice and full treasury-transfer walkthrough, see how Polygon Bridge routes treasury transfers; this post covers the withdrawal lifecycle your application should track after choosing a route.