Polygon wants to move 70 million POL without the wallet holders’ signatures

Polygon's proposed recovery of roughly 70 million POL would move coins out of five hack-linked wallets without their holders signing a transfer. The plan would change balances through the network's rules, putting the authority to return stolen funds in the hands of governance and validators.

The November 4 proposal targets five addresses it links to stolen funds from security incidents affecting prediction market Polymarket and exchange Binance. Its dated reference tables attribute about 24 million POL to four Polymarket-linked addresses and 47 million POL to one Binance-linked address. The actual recovery would use balances at activation, not these dated reference amounts.

As of November 9, the published proposal still leaves the recovery fork's name, client release and activation block undecided. The November 5 governance agenda lists the proposal for discussion without recording approval. The separate Bor v2.11.0 release implements Uburu's StateReceiver changes, rather than this proposed recovery.

Who can authorize Polygon's recovery?

Under the proposed design, the upgraded software would read each listed address's balance immediately before activation, set it to zero and credit the same amount to the designated recovery address. This would happen before transactions execute in the activation block. Total supply would stay the same, and earlier chain history would remain intact. The proposal says Bor engineering must still confirm the design.

How the proposed POL recovery would work

A single protocol rule would move native POL from five listed accounts to two company-designated recovery addresses. Approval and recipient verification remain conditions.
FIVE LISTED ACCOUNTSTWO DESIGNATED RECIPIENTSPolymarket-linked4 source addressesBinance-linked1 source addressIF ACTIVATEDBlock FOne-time rulePolymarketrecovery addressBinancerecovery addressFull native POL balances at F−1, including deposits credited by then.
FIVE LISTED ACCOUNTSPolymarket-linkedBinance-linked4 addresses1 addressIF ACTIVATEDBlock F: one-time rulePolymarketrecovery addressBinancerecovery addressFull native POL balances at F−1.Includes deposits credited by then.

Inspect the proposed activation boundary

Inspect the proposed activation boundaryImmediately before FIf the rule executes at F
The rule would read each listed account's full balance from F−1. The recovery credit has not executed.
5 source accountsFull POL balancesRead from the end of F−1Recovery recipientsNo credit from this ruleRecovery has not executedF is not yet specified. This is the proposed activation sequence.
5 source accountsFull POL balancesRead from the end of F−1Recovery recipientsNo credit from this ruleRecovery has not executedF is not yet specified.Proposed sequence only.
Before ordinary transactions in F, the five source balances would be zero and the designated recipients credited by the same amounts.
5 source accounts0 POLAfter proposed sweepRecovery recipientsSame amounts creditedBefore F's transactionsSupply and earlier history would stay unchanged.
5 source accounts0 POLAfter proposed sweepRecovery recipientsSame amounts creditedBefore F's transactionsSupply and earlier historywould stay unchanged.

The proposed recovery changes balances at one block, so custody records need a separate adjustment.

Governance approval, recipient-control checks and Bor engineering confirmation are required. The activation block and recovery release remain undecided as of November 8.
Sources and evidence

Sources

1. Polygon recovery proposal, November 4
2. November 5 governance agenda

Supporting facts

• Polygon's November 4 recovery proposal seeks a one-time hard fork moving native POL balances from five specified addresses to recovery addresses designated by Polymarket and Binance. [1]
• The proposed full-balance rule would read each target's balance after block F-1, zero it before transactions execute in block F, and credit the corresponding recovery address by the same amount, leaving total supply unchanged. The proposal says Bor engineering must still confirm this design. [1]
• As retrieved November 8, the recovery proposal still leaves its fork name, client release and activation block undecided, and the November 5 governance agenda records it as a discussion item rather than documenting approval. [1] [2]
• The proposed recovery would leave pre-activation history unchanged; explorers, indexers and accounting tools that reconstruct balances from transactions would need to account separately for the change at the fork block. [1]
• The proposal requires each recipient to prove control, for example with a signed message or test transfer confirmed by Polygon Labs, and confirm ownership in writing before activation. [1]
• The proposed activation conditions include governance approval, consistent published postmortems, continuing blocklists, and refreshed Class A balances with changes published. [1]
• Under the proposed full-balance rule, POL deposited into a listed address before activation would also move to the designated recovery address. [1]
• The proposal calls for Amoy tests of supply preservation and unchanged unrelated accounts, a mainnet-fork replay, and publication of the transaction-free balance change and a verification script after activation. [1]

Method

Schematic of the published proposed full-balance rule. Account markers show address counts, not relative POL amounts. The panel compares successive steps of the proposed activation sequence; it does not depict observed recovery.

Scope

Governance approval, recipient-control checks and Bor engineering confirmation are required. The activation block and recovery release remain undecided as of November 8.
Infographic by CryptoSlate

That would place recovery authority in a combination of governance approval, the specified address list and the software rule validators adopt. The affected companies would designate the recipients. Polygon Labs would confirm the proposed proof of recipient control. The proposed sweep would not require a transaction signed by the source addresses.

Those are separate responsibilities. Tracing stolen coins to an address supports the case for including it; proving control of a recovery address checks where the coins would go. The proposal itself warns that misidentifying an attacker-controlled address could move a legitimate balance.

Its recipient-verification requirements call for proof of control, such as a signed message or small test transfer confirmed by Polygon Labs, plus written confirmation that the address belongs to the recipient. The proposal also excludes other tokens and a separate category of blocked addresses, limiting the proposed sweep to native POL at the five listed accounts.

The full-balance rule creates another ownership question: later deposits would move too. The proposal requires balances to be checked again before activation and any changes to be published.

Those checks would disclose which coins the sweep includes, but would not establish that every later deposit belonged to an incident victim.

A recovery that accounting systems can see

For exchanges and custodians, the proposed movement would create a difference between the balance shown by an upgraded node and the balance reconstructed solely from ordinary transactions. The proposal explicitly flags this problem for explorers, indexers and accounting tools.

A reconciliation would therefore need to connect each affected source address, its balance before activation, the designated recipient and the corresponding credit at the activation block. For custodians, the rule implies a separate balance adjustment, since there would be no ordinary transfer transaction to match against it.

The planned checks address part of that burden: an Amoy rehearsal would test that supply stays constant and unrelated accounts remain unchanged, followed by a mainnet-fork replay. The proposal also calls for publishing the transaction-free balance change and a verification script after activation. Together, those records would let operators compare the implemented change with the approved scope.

Customer reimbursement is a separate process. In its October 30 postmortem, Polymarket said 95% of affected wallets had been refunded in full that afternoon and announced $4 million being returned, including $1 million for pause-related losses. Those refunds compensate traders; the proposed fork would return assets to company-designated recovery addresses.

The next recovery milestone would require a governance decision, a final software specification, verified recipients and an activation block.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.