Polygon Proposes Moving 70 Million POL Without Wallet Signatures

By Tom Whitfield

Polygon proposes moving 70 million native POL from five listed addresses to company-designated recovery addresses without source-wallet signatures, according to the recovery proposal.

The design remains conditional: governance must approve it, validators must adopt the software, Polygon Labs must verify recipient control, and Bor engineering must confirm the design. The activation would alter balances without creating ordinary transfers from those five addresses.

How would the software reset the balances?

Immediately before activation, upgraded software would read each listed address’s POL balance, set it to zero and credit the same amount to its designated recovery address. Those changes would execute before transactions in the activation block. Total POL supply would remain unchanged, and Polygon’s earlier chain history would remain intact.

Unlike a conventional transfer, the mechanism would need no signature from the source address. The result would resemble an accounting allocation rather than a holder-authorized payment.

Who would authorize the recovery?

Authority would rest across three layers: governance approval, inclusion of each address on a specified list, and adoption of the software rule by validators. Affected companies would designate the recovery recipients, while Polygon Labs would confirm proof that those recipients control the addresses.

Tracing stolen coins to an address would support adding it to the list. Separately, proving control of a recovery address would establish where the transferred balance would go. The proposal warns that misidentifying an attacker-controlled address could move a legitimate balance.

How would recipients be verified?

Recipient checks would require evidence of control, such as a signed message or a small test transfer confirmed by Polygon Labs. The process would also require written confirmation that each recovery address belongs to its recipient.

Only native POL at the five listed accounts would fall within the proposed sweep. The proposal excludes other tokens and a separate category of blocked addresses, limiting the sweep to those five native-token balances.

What happens to later deposits?

Because the rule resets the full balance, any later deposit to a listed address before activation would also move to its recovery address. The process would check balances again immediately before activation and publish any changes.

Those checks would reveal which coins the sweep includes. They would not prove that every later deposit belonged to an incident victim, leaving a gap between wallet mechanics and loss attribution.

Why would accounting systems need reconciliation?

For exchanges and custodians, upgraded-node balances would differ from balances reconstructed solely from ordinary transactions. The proposal flags the mismatch for explorers, indexers and accounting tools, which would need a reconciliation outside normal transfer history.

Each reconciliation would connect the affected source address, its balance before activation, the designated recipient and the corresponding credit in the activation block. Custodians would need a separate balance adjustment because no ordinary transfer transaction would exist to match.

How would the upgrade be tested?

An Amoy rehearsal would test two properties: total supply would stay constant, and unrelated accounts would remain unchanged. A mainnet-fork replay would follow the Amoy test.

The proposal also calls for publishing the transaction-free balance change and a verification script after activation. Operators could compare those outputs with the approved scope and address list.

How do trader refunds differ from fork recovery?

Customer reimbursement already follows a separate process. In an October 30 postmortem, Polymarket said 95% of affected wallets had been refunded in full that afternoon and that $4 million was being returned, including $1 million for pause-related losses.

Those refunds compensate traders. The proposed software change instead sends assets to recovery addresses designated by affected companies, leaving exchange accounting and customer reimbursement as distinct operational workstreams.

What must happen before activation?

Activation still requires four elements: a governance decision, a final software specification, verified recipients and an activation block. Until those steps are complete, the proposed 70 million POL transfer would remain unimplemented.

Success would depend on validators implementing the approved scope without changing balances outside the five accounts. The next checkpoint is governance approval, after which recipient verification and software testing must precede any activation block.