Polygon withdrawals hinge on a proof, not a second bridge

A Polygon PoS withdrawal by proof burns the bridged tokens on Polygon, then uses evidence of that burn to release the original assets on Ethereum. The proof is a Merkle inclusion proof tied to a checkpoint that Polygon validators have submitted to Ethereum.

That makes withdrawal a two-chain process: the burn starts it, but the funds arrive only after an Ethereum transaction submits the proof and calls the bridge’s exit function.

The proof is the bridge between a confirmed burn and an Ethereum claim.

What does the withdrawal proof prove?

It proves that a specific burn event appeared in a specific Polygon block, and that Ethereum has a checkpoint covering that block. The checkpoint commits to a range of Polygon blocks; the proof lets the Ethereum contract verify the burn without replaying Polygon’s transaction history.

For a practical overview of wallet preparation and the user-facing flow, see this guide to setting up a wallet for Polygon Bridge. For an integration, the key inputs are the Polygon burn transaction hash, the matching event and the token event to claim.

How do you integrate a proof-based withdrawal?

Build the flow around the burn transaction, not a guessed wait time. After a user initiates withdrawal, save the Polygon transaction hash and track its receipt until the burn has been included in a checkpoint.

A proof-generation service can check whether the block is checkpointed and return an encoded exit payload. Polygon’s proof-generation API exposes separate checks for block inclusion and payload generation; a team can use the hosted service or run the open-source service itself. The payload contains the proof data expected by the Ethereum bridge contract.

The integration usually follows these steps:

• Submit the withdrawal on Polygon and retain its transaction hash.
• Read the receipt to identify the burn event and its block.
• Wait until that block is checkpointed, then request the exit payload using the transaction hash and event type.
• Ask the user to submit the payload to the Ethereum bridge’s exit function, then monitor the Ethereum transaction for completion.

For a batch transaction, the integration must select the intended matching event; some proof APIs accept a token index for that purpose. Validate the event type and index against the receipt rather than assuming every burn transaction contains just one claim.

How long does it take, and what does it cost?

The burn can be ready before its block is covered by an Ethereum checkpoint, so the user may need to wait before a valid proof can be produced. Poll checkpoint status with backoff and show a pending state; a “not checkpointed” response means to retry later, not to send another burn.

Users pay for a Polygon transaction to burn the asset and an Ethereum transaction to claim it. The proof-generation request itself is not the on-chain claim: the Ethereum exit call consumes gas, and its cost varies with network conditions. The wallet also needs enough ETH on Ethereum to submit that call.

What should you verify before submitting the claim?

Check that the payload came from the recorded burn transaction, the selected event matches the asset, and the destination wallet is correct. A malformed or mismatched payload will fail contract verification; a successful burn alone does not mean the Ethereum-side claim has happened.

For most integrations, the sound design is to automate checkpoint polling and proof retrieval while leaving the final Ethereum transaction visible to the wallet. This keeps the slow checkpoint step separate from the user’s paid claim and makes the status of each chain leg clear.