Polygon PIP: a hard fork to return blocked POL to Polymarket and Binance

A Polygon PoS PIP posted on 4 November 2026 by @Parvez03 asks for a coordinated hard fork that would move about 70.49M POL held in five blocked addresses to recovery addresses designated by Polymarket and Binance, which the PIP names as its proposers. The proposal was scheduled for presentation at the Polygon Protocol Governance Call on 5 November 2026 at 14:30 UTC. It matters because the funds are held by a mechanism that can only stop them, not return them, and because the only way to move a balance without the owner's key is a consensus change.

Both incidents are publicly acknowledged. On 29 October 2026, about 28M POL was involved in an incident at Polymarket, where malicious code from a compromised third-party provider moved assets out of users' accounts; Bubblemaps estimated about $2.7 million taken from roughly 700 users, and Polymarket has said affected traders will be fully reimbursed. Late on 29 October 2026 Binance was hacked, losing around $6.3 billion by its own figure across ten blockchains, Polygon among them. In both cases stolen funds in native POL arrived at addresses on Polygon PoS, and at the request of the affected parties the block producers anonymous-91 to anonymous-94 added those addresses to the Bor transaction block list.

What it changes

• A hard fork at a fixed block F, at the start of block F and before any transaction in it is executed, sets the native POL balance of each listed Class A address to zero and credits the same amount to the recovery address of the presenter for that address.
• The five addresses hold about 70.49M POL: about 23.86M POL across four addresses from the Polymarket incident, with 23,862,736.07 POL listed at reference balances read at mainnet block 96,399,251, and about 46.63M POL in one address from the Binance incident, with 46,626,593.27 POL listed at block 96,413,185. The PIP notes the sum is indicatively US$6.5M at US$0.0924 per POL, spot on 29 October 2026.
• Recovery addresses: 0x3dcE0a29139A851Da1dFCa56Af8e8a6440b4D952 for Polymarket and 0xd9fd39103674cb061d64d9c3b73b878dbe610b80 for Binance.
• Scope is narrow. Only native POL balances in the listed addresses change; other tokens are out of scope; the USDT at the Binance address is already frozen by Tether; Class B addresses are not touched; total supply is unchanged; Heimdall, the StakeManager and the bridge contracts are not changed.
• Each presenter must provide the recovery address in the discussion thread, prove control of it, have that control confirmed by Polygon Labs, and confirm in writing that the address is theirs to receive these funds. Any multisig signers will be published.
• The fork activates only if the PIP is approved through the Polygon governance process, the presenters' post-mortems remain published and consistent with the on-chain record, the block lists on all block producers remain in force until activation, and the Class A balances are re-read at the snapshot block with any change published.
• It is a consensus-breaking change to Bor. All validators, RPC providers, exchanges and node operators must run the new release before block F, and nodes that do not upgrade will follow a different chain from block F. Tools that re-derive balances from transactions, such as explorers, indexers and accounting tools, must handle the balance change at F.
• The fork name, the activation block and the client release are all marked as to be decided once approved.

The case for it

The proposal opens with the size of the problem: "5 attacker-controlled addresses hold about 70.49M POL: about 23.86M POL (4 addresses) from the Polymarket incident and about 46.63M POL (1 address) from the Binance incident." It argues the block list is not an end state: "The block producers’ block list stopped the funds from moving, and no bypass has been found, but it is a stopgap." And it states why the delay matters: "Leaving 70M POL locked indefinitely is neither a stable end-state nor a return of funds to their owners."

The objections

@S1W says the victims probably deserve to recover their funds, but raises the precedent: "If Polygon demonstrates that native POL balances can also be frozen, seized, or reassigned through coordinated network intervention, law enforcement agencies worldwide will inevitably take notice." The same reply asks: "How would Polygon distinguish between legitimate recovery requests and politically motivated asset seizures?" and argues that "Once you demonstrate that native token ownership can be overridden, it becomes much harder to argue that such intervention is impossible in future cases."

@Williamsj043 thanks the authors for stating when this should be treated as an exception, and raises an implementation point: "It may help to publish the activation block and a machine-readable list of the affected addresses and amounts ahead of the release, so integrators can add a special case and reconcile their records."

Where it stands

The thread had four posts as of 8 November 2026: the proposal, a supportive reply from @Just, the implementation point from @Williamsj043 and the precedent objection from @S1W. No vote is recorded in the thread.

The rollout the PIP gives starts after approval: client development and an Amoy deployment and rehearsal, which it says is about two weeks after approval and workable, with one week tight; then notification of validators, RPC providers and explorers, with Polygon validator operations expecting about 70 to 80% of stake to reach the required version quickly after release; then the fork at block F; and after block F the publication of the transaction-free balance change and the verification script. The proposal states it is a response to a specific situation that should not be reproduced commonly.