SMART CONTRACTS, DEFI & WEB3 SECURITY - Chapter 9, Exercise 3 Solution ========================================================== Why Rug Pulls and approve() Phishing Fall Outside Chapter 7's Taxonomy PROBLEM ------- Explain why a rug pull and an approve() phishing exploit both fall outside Chapter 7's own smart contract vulnerability taxonomy, even though both can result in a user losing real funds from a Web3 application. SOLUTION -------- Chapter 7's own taxonomy specifically catalogs ways a smart contract's code can behave differently than its own developers intended - a flaw, bug, or oversight in the contract's own logic that lets an attacker achieve something the contract was never actually supposed to allow. Both categories this exercise asks about lack exactly that property. RUG PULLS: a rug pull does not require any flaw in the contract's own code at all. The liquidity pool contract (Chapter 4) may function completely correctly and exactly as written - the real problem is that the contract's own owners always retained the legitimate, intended ability to withdraw liquidity, and simply chose to exercise that ability in a way that harmed other participants. There is no bug to name here, because the contract did precisely what it was built to do; the harm comes from the intentions of the people controlling it, not from any gap in the code. APPROVE() PHISHING: this exploit targets the ERC-20 approve() function working exactly as it is genuinely designed to work. The token contract's own code correctly checks whether the calling address has been granted permission, and correctly allows an approved address to move tokens on the owner's behalf - that is the function's real, intended purpose. The actual failure occurs entirely outside any contract's own code: a user is deceived, typically by a malicious website's interface, into granting that permission to an attacker-controlled address in the first place. The token contract itself never misbehaves. THE SHARED PATTERN Both cases share the same underlying reason for falling outside Chapter 7's taxonomy: that taxonomy specifically catalogs code doing something it was not supposed to do. In both a rug pull and an approve() exploit, every contract involved behaves exactly as its own code specifies - the loss instead comes from a legitimate, working feature being used by a bad actor, or by human deception happening around the contract rather than inside it. ANSWER: Rug pulls and approve() phishing both fall outside Chapter 7's taxonomy because that taxonomy specifically covers contract code behaving in a way its own developers never intended - a genuine bug or flaw. In a rug pull, the liquidity-pool contract works exactly as written, and the harm comes from the legitimate owner's own choice to use an intended feature (withdrawing liquidity) in a harmful way. In an approve() exploit, the ERC-20 token contract's approve() function also works exactly as designed - the failure is a user being deceived into granting permission to a malicious address, which happens entirely outside the contract's own code. Both are real losses of funds without any contract actually malfunctioning. ---- WHY THIS WORKS AS AN ANSWER It identifies the specific defining property of Chapter 7's taxonomy (code behaving unintentionally) and shows precisely why neither case satisfies it - both involve a contract functioning exactly as designed, with the actual harm originating from human intent or deception rather than a code-level flaw.