Polygon proposal targets 70.49 million POL: what recovery would require

What the 70.49 million figure measures

The proposal groups four Polymarket-related addresses with one Binance-related address. Its reference balances total 23,862,736.07 POL for the former and 46,626,593.27 POL for the latter. Adding those figures gives 70,489,329.34 POL, rounded to 70.49 million. These are the document's reference balances; a final snapshot is one of its activation conditions.

That scope matters for anyone comparing incident headlines. The number describes native POL in the listed addresses. It is not a measure of every asset affected by either incident, nor a statement about either company's total loss. In the Binance address, the proposal separately identifies USDT that it says Tether has frozen. The proposed balance transfer covers native POL only.

The source values appear in the proposal's address tables. Its indicative dollar valuation is about $6.5 million, using a POL price of roughly $0.0924 on 29 October. That dated conversion is not a current POL quote. The quantity of tokens is the useful measure when assessing the scope of the proposed operation; a dollar headline would need to retain the valuation date.

The two reference groups also use different snapshot blocks. The Polymarket table cites block 96,399,251; the Binance table cites block 96,413,185. The document requires the balances to be read again and any change published before activation. Readers should therefore distinguish the published reference total from the eventual balance an approved implementation might move.

Why blocking an address has not returned the funds

According to the proposal, Polygon PoS block producers added the relevant addresses to their transaction block lists at the affected parties' request. The author says this stopped the funds from moving, while leaving no mechanism in the current arrangement to return them. That is the reason the document asks for a consensus change.

The proposal describes the existing filter as operationally limited. Each block producer reads its list at startup, changes require a deployment and restart or span rotation, and entries have no automatic expiry. The filter covers outer senders and EIP-7702 authorities. Those details are the author's explanation of the current control and its limits, rather than our independent test of every possible transfer route.

For a user waiting for an incident update, a successful block and a completed recovery answer different questions. A block concerns whether particular funds can move under the current arrangement. Recovery concerns where the balance goes next and who controls the receiving address. Neither statement, on its own, establishes that a customer's exchange account has been credited.

The document's proposed receiving addresses belong to the two presenting parties. It does not set out an individual-customer claim process or a timetable for account credits. A user with a pending deposit or withdrawal should keep the transaction hash and the account's own status record. The aggregate POL amount cannot answer whether that particular transfer is included.

SponsoredBinance

Partner rebate share25%Up to

Check regional eligibility and account terms

✓Code applied automatically by the sign-up link: 11350287

Sign up on Binance →Code11350287Copied

How the proposed transfer would work

The proposal calls the future activation block F. Before any transaction in F executes, the proposed rule reads each listed Class A address's balance from the end of the preceding block, sets that address's native POL balance to zero, and adds the same amount to its designated recovery address. The document explicitly labels this a proposed design requiring confirmation by Bor engineering.

Under that design, total POL supply remains unchanged. The operation reallocates existing balances. The proposal says it would leave Heimdall, the StakeManager and bridge contracts unchanged, and would not change state before the activation block. Those boundaries describe the requested implementation; they are not evidence that a release containing it is available.

The distinction between Class A and Class B is especially relevant. The balance-moving rule applies to the addresses in the specified Class A tables. Class B addresses are not swept. The author discusses attribution risk as a reason for that narrower scope, rather than asking for a general power to move funds from every address connected to the incidents.

A technical choice remains open in the rationale: it mentions a fixed-amount alternative to the full-balance approach. The submitted design reads the balance immediately before activation. That means a later credit to a listed address could affect what moves. The final snapshot and engineering review are therefore substantive parts of the process, not administrative labels.

What has to happen before activation

The forum proposal lists approval through Polygon governance as a condition. It also requires the presenters' post-mortems to remain published and consistent with the on-chain record, the block lists to remain in force, and the Class A balances to be checked again. These requirements must hold at the final vote and at the Amoy test-network sign-off.

Receiving-address verification is another separate step. Each presenter must provide its address in the discussion, prove control through a signed message or a small test transfer confirmed by Polygon Labs, and confirm in writing that the address is its own. Publishing an address in a proposal is therefore only part of the proposed verification process.

The timeline begins with the protocol governance call at 22:30 SGT on 5 November, equivalent to 14:30 UTC. Development and an Amoy rehearsal would follow approval. The author describes about two weeks after approval as workable and one week as tight. Those are estimates in the proposal, not an activation deadline or a promised return date.

Before mainnet activation, the document calls for notifications to validators, RPC providers and explorers. It says validator operations expects roughly 70% to 80% of stake to reach the required version quickly after release. That expectation is not a measurement of upgraded stake today. The activation block and release version remain fields to be decided after approval.

Why a POL holder should watch the implementation details

The proposal identifies chain-split risk: nodes that do not upgrade would follow a different chain from block F. It proposes advance notice, an Amoy rehearsal and confirmation of stake coverage as mitigations. Ordinary holders should watch for an actual approved release and dated service notices if the process advances, rather than treating the discussion's meeting time as a network switch.

The balance change also has an accounting consequence. Because it would happen without a normal transfer transaction, the proposal says explorers, indexers and accounting tools that reconstruct balances from transactions must handle the exceptional change at F. A later recovery claim should therefore be assessed against the published verification record, rather than judged solely by the presence of an ordinary transfer entry.

For an existing Binance deposit or withdrawal, open that transfer record and save its current status, transaction hash, asset and network label together. Compare any later service update with that specific record before treating it as confirmation of receipt. This proposal concerns native POL on Polygon PoS. Its scope does not establish the state of another token, another network or an internal exchange balance. An incident headline naming Binance cannot replace the status of a particular deposit or withdrawal in the account.

A purported recovery message deserves the same precision. The opened proposal describes institutional recovery addresses and governance conditions. It supplies no customer application page asking users to send funds or reveal a wallet recovery phrase. Do not follow an unsolicited compensation link or direct message; check the affected service's own status channel and retain the original transaction details.

The precedent is part of the decision

The proposal calls moving a user's balance the most sensitive action that can occur on a chain. It argues for a closed address list, a one-time rule at a named block, and conditions tied to the two incidents. It explicitly rejects a permanent freeze-and-recover mechanism as an alternative because that would create an ongoing power over user funds.

Its other alternatives include leaving the tokens locked and seeking a negotiated return from the attacker. The author argues that indefinite blocking depends on a stopgap mechanism and says Polymarket has already attempted an on-chain recovery contact without receiving a response. These are reasons advanced by the proposer; they do not settle the governance decision.

For readers assessing the plan, the difficult question is whether those limits are sufficiently specific and verifiable. Approval would need to address attribution, receiving-address control and implementation behavior. The reference amount explains the size of the proposed intervention, while the conditions explain who would authorize it and how a mistake could be detected.

Quick answers

Has Polygon recovered 70.49 million POL already?

The opened sources establish a proposal and its proposed process. They do not establish an approved activation block, a released client or a completed balance movement. The headline amount is the approximate scope of the requested recovery.

Would the proposal create additional POL?

The submitted design credits the same amount that it removes from the listed addresses, leaving total supply unchanged. Engineering confirmation and governance approval remain necessary before that design could become an active rule.

When would affected customers receive funds?

The document contains no individual-customer payment schedule. Watch the governance decision first, then the approved implementation, the final address verification and evidence of execution. Any account credit would need its own confirmation from the affected service.