The Poly Network hack: how $610 million was taken, and why it came back

In August 2021 someone drained more than $600 million from a crypto platform in one of the largest thefts of its kind, and within about two weeks gave essentially all of it back.^[1] This case file covers the one misplaced power that made the theft possible, the strange public negotiation that followed, and the control that would have closed the gap before anyone found it.

What happened

How it worked

A bridge like this lives or dies on one question: who is allowed to say a withdrawal is valid? In Poly Network's design, that list of approved signers was held in a data contract, and changing it was a privileged action.^[2]

The problem was which other part of the system had that privilege. The contract that processed ordinary incoming cross-chain messages also held the right to update the keeper. According to a post-incident analysis by a blockchain security firm, the attacker sent a specially shaped cross-chain message that caused that everyday message handler to call the keeper update on their behalf, swapping in a key the attacker controlled.^[2]

Once the attacker was the keeper, the system trusted them completely. They could approve their own withdrawals, and the contracts released the funds as designed.^[2] Nothing was technically broken in the sense of a crashed server. A routine path simply had access to the most powerful switch in the building.

How it ended

The attacker was never publicly identified, and no one has been charged.^[1] Security experts pointed to a practical reason for the return: every movement of stolen crypto is recorded on a public ledger, which makes converting a haul this size into usable money very hard.^[1]

Not every token was part of the handover. About $33 million in one stablecoin had been frozen by its issuer, and more than $200 million was stuck for a time in an account that needed both sides' keys to open.^[1] In messages embedded in their transactions, the attacker said they were quitting and had wanted to point out the weakness in their own way. Some observers suspected the whole episode was partly a publicity stunt.^[1]

Poly Network got lucky. Most attackers who find a flaw like this do not negotiate, and most bridge losses are never recovered.

The missing control

The missing control: no single component able to change who signs withdrawals. The power to replace the keeper should have been separated from the code that handles everyday messages, and should have required several independent approvals and a time delay before taking effect.

With that separation, the attacker's crafted message would have reached a handler that simply had no right to touch the signer list. Even if some route had existed, a multi-party approval and a waiting period would have given the team time to notice an unexpected signer change and stop it before the vaults were emptied. The security firm's own lesson was to test for unintended interactions between contracts, especially where a privileged function can be reached through an outside call.^[2]

What to do in your business

• List who can change who approves payments. In your bank, payroll and accounting tools, find which users can add approvers or change payee details. Keep that list short.
• Require two people for changes to approvers. Adding a new signer, raising a limit or changing bank details should need a second person's sign-off.
• Add a cooling-off period. Ask your bank whether new payees or approver changes can be held for 24 hours, with an alert to more than one person.
• Keep admin rights off everyday accounts. Staff who send routine payments should not use the same login that can change settings or permissions.
• Review permissions after every new tool. When you connect an app or integration, check what it is allowed to change, not just what it reads.

Facts are drawn from court records, government reports, company statements and reputable reporting, listed below. People are named only where they were convicted, pleaded guilty or spoke publicly in an official role.