Polygon's community is scheduled to consider a hard fork proposal at 22:30 Beijing time on Nov. 5 that would remove roughly 70.49 million POL from five blocked addresses linked to recent exploits and assign the same amount to recovery wallets. The proposed on-chain intervention, covering about $6.7 million in POL, would leave the token's total supply unchanged while bypassing the private keys controlling the attacker-linked accounts.
The measure follows separate Oct. 30 compromises involving Polymarket's front end and a Binance hot wallet. Polygon validators blocked the five addresses after the incidents, preventing the POL held there from being transferred. Four addresses associated with the Polymarket incident contain 23.86 million POL, while the address connected to the Binance case holds 46.63 million POL, according to the governance proposal.
Polymarket and Binance are expected to present their cases during the Polygon protocol governance meeting. Community participants will then consider whether the network should move from blocking the assets to changing the balances directly through a coordinated upgrade.
The proposal would change account balances
The distinction between the two steps is central to the decision facing Polygon participants. Validator-level address blocking can restrict an account's ability to submit transactions, but it does not alter the account's recorded ownership of its assets. The balances remain associated with addresses controlled by the holders of the relevant private keys.
A hard fork would take a different route. Under the proposal, the designated attacker addresses would have their POL balances reduced to zero at a specified block, while an equal amount of POL would be credited to recovery addresses selected for the affected parties. No new POL would be created, and no tokens would be burned; the network's ledger would simply assign the existing coins to different addresses.
That design limits the scope of the intervention to five accounts and a fixed quantity of POL. The proposal describes the 70.49 million POL as less than 1% of the circulating supply, a much narrower proportion than some previous blockchain recovery forks.
The blocked accounts have already prevented the alleged attackers from moving the tokens, meaning the immediate question is less about stopping an active transfer and more about whether the network should make the freeze permanent through a state change. A prolonged block could preserve the disputed balances in place without resolving their ownership, while a successful fork would return them to recovery addresses but establish a precedent for protocol-level intervention after security incidents.
Attackers allegedly sought to have addresses unblocked
The proposal states that Polymarket attempted to communicate with the attackers following the front-end compromise but received no response. It also says the attackers contacted Polygon validators and offered cash payments in exchange for restoring the blocked addresses' ability to transact.
That allegation places validators in a sensitive position. Polygon PoS relies on validators to participate in consensus and execute network upgrades, and the episode illustrates how targeted account blocks can turn validator operations into a focal point during a theft response. A hard fork, if approved and adopted by enough network participants, would shift the decision from individual transaction permissions to a public protocol rule implemented across the chain.
The materials state that both Polymarket and Binance had already fully compensated users affected by the respective incidents. The recovery proposal therefore concerns the platforms' efforts to recover assets that were allegedly taken, rather than a plan to distribute funds directly to individual users.
A familiar debate with a smaller financial footprint
The proposal draws a comparison with Ethereum's 2016 response to The DAO exploit, one of the most consequential recovery decisions in blockchain history. Ethereum's community approved a hard fork that redirected approximately 3.6 million ETH from the attacker path to a refund contract. The amount represented roughly 14% of Ethereum's supply at the time and was valued above $50 million.
The decision divided the network. A group of participants continued operating the original chain, which became Ethereum Classic, while the forked chain retained the Ethereum name and the vast majority of its ecosystem. The episode remains the standard reference point for debates over whether blockchains should preserve transaction history under all circumstances or intervene when an exploit produces extraordinary losses.
Polygon's proposal involves a considerably smaller share of supply and targets specific addresses that were already blocked. Yet it raises a related question: whether a network's governance should treat assets linked to an exploit differently from any other balance once they are recorded on-chain.
A more recent precedent came from Core Network after an Oct. 31 incident involving the b14g protocol. Core Network announced a hard fork on Nov. 2 to recover 68,146,177.22 CORE from three attacker-controlled addresses. The network described that amount as 70.2% of the roughly 97 million CORE affected after unauthorized withdrawals from tokens staked through b14g.
These cases show that recovery forks remain technically available to networks with sufficient governance coordination, even if they remain politically contentious. The practical difficulty lies in defining a narrow rule that addresses an identified incident without creating confusion over the conditions under which future balances might also be altered.
Testing would follow an approval
If the Polygon community approves the proposal, developers would spend 14 days building and testing the customized fork code on the Amoy testnet, according to the plan. That process would be intended to confirm that the balance changes execute correctly and that validators, node operators and applications can transition to the upgraded software without disrupting normal network activity.
The test phase would also give infrastructure providers and decentralized application teams a defined window to prepare for the upgrade. For users, the primary operational issue would be whether wallets, RPC providers, bridges and applications serving Polygon PoS remain synchronized as the new software version is deployed.
The Nov. 5 meeting will determine whether Polygon proceeds toward that implementation work or leaves the attacker-linked balances frozen under the existing restrictions.
Worried about hacks and blocked funds? Learn how to recover from a crypto hack and protect your assets.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
