Polygon’s POL exit claim rests on three address bindings

A Polygon PoS exit claim for the proposed POL distribution depends on one address binding the burn, the Ethereum exit and the payout. PIP-92, a draft dated September 23, describes moving the accumulated staker share from Polygon PoS to Ethereum, then into the StakeManager; the draft is not proof that those transfers occurred.

Why does this exit use Plasma?

The draft says native POL is not mapped in the PoS bridge’s RootChainManager, so the distribution cannot leave through that contract’s mapped-token exit. Instead, the proposal uses the Plasma withdrawal path for the native token: the holder calls withdraw(X) on Polygon’s native POL contract, address 0x0000000000000000000000000000000000001010, with X POL as the transaction value. That burns the POL and emits a Withdraw event.

This is distinct from the mapped-token route commonly meant by the Polygon Bridge’s Ethereum-to-Polygon transfer mechanism. A burn receipt must first be included in a checkpoint; the Ethereum exit then proves that receipt. The exit claim is a two-chain proof-and-release process, not a direct transfer from the Polygon token contract to Ethereum.

Which three addresses must line up?

The proposal’s route binds the Polygon burner, the Ethereum exit caller and the Ethereum payout recipient to the same address. The first binding starts with the address holding the POL: that account calls withdraw(X) on Polygon. The second is enforced when the same address calls startExitWithBurntTokens on Ethereum’s Plasma ERC20 predicate with the burn receipt proof. The predicate requires the caller to match the burning address.

The third binding is the exit recipient. The draft says the exit pays to the Ethereum address equal to the Polygon burning address. It identifies the fee-collection account as a Safe deployed at the same address on both networks, with the same signers and three-signature threshold. In the proposal’s account, therefore, the address that authorizes the Polygon burn is also the address that can submit and receive the Ethereum exit.

• Burn: the Polygon fee-collection Safe calls withdraw(X) on the native POL contract.
• Submit: that same address calls startExitWithBurntTokens on Ethereum with proof of the burn receipt.
• Receive: the Plasma exit releases POL to the corresponding Ethereum address, from which it can be transferred to the StakeManager.

These are protocol address checks and a stated custody arrangement, not proof that the signers are the same people or that the planned transactions succeeded. A Safe at an identical address on two chains has the same address value; the draft separately claims its signers and threshold match.

What happens after the burn is proven?

Once the burn is checkpointed, the exit is started through the Plasma ERC20 predicate and processed by the Ethereum WithdrawManager’s processExits. The draft says the current HALF_EXIT_PERIOD is one second, making the exit processable almost immediately. The DepositManager pays native-token exits in POL. After receipt, a plain ERC-20 transfer sends the amount to the StakeManager proxy; the draft says no StakeManager function call is needed to fund its balance.

The amount in PIP-92 is 27,334,955.845734223717311595 POL, described as the accumulated staker share through Polygon PoS block 93,430,949. The proposal then uses the existing checkpoint reward path to distribute that balance: it proposes raising CHECKPOINT_REWARD for a temporary window, with rewards credited through checkpoints rather than individual claim contracts. That parameter change controls distribution; the bridge exit only moves the POL that funds it.

The distinction matters for verification. A draft can specify the expected source account, proof path, recipient and amount, but completion requires the Polygon burn receipt, the Ethereum exit processing and the transfer into the StakeManager to be visible on-chain. The draft says transaction hashes will be published and makes confirmation of StakeManager receipt a prerequisite to the reward increase. Until those records establish each step, the address bindings describe the proposed control path, not a completed distribution.