Real, Documented Exploits & What They Teach

Smart Contracts, DeFi & Web3 Security

Course 2 · Chapter 8 · Real, Documented Exploits & What They Teach

Chapter 7 named the vulnerability classes. This chapter applies that taxonomy to two real, fully documented, large-scale exploits — one a genuine smart contract flaw, the other a reminder that "smart contract security" isn't the only real attack surface in Web3 at all.

Case Study 1: The Poly Network Exploit (August 2021)

Poly Network is a real protocol for moving assets between different blockchains. On 10 August 2021, an attacker exploited a real, genuine access control flaw in its cross-chain contract logic — exactly the vulnerability class Chapter 7 covered — to trick the protocol into treating the attacker's own address as an authorized "keeper" able to direct transfers. The result: over $610 million moved out to addresses the attacker controlled, spread across Ethereum, Binance Smart Chain, and Polygon — the largest DeFi hack ever recorded up to that point.

10 Aug 2021

The exploit occurs; over $610 million is drained across three chains.

11 Aug 2021

The attacker publicly announces, one day later, that they intend to return the funds.

13 Aug 2021

$340 million worth has already been returned; the rest moves to a multisig (Chapter 6) jointly controlled by the attacker and Poly Network.

25 Aug 2021

The full return completes — just 15 days after the original exploit. Poly Network publicly offers the anonymous attacker a $500,000 bug bounty and a "chief security advisor" role.

A Real, Genuinely Debated Ending Whether to call this attacker a "white hat" security researcher who made a point, or simply a thief who got cold feet (or feared being traced, since every transaction is permanently public per Course 1's own chapters on transparency), is a real, open question security professionals have genuinely disagreed about publicly. Some raised a real, honest concern that publicly rewarding this outcome risks normalizing "steal it, then negotiate a reward for giving it back" as an acceptable playbook. This chapter isn't resolving that debate — it's worth knowing the ending is genuinely contested, not a clean, uncomplicated resolution.

Case Study 2: The Ronin Network Bridge Hack (March 2022)

Ronin is a real, dedicated blockchain built for the game Axie Infinity, connected back to Ethereum via a "bridge" — a system for moving assets between the two chains. On 23 March 2022, attackers stole a real, documented 173,600 ETH and 25.5 million USDC, worth approximately $620 million at the time — discovered only six days later. The FBI later attributed the attack to the Lazarus Group and APT38, real North Korean state-sponsored hacking groups.

A Genuinely Different Kind of Attack Surface Unlike Poly Network, this wasn't primarily a smart contract code vulnerability of the kind Chapter 7 catalogued. The real, publicly reported account is that the attackers compromised validator infrastructure directly — obtaining enough real, valid private keys to forge the authorizations needed to approve withdrawals, reportedly through social engineering rather than exploiting a flaw in the bridge's own Solidity code. The exact operational specifics (which keys, exactly how many, and exactly how they were obtained) are widely reported in security-industry coverage, but this course couldn't independently re-verify every specific detail this session — the honest, important, well-established takeaway is the category of attack: this targeted the humans and infrastructure operating the system, not a bug in the deployed contract itself.

Sky Mavis, Ronin's own developer, publicly reimbursed all affected users afterward — a real, centralized company absorbing a loss that a fully decentralized system, per Course 1's own trust-minimization theme, wouldn't have had any single party positioned to guarantee.

What Both Cases Teach Together

	Poly Network	Ronin
Real cause	A genuine access-control flaw in deployed contract code	Compromised validator/infrastructure access, not a contract code bug
Real scale	Over $610 million	Approximately $620 million
Real outcome	Funds fully returned within 15 days	Funds not recovered; users reimbursed by the company
Chapter 7 category	Access control	Outside this course's own contract-code taxonomy entirely

Chapter 7's own vulnerability taxonomy is real and useful — but Ronin is an honest, important reminder that it only covers part of the real attack surface. A perfectly audited, flawlessly written smart contract can still sit behind a system whose real weak point is a human being tricked into handing over access, or a private key stored insecurely. Real Web3 security has to cover both the code and everything operating around it.

Hands-On Exercises

Three exercises applying both real case studies before Chapter 9 turns to regulation, custody, and the broader real risks of Web3.

Exercise 1

Using Chapter 7's own vulnerability taxonomy, explain specifically which category the Poly Network exploit falls under, and describe in your own words what the attacker's contract interaction must have achieved to be treated as an authorized "keeper."

→ Solution

Exercise 2

A junior developer says: "We had our smart contracts professionally audited, so our project is now fully secure against a major hack." Using this chapter's own Ronin case study, explain what this statement overlooks.

→ Solution

Exercise 3

Using this chapter's own comparison table, explain why Ronin's users could be made whole by Sky Mavis's own reimbursement, while a comparable loss on a fully decentralized protocol with no single company behind it typically couldn't be resolved the same way.

→ Solution

Quick Reference

Poly Network (10 Aug 2021) — a real cross-chain access-control flaw, over $610 million drained, fully returned within 15 days after the attacker announced their intent the very next day.
Ronin Network (23 Mar 2022) — approximately $620 million (173,600 ETH + 25.5M USDC) stolen via compromised validator access, attributed to North Korea's Lazarus Group/APT38; users reimbursed by Sky Mavis.
The real, shared lesson — smart contract code vulnerabilities (Chapter 7) are real and serious, but infrastructure and human factors are a genuinely separate, equally real attack surface.