Why Polygon Bridge Claims Match the Burned Amount

On Polygon’s PoS bridge, the amount claimed on Ethereum is tied to the amount recorded when the Polygon token is burned. A withdrawal does not simply copy a wallet balance across chains: the bridge verifies a specific Polygon transaction, then uses its recorded transfer amount to release the corresponding asset held on Ethereum. That link between burn and claim is the accounting rule behind the match, while the checkpoint and claim steps explain why the return journey takes longer than a deposit.

The distinction matters because “burned” and “claimed” describe separate events on separate networks. Polygon Support describes the standard route as locking tokens on Ethereum when they are deposited to Polygon, then burning the Polygon representation when they return. For a fuller explanation of the Polygon Bridge burn-and-claim process, the key point is that the burn provides the evidence for the later release; it is not itself an Ethereum transaction.

Why does the Ethereum claim match the Polygon burn?

The claim matches because the bridge checks a proof of the burn transaction and processes the amount in its event data. Polygon’s proof-generation repository describes a withdrawal as two steps: burn the asset on Polygon, then submit an exit on Ethereum that verifies the burn. For a standard ERC-20 withdrawal, the relevant log is a Transfer event to the zero address; its amount is part of the transaction receipt used to build the proof.

That proof connects the claim to a particular Polygon block and receipt. Polygon’s repository explains that the burn must be included in a block covered by a checkpoint submitted to Ethereum. Once that condition is met, the exit proof lets the Ethereum bridge contract check the event against the checkpoint before releasing funds. The amount is therefore not an estimate based on a user interface, a token price, or a wallet’s current balance. It is part of the on-chain record being proven.

In the standard mapped-token route, an Ethereum deposit locks the original tokens and issues the corresponding representation on Polygon. On the return trip, burning that representation authorizes the release of the escrowed tokens. The amounts are intended to match in token units, though their dollar values can move while the withdrawal is pending. Gas costs are separate: they pay for the transactions and do not change the token amount recorded in the burn event.

What happens between burning and claiming?

After the burn, the withdrawal waits until the relevant Polygon block is covered by an Ethereum checkpoint. The proof-generation repository describes the next step as building an inclusion proof from the transaction receipt and the checkpoint that covers its block. The user then submits the exit on Ethereum, where the bridge verifies the proof and releases the asset.

This sequence explains why seeing a successful Polygon transaction does not necessarily mean the Ethereum funds have arrived. The burn can be final on Polygon while the withdrawal still awaits a checkpoint or a separate claim transaction. Polygon Support’s explanation of the native bridge also distinguishes the burn from the later unlock on Ethereum.

The practical checks follow from those stages:

• Confirm the source transaction is a withdrawal burn for the intended token and amount.
• Check whether the Polygon block is covered by a checkpoint; an uncheckpointed burn is not yet ready for the exit proof.
• Look for a successful Ethereum claim transaction before treating the withdrawal as complete.
• Compare token addresses and units on both networks, since a matching symbol alone does not establish that two tokens are the mapped pair.

A displayed amount can also look different without changing the underlying claim. Tokens may use different decimal displays, and wallets may format small fractions or hide token balances until the relevant asset is visible. The useful comparison is between the token contract and amount in the Polygon burn record and the token released by the Ethereum claim, not between rounded screen values.

When might the amounts not match exactly?

The one-to-one explanation applies to the standard bridge route and correctly mapped tokens; it is not a rule that every cross-chain product must follow. Some alternative bridges use liquidity pools or relayers, which can deliver assets from reserves and may deduct a fee or quote a different receive amount. In those systems, the source action and destination payout are connected by that bridge’s own accounting and validation rules.

Even within a lock-and-burn design, token behavior matters. A fee-on-transfer token, rebasing token, or custom contract can make the amount a bridge expects differ from the amount actually received or burned. A ChainSecurity assessment of Polygon’s PoS Portal notes the general risk that a bridge can record the requested transfer amount when a fee-on-transfer token delivers less. This is why support and mapping for the specific asset matter; the bridge’s standard accounting should not be assumed to handle every token design.

For a typical withdrawal of a supported Polygon PoS asset, the burn record is the anchor: its verified amount determines the corresponding release, while the checkpoint and Ethereum claim provide the proof and execution. The trade-off is a slower, two-stage return compared with routes that pay out from liquidity, but the claim can be traced to a specific burn and checked against the bridge’s escrow. The next signals to watch are whether the burn is checkpointed, whether the exit transaction succeeds, and whether the released token contract and units match the source record.