How Polygon would return 70 million stolen POL to recovery wallets
Two thefts left millions of POL in five blocked addresses. A Polygon proposal would move those balances into recovery wallets by changing the network’s rules at a specific block. Getting the tokens there would resolve one part of the recovery. Getting them back to customers is a separate job.
- The proposed Polygon fork would recover about 70.49 million POL from five blocked addresses, with 46.63 million tied to Binance and 23.86 million to Polymarket.
- Polygon block producers restricted transfers from the addresses after the October incidents, but the balances remained in place and the filter had limited coverage.
- At the proposed activation block, upgraded software would read the preceding block’s balances, debit the listed addresses and credit designated recovery wallets.
- Tether separately froze the USDT sent alongside Binance’s stolen POL, leaving the fork proposal focused on native POL rather than both assets.
- Recovery wallets would receive the tokens first. Customer reimbursements would depend on each platform’s claims process and treatment of any payments already made.
A Polygon improvement proposal has identified 70.49 million POL across five blocked addresses that a coordinated hard fork could move to recovery wallets designated for Binance and Polymarket.
The proposal describes a change to native POL balances at a fixed block. The software would zero the five listed balances and credit the corresponding amounts to verified recovery addresses.
The distinction is between a balance the network has prevented from moving and one a recovery team can control. For customers, there is a further distinction between tokens reaching a recovery wallet and a platform recognising and paying a claim.
How the two incidents add up
The proposal assigns 46.63 million POL in one address to the Binance incident and 23.86 million across four addresses to the Polymarket incident. Adding those rounded figures gives 70.49 million POL. Dividing each by that total puts Binance’s share at about 66.2% and Polymarket’s at 33.8%.
Those are shares of the proposed recovery, not measures of the two incidents’ total losses. A dollar estimate also depends on the timestamp and price used. The quantities in the proposal are denominated in POL.
The addresses matter more than the headline dollar figure
The proposal’s reference balances total 70,489,329.34 POL. The Binance address accounts for 46,626,593.27 POL, while the four Polymarket addresses account for 23,862,736.07 POL. Those are balances at reference blocks chosen by the authors. The earlier transfer from a Binance hot wallet was slightly smaller than the balance subsequently recorded at the recipient address.
A four-token difference on a transfer of more than 46 million would barely change the headline. It matters to an implementer because there are two possible numbers to encode: the amount traced from the sender and the full balance at the destination. The proposal describes the latter as the amount to read from the state immediately before activation, with a preceding snapshot to be published so changes are visible. The draft should therefore be read as a procedure for determining the final amount, alongside a table that establishes the approximate amount under discussion.
The Polymarket figure presents a separate measurement problem. The proposal puts the incident at about 28 million POL and the four selected balances at roughly 23.86 million POL. Against that rounded incident estimate, the selected amount represents roughly 85%, leaving a difference of approximately 4.14 million POL. That subtraction measures the gap between the incident estimate and the selected balances. It cannot establish where the remaining tokens ended up or whether some could be recovered through another route.
A dollar conversion adds another variable. At $0.092 per POL, the reference balance would be worth about $6.49 million. At $0.096, the same tokens would be worth about $6.77 million. The calculation multiplies the proposal’s reference quantity by two illustrative prices. It explains how dollar figures near $6.5 million and $6.8 million could describe nearly the same proposed transfer. The initial coverage put the value around $6.5 million. A payment decision would need an explicit valuation date and price source.
What the proposed fork would leave behind
The proposed recovery covers about 85% of the roughly 28 million POL attributed to the Polymarket incident in the forum post. It is tempting to describe the remaining 15% as an amount the fork would fail to recover. The more precise comparison is between an approximate incident figure and the balances the authors say are still held at four addresses. A separate tracing exercise would be needed to account for the difference.
The Binance comparison is different. The proposal identifies one transfer of 46,626,589.6 POL from a hot wallet and a balance of 46,626,593.27 POL at the recipient when the reference snapshot was taken. The destination balance was roughly 3.67 POL larger than that transfer. The difference is small enough to disappear in any rounded headline, but it helps explain why a snapshot taken at a specified block is more useful than quoting an amount from the original transaction.
A second lesson lies in the units. The reference table uses native POL, while the earlier Binance transfer also included 6,185,900.1 USDT. A dollar total that includes both would cover a different set of assets from the proposed fork. A report about money blocked could reasonably discuss both, provided it makes clear which organisation took each action and whether the funds subsequently moved.
The two cases also share an activation mechanism without sharing a single account. Polygon software would credit separate recovery addresses, preserving the distinction between the balances assigned to each incident. The recipients would therefore be able to reconcile what they received against their own claims and compensation records. The forum post does not combine the claims arising from the two incidents or give one platform authority over the other’s proceeds.
What a blocked balance can tell us
A block can prevent a listed address from transferring funds while the balance still appears on the chain. An observer can see how much remains at an address without being able to determine how much any individual customer is owed.
The five balances define the scope of this proposal. An asset involved in either incident but outside those balances would need its own recovery route.
What the transfer record can establish
The proposal describes two native transfers at 18:30:34 and 18:35:59 UTC on 29 October. Together they moved 3,282,275.71 POL from one address to another. Two timestamps matter because they help establish the sequence in which balances spread across wallets. The transaction history can show movement and amounts even when the people controlling the keys are harder to identify.
The proposal links the listed addresses to the incidents. For an independent check, a reviewer would need to follow the named transaction records and compare the source addresses with the accounts identified by the affected platforms. That is more specific than seeing several wallets move money on the same day. It is also distinct from proving a legal claim to every coin still in an account.
An address that held native POL and a stablecoin can illustrate the limits of wallet-level language. The stablecoin’s issuer can act through the stablecoin contract. Native POL is part of the network’s balance accounting. The two assets share an address, but the people who can prevent transfers, and the mechanism they can use, depend on what the asset is.
The proposal describes further addresses supplied by Binance as Class B. They belong to the blocking discussion, while the draft’s state changes are limited to the Class A addresses specified for recovery. Counting every blocked address as a wallet that would be emptied would overstate the scope. It would also obscure an important governance question: blocking a transaction is one action, while deciding that a specific balance should go to a named recipient is another.
Why two assets required different responses
The Polygon proposal’s chronology traces 46,626,589.6 native POL and 6,185,900.1 USDT from a Binance hot wallet to the same recipient in block 96,406,484. Tether froze the USDT. The POL remained the subject of the proposed network intervention.
The proposed transfer addresses the different controls available over those two assets. An issuer can impose restrictions through the system it operates for its token. In this case, Polygon’s block producers instead used a Bor transaction filter for native POL, and the proposal describes that filter as a stopgap.
Each block producer reads the list at startup, according to the proposal. Changes require deployment and a restart or rotation, and the filter covers outer senders and EIP-7702 authorities. The proposal says the snapshot will be reread before activation, so its published table is a reference rather than a guarantee of the final debit amounts.
Why a transaction filter can hold for days and still be temporary
The block producers’ list relies on software configuration. The proposal says the list is read at startup. A new entry therefore needs an operational change, and operators need to apply the same configuration if the restrictions are to work as intended. The effort involved can be justified during a live incident, when each hour gives a person holding the keys another chance to move funds.
A restriction at the producer layer also has to match the way a transaction can be authorised. The proposal says the filter covers outer senders and EIP-7702 authorities. That is a narrower claim than saying the funds have been rendered impossible to move under any conceivable transaction path. What the authors report is that the funds were stopped and that they had found no bypass. They identify limits in the approach as part of their case for a more durable change.
The authors describe a pending transaction carrying an unusually large proposed fee and attempts to secure assistance from validators. An attempted transaction is evidence of an effort to change the status of the balance. It carries a different evidentiary weight from an executed transfer. The proposal also describes an unanswered onchain recovery channel. A negotiated return would have depended on a response from a party able to authorise payment, while the fork proposal would work through participants adopting new rules.
An indefinite list has practical consequences for the people administering it. They would need to know which entries still serve a purpose, how new operators obtain the correct configuration and who is responsible for reviewing old entries. The forum proposal envisages a review after the recovery, including distinct handling for the additional addresses. That means the proposal concerns both a one-time balance change and what happens to the temporary controls around it.
What changes at the fork block
Normally, a transfer changes account balances after a valid transaction is accepted under the network’s rules. The proposal instead asks software following the upgraded rules to apply the listed debits and credits as part of processing a specified block.
The matching credits matter. The operation as described takes the same number of native tokens from the listed addresses as it gives to the designated recovery addresses. The scope does not extend to arbitrary tokens in the wallets.
The block that would record the recovery
The proposed state change is ordered around the activation block, which the draft calls F. The relevant amount is the balance after F minus one. Upgraded nodes would apply the prescribed balance adjustments before ordinary transactions in F. That sequencing matters because it identifies the exact boundary a reviewer would use to check the outcome.
A normal transfer usually gives an explorer a transaction entry to display. A change applied directly under the chain’s rules may instead be visible by comparing balances across adjacent blocks. Someone looking only at the recipient’s list of ordinary transfers could miss it. The proposed publication of a verification script would help connect the before-and-after state with the list of intended recipients.
The verification needs to cover both sides of the ledger. It would look for a matching debit and credit for each balance. If a recovery address also received ordinary transactions in the same block, the raw difference between two snapshots could include those movements. A reviewer would then need to separate them from the special state change rather than treat every increment as recovered funds.
The activation block is a coordination deadline. An operator running software that calculates the old state and an operator applying the special balance rule could calculate different results from the same block. The practical work therefore includes publishing the change, giving operators time to review it and making the activation point clear. The proposal’s table still labels the block as a decision to be made once approval is in place. A governance discussion is an opportunity to settle that plan, while the chain state would establish execution.
Who makes the change take effect
The forum proposal describes the requested change. A separate milestone would be a release that implements it and identifies the activation block. Operators would then have to adopt compatible software for the change to take effect on the chain they use.
A user following the proposal should therefore distinguish a forum post, an implementation and a block that actually reflects the new balances. Each answers a different question about the recovery.
The work behind choosing an activation block
A block number can look like an administrative detail. In practice it is where the new software and the old software begin to disagree about the balances of the affected accounts. Choosing it gives operators a shared deadline for installing the upgrade, and it gives explorers, infrastructure providers and the affected firms a common point from which to check the result.
The preparation proposed in the forum post involves confirming the destinations, keeping the blocking arrangements in place until activation and publishing a fresh balance snapshot. Those steps address different ways a recovery could go wrong. An incorrectly recorded address could send assets somewhere unintended. An unexplained change in a balance could leave readers comparing the outcome against a stale figure. A delayed upgrade could leave an operator calculating state using the old rules.
Each of those issues calls for a different check. For the destination, the important evidence is how the recipient demonstrates control and how the published address is reviewed. For the amount, it is the balance at the final reference point. For the network, it is which software versions actually process blocks after the activation point. A statement that operators support the recovery would answer none of those implementation questions on its own.
There is also a useful check after the event. The state change would affect native balances directly, while an ordinary payment made in the same block could affect the same recipient. A balance difference therefore needs to be reconciled against ordinary transactions in that block. That is where the verification script proposed by the authors would be useful, particularly if it identifies both the debit and the corresponding credit for each account.
Where customers enter the process
The recipient of the proposed transfer is a recovery address, not a list of customer accounts. Once an operator controls the funds, the next question is how its own recovery and reimbursement process accounts for them.
Relevant evidence would include a claims timetable, instructions for proving a loss and a policy on the valuation date. A platform might already have reimbursed some users from other funds. Its accounting would need to establish where recovered POL goes in those cases.
What counts as a return to customers
A receiving wallet is where the network’s ability to move the funds meets an organisation’s responsibility to account for them. If affected customers have already been reimbursed from an exchange’s own resources, the recovery could replenish those resources under the applicable terms. If they have outstanding claims, a distribution might instead reduce the amount they are owed. Both scenarios involve money reaching a recovery address, with different consequences for users.
There may also be a mismatch between the asset recovered and the asset a customer lost. A user whose original balance was denominated in dollars or another token would need to know whether compensation is calculated in units of that original asset, in POL or in money at a stated price. A volatile token can produce materially different outcomes depending on when the conversion is measured.
The distinction between customer balances and platform losses is especially important when separate incidents are combined in one proposal. The reference table allocates the Polygon balances by incident. It does not contain a joint claims pool or a calculation of amounts due to individual users. Even if both sets of balances move in the same activation block, the platforms can face different obligations and may announce different payment arrangements.
The public evidence can be ordered by what each step would prove. A release and activation height would show an implementation is ready. The block state would show whether the ledger changed. Records from the platform would establish whether the recovered assets were distributed, retained against prior compensation or otherwise accounted for. The forum draft makes its intended chain-level destinations specific to each incident and provides for public verification of the balance changes.
Who can decide what a recovered token is worth?
Assume, for illustration, that a platform owes a user the cash value of a balance and receives POL after the price has changed. There are at least three dates the platform might refer to: the time of the theft, the time at which it obtains the recovered tokens and the time at which it makes a distribution. The amount of cash represented by the same quantity of POL can differ at each point.
A claims policy could instead provide for payment in units of the asset that was lost. That avoids choosing a market price for a claim denominated in the same asset, but it still leaves questions about eligibility and prior reimbursements. A customer who had already been repaid could have a different position from someone whose claim remains outstanding. The network has no role in making those determinations.
What a customer needs is a statement of what the platform owes, in which unit and how it accounts for anything paid earlier. The chain can establish a recovery address received a balance, and the platform can reconcile it with its records. Neither document does the other’s job. This is one reason a confirmed recovery can be news even if there is still a separate wait for details of a distribution.
A reporting comparison can keep the figures side by side. The first would be the native POL recovered under the state change. The second would be the amount assigned to customer claims or to reimbursements already made. The third would be any balance that remains in custody while the platform resolves individual cases. A single dollar number taken from the first stage would tell readers little about the other two.
Why the narrow scope matters
A fork that changes balances raises a question that a normal software upgrade does not. What facts would have to be present for participants to support this intervention again?
The proposal itself describes the action as extreme and limits it to listed native POL balances. The case for the proposal and the question of precedent can both be assessed against the same concrete details: the identified addresses, the proposed destination and the block at which the balances would change.
What would make this case a precedent?
Another project might point to Polygon’s approach after a theft, but the circumstances in this draft are unusually specific. The authors identify the incidents, the listed accounts, the assets subject to the proposed change and where they would go. They also describe why the restriction already in use was only a temporary measure. A proposal without those elements would make a different case for changing balances.
The important issue is who has to be persuaded and what information they receive. An exchange may know which customer balances were affected, while operators need evidence about the proposed change to the chain. A user whose funds are recovered is interested in the result. An operator evaluating the proposal also has to think about how it would assess a future request from a different party.
The safest comparison is between the facts another request could demonstrate. Can it identify the amount at a particular block? Can it tie those funds to an acknowledged incident? Can it verify a recipient and specify what happens to addresses already blocked? Those questions follow directly from the published draft and are more useful than describing every unusual state change as equivalent.
The proposal would leave some of those questions testable in public. An activation height would allow observers to identify the exact state transition. Named destinations would allow them to trace what happened after it. The authors also propose reviewing the entries on the temporary block list after activation, including different treatment for the additional Binance-related addresses. That final review would help establish which emergency restrictions remain in use after the recovery is complete.
What the ledger could confirm
If the proposal is implemented, the first check would compare the listed address balances on either side of the fork block. Matching credits would show that the ledger applied the transfer as specified. Customer distributions would need evidence from the recovery operators.
The current proposal specifies five source addresses and designated recovery addresses for the two incidents.
Which records answer which recovery question
| Record | What it could establish | What remains to be established |
| Historical transfer | The sender, recipient, amount and time recorded onchain | Who can legally claim the balance |
| Block producer filter | Whether operators adopted a restriction on specified transactions | Whether the network returned the funds |
| Activation snapshot | The amounts available for the state change | Whether upgraded nodes applied it |
| Post-fork state | The resulting debits and credits at named addresses | Whether customers received compensation |
| Platform claims record | What customers received and how amounts were calculated | Whether other assets remain recoverable |
An incident can move through these stages at different speeds. The USDT freeze, for example, concerns a different asset and mechanism from the proposed POL fork. A later announcement about funds protected or recovered would need to specify which asset was counted and what happened to it.
The balances can also change between the dates used in reporting. A proposal that quotes an earlier snapshot should preserve the block number so readers can reproduce the amount even if the current balance changes. When the result is known, comparing the execution block against the published snapshot would establish whether the amount returned differs from the amount discussed in the proposal.
The most important reconciliation for readers is between the amount debited and the amount credited. Publishing that check separately for the two incidents would allow each platform’s later account of proceeds to be compared with the amount it actually gained control over. A single combined total would make it harder to follow which proceeds were available to meet which claims.
A narrow recovery also gives the platforms a way to communicate what happened to assets outside the fork. The Polymarket figure in the forum post includes more POL than is listed in the proposed state change. The Binance transfer included USDT, which Tether handled separately. A recovery update that identifies the relevant asset, the address and the action taken would allow readers to reconcile both incidents without assuming all stolen funds followed one route.
The chronology gives three dates with different meanings. The incident date establishes when the funds moved. The reference block establishes what was observed at the addresses when the authors compiled the proposal. The activation date, if agreed, would establish when the network applies the recovery rule. A token can be protected against certain transfers between those dates without having been returned in the meantime.
The address records can also serve as a check on statements that come after an upgrade. If an operator claims that funds were sent to the published destination, the chain should show the matching balance change at the activation height. If it says customers have been repaid, the more useful evidence is a distribution record or a clear account of reimbursements. One is a statement about the network, the other about the platform’s obligations.
That is why the ledger evidence is especially valuable when the public conversation turns to whether the fork worked. It gives observers a narrow question they can verify without waiting for each affected firm to complete its own accounting. The proposal sets out a procedure for publishing the balances used in the state change and for checking the recipient credits after it. Those records would also give users a starting point for tracking what each platform did once it had control of the money.
What to Watch
- Release proposal: The incident-specific quantities, proposed recipient addresses and executable instructions submitted to governance.
- Activation block: The confirmed block height and the software release Polygon operators would need to install before it.
- Recovery credits: The native POL debited from each blocked address and the matching credit recorded at its designated recipient.
- Customer claims: Each platform’s instructions on eligibility, valuation and how it will account for earlier reimbursements.
FAQs
Has Polygon already moved the funds?
The proposal describes a possible recovery. An agreed activation block and matching balance changes at the listed addresses would establish whether Polygon carried it out.
How much POL is involved?
The reference balances total approximately 70.49 million POL across five addresses. The proposal calls for a fresh balance check, so the amounts ultimately moved could differ from those reference figures.
How is it split?
About 46.63 million POL is tied to the Binance incident and 23.86 million to Polymarket’s. The proposal assigns the two amounts to separate recovery destinations.
Why does the proposal call for a fork?
Upgraded Polygon software would apply the specified balance changes at a fixed block. An ordinary transaction would require authorisation to spend from the affected addresses.
Is the proposal about every asset at those addresses?
It covers native POL at the listed addresses. Tether’s separate freeze on the USDT transferred during the Binance incident uses a different mechanism.
Who receives the POL first?
Designated recovery addresses would receive the POL first. Customers would need to look to their platform’s claims process to find out how their balances would be handled.
Does a recovery credit settle a customer claim?
The credit would show that funds reached the recovery address. It would take a separate distribution or reimbursement record to establish what an individual customer received.
Can readers verify execution?
Readers could compare the balances immediately before and after activation and reconcile them with ordinary transactions in the same block. The proposed verification script would make that check easier. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures are based on sources available at the time of writing and may change with new disclosures. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is current as of 6 November 2026. Legal questions should be discussed with qualified counsel.
