Abstract
On 29th and 30th October 2026, Polymarket and Binance each dealt with a separate, publicly acknowledged security incident. In both cases, stolen funds in native POL arrived at addresses on Polygon PoS. At the request of the affected parties, the Polygon PoS block producers (anonymous-91 to anonymous-94) added those addresses to the Bor transaction block list.
5 attacker-controlled addresses hold about 70.49M POL: about 23.86M POL (4 addresses) from the Polymarket incident and about 46.63M POL (1 address) from the Binance incident. The funds cannot move, but nothing in the current setup lets them be returned either.
This proposal asks for a coordinated hard fork that, at a fixed block, sets the native POL balance of each listed attacker-controlled address to zero and credits the same amount to a recovery address that Polymarket or Binance has designated and verified. The change is limited to native POL balances in the addresses listed in this PIP. It is an extreme action that should not be reproduced commonly. Section 5 of the Specification and the Rationale state the conditions under which it is justified here.
Motivation
The Incidents
Polymarket. On 29 October 2026, about 28M POL was involved in the Polymarket incident on Polygon PoS. At 18:30:34 and 18:35:59 UTC, 3,282,275.71 POL went from 0xe4C4…1EC6 to 0x3f70…1Ffa in two native transfers. All validator-elected block producers blocked the four addresses in the table below, which hold about 24M of the roughly 28M POL involved. Polymarket’s own account of the incident is in its post-mortem .
Binance. Late on 29 October 2026, Binance was hacked, and on 30 October it asked all validator-elected block producers to block 0x5227…2f8c. In block 96,406,484, a Binance hot wallet had sent that address 46,626,589.6 POL (native) and 6,185,900.1 USDT. Tether has since frozen the USDT, which leaves the native POL as the balance still at risk. Binance later supplied further addresses to block (Class B below). Binance’s own account is in its post-mortem.
Why a block list is not enough
The block producers’ block list stopped the funds from moving, and no bypass has been found, but it is a stopgap. Each block producer reads its list only at startup, so every change needs a deployment and a Bor restart or span rotation. Entries have no automatic expiry. The filter also covers only outer senders and EIP-7702 authorities, so it is not a complete asset freeze. The attacker keeps trying: a pending transaction paying a fee of about 219,450 POL (10.45 POL per gas) was observed on 30 October, and the attacker has contacted validators offering cash payment in exchange for assistance to unblock a transaction. Polymarket has also opened a recovery channel to the attacker on-chain through the SEAL Safe Harbor Recovery safe without receiving any response. Leaving 70M POL locked indefinitely is neither a stable end-state nor a return of funds to their owners.
Why this is not a random demand for funds
This proposal relies on the following conditions. Each is checkable, and the evidence is listed in the References.
| Condition | Status | Evidence |
|---|---|---|
| The hacks are publicly acknowledged by the victims | Met | Polymarket and Binance post-mortems (links below); independent public reporting of the Binance incident |
| Every block producer has blocked the addresses | Met | Block lists on anonymous-91 to anonymous-94 updated and deployed on all block producers |
| The sum is meaningful | Met | About 70.49M POL (indicatively US$6.5M at US$0.0924 per POL, spot on 29 Oct 2026) |
| The funds trace to known, reputable victim(s) | Met | On-chain transfers from the victims' wallets to the listed addresses, set out in the tables below, and Polymarket and Binance are well known, reputable actors |
| The affected parties request the remedy | Met | Polymarket and Binance are the proposers of this PIP |
| After public statements, no potential party having a right to the funds has contested the circumstances of the incident. | Met | The event has been publicly stated, and no party has come forward with any alternative description of the events. |
Scope and precedent
Polygon PoS validators are not asked to adjudicate disputes or to freeze or move funds in general. They are asked to approve one fork with a closed list of addresses, specified in advance and tied to two incidents that meet the conditions above. This should not be reproduced commonly (see Rationale).
Specification
1. Parameters
| Item | Value |
|---|---|
| Network | Polygon PoS mainnet (Bor); rehearsed first on Amoy |
| Asset in scope | Native POL balance (the gas token, exposed at 0x0000000000000000000000000000000000001010). Other tokens are out of scope; USDT at 0x5227…2f8c is already frozen by Tether |
| Fork name | [TO BE Decided once approved] |
| Activation block | [TO BE Decided once approved] |
| Polymarket recovery address | 0x3dcE0a29139A851Da1dFCa56Af8e8a6440b4D952 |
| Binance recovery address | 0xd9fd39103674cb061d64d9c3b73b878dbe610b80 |
| Client release | [TO BE Decided once approved] |
2. Addresses
2.1 Polymarket: blocked addresses
Reference balances are the floors read at mainnet block 96,399,251 (29 Oct 2026).
| # | Address | Native POL balance | Notes |
|---|---|---|---|
| 1 | 0xe4C4C39C1733e1C7c06B79f97ED442B68Df41EC6 | 15,331,308.29 | Largest holder; source of the onward transfers to 0x3f70…1Ffa |
| 2 | 0x5392587814Ce8c6af6789764f88e5e9AB0b9962C | 4,295,442.00 | |
| 3 | 0xc91ee0574a14446DE200923729c349B9CAE19b60 | 4,235,982.73 | Received POL after the first block request |
| 4 | 0x3f7019221a925537dC20767C38e80A7127fb1Ffa | 3.05 | Received 3,282,275.71 POL from #1 in two transfers; now holds little |
| Total | 23,862,736.07 |
2.2 Binance: blocked address
Reference balance is the floor read at mainnet block 96,413,185 (29 Oct 2026).
| # | Address | Native POL balance | Notes |
|---|---|---|---|
| 1 | 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c | 46,626,593.27 (block 96,413,185) | Recipient of the drained funds (46,626,589.6 POL plus 6,185,900.1 USDT from Binance hot wallet 0xe7804c37…e245 in block 96,406,484). USDT frozen by Tether. Class A. |
3. State transition at the fork block
At the start of block F (the activation block), before any transaction in F is executed, for each Class A address A in Tables 2.1 and 2.2, in order:
- Let amount = balance(A) in the post-state of block F-1.
- Set balance(A) = 0.
- Set balance(R) = balance(R) + amount, where R is the recovery address of the presenter for A (Polymarket for Table 2.1, Binance for address 1 of Table 2.2).
Total supply is unchanged. Class B addresses are not touched. Heimdall, the StakeManager and the bridge contracts are not changed. [Proposed design, to be confirmed by Bor engineering; see Rationale for the fixed-amount alternative.]
4. Recovery address verification
Before activation, each presenter will:
- Provide the recovery address in the PIP discussion thread.
- Prove control, for example with a message signed by the address or a small test transfer from it, confirmed by Polygon Labs.
- Confirm in writing that the address is theirs to receive these funds.
5. Conditions for activation
The fork activates only if all of the following hold at the time of the final vote and at the Amoy sign-off:
- The PIP is approved through the Polygon governance process.
- The presenters’ post-mortems remain published and consistent with the on-chain record.
- The block lists on all block producers remain in force until the fork activates.
- The Class A balances are re-read at the snapshot block and any change from the tables above is published.
6. Rollout and timeline
| When | Action |
|---|---|
| 5 November 2026, 14:30 UTC | Presentation at the Polygon Protocol Governance Call (PPGC) |
| After approval | Client development and Amoy deployment and rehearsal. About 2 weeks after approval is viewed as workable; one week is tight |
| Before mainnet | Validator, RPC provider and explorer notification. Polygon validator operations expects about 70 to 80% of stake to reach the required version quickly after release |
| Block F | Fork activates on mainnet |
| After block F | Publish the transaction-free balance change and the verification script. Review the block-list entries: Class B entries are removed on Binance's confirmation, and Class A entries are reviewed for removal once empty |
Rationale
Why a hard fork. The block list prevents movement but cannot return funds. Moving a balance without the owner’s key is possible only through a consensus change, so a coordinated fork is required.
Why now. The funds are held in a configuration that depends on every producer restarting with an unmodified file. That is operationally fragile (the file is read once at startup, entries do not expire, and the attacker has a strong incentive to find a bypass).
Alternatives considered.
- Leave the funds locked. Simplest, but it freezes about 70M POL permanently and relies on a mechanism designed as a short-term stop.
- Negotiated return through the attacker. Polymarket has tried this on-chain. It depends on the attacker’s cooperation and cannot be relied on.
- A general freeze-and-recover mechanism in the protocol. Rejected. It would be a permanent power over user funds.
An extreme action. This proposal is a response to a specific situation and should not be reproduced commonly. It relies on all of the following together: a widely acknowledged theft, a victim that presents the PIP, a block that every producer applied and validators have not lifted, an amount large enough to justify a fork, and funds traceable on-chain to the victim. A future request that does not meet them should not rely on this PIP as precedent.
Backwards Compatibility
This is a consensus-breaking change to Bor. All validators, RPC providers, exchanges and node operators must run the new release before block F. Nodes that do not upgrade will follow a different chain from block F. Heimdall, the StakeManager and the bridge contracts are unchanged, and no state before F is altered. Balances at F and later differ from a re-execution of F’s transactions alone, so tooling that re-derives balances from transactions (explorers, indexers, accounting tools) must handle the balance change at F.
Test Cases
- An Amoy rehearsal with test accounts standing in for Class A addresses and for the two recovery addresses. It checks the balance transfer at F, that supply is unchanged, and that no other account changes.
- A mainnet-fork replay of the transition using the Class A balances at the snapshot block.
- A node that has not upgraded must reject block F.
- Class B addresses are untouched by the fork.
- The recovery-address verification in section 4 is completed on mainnet before the release is tagged.
Security Considerations
Precedent and trust. Moving a user’s balance is the most sensitive action that can occur on a chain. The proposal is bounded: a closed address list, a one-time rule at a named block and the conditions in section 5.
Wrong attribution. If an address on the Class A list is not attacker-controlled, a legitimate balance is moved. Each Class A address is tied to on-chain transfers in this PIP. Binance Class B addresses are not swept for this reason.
Recovery-address compromise. A fake or compromised recovery address would send funds to the wrong party. Section 4 requires a proof of control and written confirmation, and any multisig signers will be published.
Chain-split risk. Validators that do not upgrade will fork off. Mitigations are an Amoy rehearsal, advance notice and a release date set after stake coverage is confirmed.
Late credits. Anyone can send POL to a blocked address before F, and the full-balance rule would move it. The amounts involved are small, and the Class A balances are re-read at the snapshot block.
Contract wallets. Binance’s Hot Wallet 34 is a smart-contract wallet and accepts ERC-4337 UserOperations, which a sender-based filter cannot stop. It is a Class B entry and is not swept.
Legal and compliance. The proposal is not legal advice, and neither the presenters nor Polygon Labs make any promise about the outcome of the vote.
Communications and post-mortems
| Party | Item | Link |
|---|---|---|
| Polymarket | Post-mortem | [[Postmortem](https://status.polymarket.com/cmvvek1i90eme14ruga1z6tuj)] |
| Polymarket | Public statement or X thread | X thread |
| Polymarket | On-chain notice to the attacker via the SEAL Safe Harbor Recovery safe | Polygonscan tx |
| Binance | Post-mortem | X post |
| Binance | Public statement or X thread | X thread |
| Binance | Public attack reports | @spreekaway; @Dogetoshi |
| Binance | Transfer to 0x5227…2f8c | Tx 1; Tx 2 |
Copyright
Copyrights and related rights regarding the contents of this PIP work are waived under CC0.