The Poly Network Hack (2021): When the Attacker Gave the Money Back

On 10 August 2021, an unknown attacker took more than 600 million dollars in digital assets from Poly Network, a service that links separate blockchains. It was the largest decentralised finance theft up to that point. What happened next was unusual: within days, the attacker began returning the funds.

What Poly Network did

Poly Network is a cross-chain protocol, created by a Chinese development team, that lets users move tokens between blockchains such as Ethereum, Binance Smart Chain and Polygon. A cross-chain system typically locks assets on one chain and releases equivalent assets on another, which means it has to hold large pools of funds and must correctly verify instructions arriving from other chains.

How the exploit worked

Security researchers who analysed the attack concluded it was caused by a flaw in the way the contracts handled permissions, not by stolen private keys in the usual sense. In simple terms, one contract was allowed to execute calls on another contract that controlled the list of trusted signers, called keepers. The attacker found a way to make a cross-chain message trigger a call that replaced the keeper's public key with one the attacker controlled. With that key, the attacker could sign withdrawal instructions that the system accepted as authentic.

The exact technical explanation was published by several security firms in the days after the attack. The essential point is that the logic around who may change the guardians was flawed, and the attacker exploited it on multiple blockchains.

What was taken

Those totals, around 611 million dollars in all, were estimated at the prices of the time and are rounded. The assets included many different tokens, rather than one currency.

The response

Poly Network publicly asked the attacker to return the assets and shared the addresses involved so that exchanges and others could watch for them. Because every transaction was public, many observers could watch the assets move, and the project asked exchanges and miners to blacklist the attacker's addresses. Security firms traced the funds across addresses. The issuer of the stablecoin Tether froze around 33 million dollars worth of USDT held by the attacker's address, which stopped that portion from moving.

Then the attacker began communicating through messages embedded in transactions on the blockchain. Within days the attacker started to return the funds in stages, and the project reported that the great majority of the assets had been recovered. In the following weeks, control of the remaining assets was handed back, and Poly Network resumed operations in a limited way. The attacker said they had acted for fun and had planned to return the funds, but those statements were never verified, and this article does not treat the claim as established.

Why it is still discussed

• Scale. It showed that a single contract bug could put hundreds of millions of dollars at risk.
• Traceability. The attacker could not easily convert the proceeds into cash. Public ledgers and issuer freezing powers made it hard to profit, which was probably one factor in the return of funds, though only the attacker knows their motives.
• The role of bug bounties. Many projects now run programmes that pay researchers to report vulnerabilities, which is a legal alternative to exploiting them.

The pattern in cross-chain attacks

Poly Network was followed by other bridge incidents, including Ronin in March 2022, Wormhole in February 2022 and Nomad in August 2022. These attacks differ in detail but they share a theme: bridges concentrate value and rely on complex code and verification logic. Researchers continue to explore designs that reduce trust, such as light-client verification, though no design removes all risk.

Bug bounties and disclosure

A bug bounty is a standing offer to pay researchers who report vulnerabilities responsibly. A good programme states which systems are in scope, what rules apply, and how rewards are set. The aim is to make reporting more attractive than exploiting. Platforms such as Immunefi specialise in this field for blockchain projects. The same idea works for ordinary websites on a smaller scale: publish a clear way for researchers to contact you, for example through a security.txt file as described in RFC 9116, and respond promptly to reports. You can reach our team through the contact page if you have a question about how to set up a secure site.

What users and builders can take away

1. Audit, and audit again. Code changes, especially to permission logic, deserve independent review.
2. Limit exposure. Cap how much value a single contract can control, and add delays on large withdrawals.
3. Prepare incident plans. Know in advance who can pause a system and how to contact exchanges and issuers.

A practical lesson for site owners

Permissions are a common weak point in ordinary websites as well. Review who has access to your hosting panel, your database and your email accounts, and remove anything unneeded. Our security page outlines the safeguards available with Zebra Hosting.