Polygon Weighs Hard Fork to Return 70.49 Million POL to Recovery Wallets

A proposed recovery through a network upgrade

Polygon is considering a hard fork to move about 70.49 million POL associated with separate security incidents involving Polymarket and Binance. The proposal would alter balances held by five attacker-controlled addresses and credit matching amounts to recovery wallets designated by the two platforms. It is not yet an approved or completed recovery: the change would require a coordinated network upgrade and support from Polygon PoS validators.

The incidents occurred on October 29 and 30. The amount linked to the Polymarket incident is roughly 23.86 million POL, while another 46.63 million POL is connected to Binance. Polygon’s proposal treats the assets as separate platform-related recoveries, assigning four of the five listed addresses to Polymarket and one to Binance. The proposed transfers would take place at a fixed block height rather than through ordinary transactions initiated by the address holders.

If approved and implemented, the upgrade would set the balances of those five addresses to zero and credit the corresponding POL to verified recovery addresses. That design would move the tokens despite their current placement in addresses that cannot make transfers under the existing block-list arrangement. Polygon says the balances are presently blocked, but the measure under consideration is meant to provide a route to return them, not simply maintain the restriction.

Why the current address blocks are not enough

After the affected platforms requested action, all validator-elected block producers added the identified addresses to their Bor transaction block lists. This stopped the listed funds from moving, but Polygon describes the measure as a stopgap. In other words, the current intervention constrains transfers without changing ownership balances or directing the assets to the recovery wallets. The proposed fork would make that separate, more consequential change.

Polygon says the block lists are read when a block producer starts up, so updating them requires a deployment and a Bor restart or span rotation. That operational requirement makes the mechanism less straightforward to maintain as a lasting solution. The proposal therefore frames the existing filter as limited rather than as a permanent recovery system. A hard fork, by contrast, would encode the balance changes at a specified block height if it clears the required process.

The network also cited limits in the filtering mechanism: it does not cover every possible transaction path, leaving room for potential attempts to bypass it. Polygon pointed to an attempted transaction involving a fee of around 219,450 POL, as well as an alleged approach to validators offering cash in exchange for help unblocking a transaction. These details help explain the concern with relying solely on address-level blocking, but the source does not establish that either episode succeeded.

Scope, safeguards and excluded assets

The recovery wallets are an important condition of the plan, not an automatic destination selected by the network. Polymarket and Binance would each have to prove control of their respective recovery address and confirm in writing that they are authorized to receive the funds. Those checks are intended to establish that the proposed recipients are the platforms’ designated wallets before the balances are changed. The source does not say that these proofs have already been completed.

The proposal is limited to native POL held at the five listed addresses. It does not cover other tokens, even when they are connected to the same incidents. In particular, Binance’s stolen USDT is already frozen by Tether, and Polygon says the planned fork would not touch it. The distinction matters: the stated 70.49 million POL recovery is not a proposal to recover every asset associated with the incidents.

Polygon characterizes the intervention as an extreme measure and says it should not become common practice or create a general mechanism for freezing and recovering user funds. That caveat sets a boundary around the proposal: it is presented as a response to these identified balances and platform requests, rather than a routine power to rewrite account balances. At the same time, the proposed action would directly change balances through a coordinated network upgrade.

Governance and implementation still lie ahead

Before any mainnet change, the proposal must pass Polygon’s governance process, be developed and tested on Amoy, and receive the required validator support. The steps mean that the recovery plan remains conditional, with governance, technical preparation and validator approval still ahead. The source gives no completed vote, test result, approval date or mainnet implementation date, so it does not establish when, or whether, the transfer will occur.

For the affected platforms, the proposal offers a possible path from immobilized POL to designated recovery wallets, but only if the stated checks and network approvals are satisfied. For validators and block producers, it involves deciding whether to support a coordinated upgrade that changes specific balances, after an existing block-list response proved insufficient as a return mechanism. No outcome is reported, and the proposal alone does not mean the platforms have received the assets.

The key distinction is between preventing movement and recovering funds. Polygon says its Bor block lists have constrained the five addresses, yet they do not transfer tokens back; the hard fork would attempt that next step for about 70.49 million native POL. The plan’s limits are explicit: only the five listed balances are covered, USDT is excluded, and governance, Amoy testing and validator support remain prerequisites. Those unresolved steps determine whether the proposed recovery reaches mainnet.

Source: CryptoPotato