The $20 million exploit of Sonne Finance on May 14, 2024, exposed a recurring vulnerability pattern in Compound v2-forked lending protocols known as the donation attack. For experienced DeFi users and developers, this incident provides a critical case study in how to identify and assess similar vulnerabilities before they are exploited. This advanced tutorial walks through the technical mechanics of the donation attack, the specific conditions that enabled the Sonne Finance exploit, and a systematic methodology for auditing lending protocols for this class of vulnerability. With Bitcoin at $66,267 and Ethereum at $3,037, the broader DeFi ecosystem holds tens of billions in total value locked, making security literacy an essential skill for serious participants.
The Objective
This tutorial aims to equip you with the knowledge to independently assess whether a lending protocol is vulnerable to donation attacks. You will learn to identify the specific code patterns that create this vulnerability, understand the market conditions that enable exploitation, and develop a framework for evaluating the security of any Compound v2 fork. By the end of this guide, you should be able to review a lending protocol’s smart contracts and governance configuration to determine whether similar attack vectors exist.
Prerequisites
This tutorial assumes familiarity with Solidity smart contracts, Ethereum Virtual Machine mechanics, and the basic architecture of Compound v2-style lending protocols. You should understand how collateral factors work, how lending pools calculate borrow capacity, and how governance proposals interact with protocol parameters. Access to Etherscan or the block explorer for the relevant chain is required to inspect contract code and transaction logs. Familiarity with Foundry or Hardhat for local contract interaction is helpful but not strictly necessary.
Step-by-Step Walkthrough
The donation attack exploits a fundamental interaction between how lending protocols value collateral and how total supply calculations are performed. In a Compound v2 fork, each lending market maintains an internal accounting system where user balances are represented as shares of a total supply. When a user donates tokens directly to the contract without going through the deposit function, the total supply increases but no user shares are minted. This means the value of each existing share increases, effectively inflating the apparent value of collateral held by the attacker.
Step one is to examine the market initialization and configuration process. In Sonne Finance’s case, the vulnerability was exposed during the integration of new VELO markets. Review the governance proposal that adds new markets and pay particular attention to how collateral factors are set during the initial configuration. If a market is added with a high collateral factor before sufficient liquidity exists, the conditions for a donation attack are present.
Step two is to analyze the timelock configuration. Sonne Finance used a two-day timelock on governance transactions, which meant that the critical transactions for market setup were visible and predictable. The attacker monitored the mempool and positioned their transactions to execute at the precise moment the timelock expired. When auditing a protocol, check whether governance-critical transactions can be front-run during timelock execution windows.
Step three is to inspect the collateral factor update mechanism. The Sonne Finance attacker specifically targeted the transaction that increased collateral factors for the new VELO markets. Review the smart contract code that handles collateral factor updates and determine whether there are any safeguards against sudden, large increases. Look for rate limiting, gradual adjustment mechanisms, or sanity checks that prevent collateral factors from being set to dangerous levels.
Step four is to simulate the attack locally. Using Foundry, you can fork the Optimism network at the block just before the exploit and reproduce the attack transaction by transaction. The exploit involved four initial setup transactions followed by the collateral factor increase and then the final borrowing exploit. Simulating these transactions reveals exactly how the donation attack inflates collateral values and enables over-borrowing.
Step five is to evaluate the protocol’s emergency response capabilities. Sonne Finance detected the breach within 25 minutes and paused markets, and the Security Alliance’s Seal911 contributors managed to salvage $6.5 million by adding minimal VELO to the compromised markets. When assessing a protocol, verify that it has functioning pause mechanisms, that the pause authority is appropriately decentralized, and that response procedures are documented and tested.
Troubleshooting
If you encounter difficulties identifying the vulnerability in a specific protocol, start by comparing the contract code against the original Compound v2 implementation. Focus specifically on any modifications to the exchange rate calculation, the total supply accounting, or the collateral factor logic. Forks often introduce subtle changes that create new attack surfaces. If the protocol uses a non-standard token as collateral, pay special attention to how the protocol handles tokens with transfer fees, rebasing mechanics, or other non-standard behaviors, as these can introduce additional vectors.
Another common challenge is determining whether a timelock configuration is genuinely secure. Some protocols use timelocks that can be bypassed under certain conditions, or that have guardian roles with emergency override capabilities. Trace through the complete execution path from governance proposal to on-chain effect to identify any shortcuts that an attacker might exploit.
Mastering the Skill
To develop expertise in DeFi security auditing, practice by reviewing real exploits retrospectively. The Sonne Finance exploit is an excellent starting point because the attack transactions are publicly visible on Optimism Etherscan. Reproduce the attack in a local environment, then attempt to identify the vulnerability before reading the analysis. Gradually work through other major DeFi exploits to build a library of attack patterns. Contribute to public audit reports and participate in bug bounty programs to sharpen your skills against real-world targets. The $20 million lost in the Sonne Finance exploit underscores that protocol security is not merely an academic exercise but a critical competency for anyone participating in the DeFi ecosystem.
Disclaimer: The information presented in this article is for educational and informational purposes only and does not constitute financial or security advice. Always conduct your own research and consult with qualified security professionals before interacting with DeFi protocols.
compound v2 forks are a security minefield and sonne wont be the last. the exchange rate rounding bug is present in at least 3 other live protocols i checked last month
the exchangeRateStored rounding bug being present in 3 other live protocols is terrifying. anyone holding cTokens in compound v2 forks should be checking their code right now
solvency_check_ most cToken holders dont even know what exchangeRateStored does. the gap between using a protocol and understanding its internals is where exploits live
Anya K. most cToken holders dont even know what a cToken is let alone exchangeRateStored. the knowledge gap between users and protocol internals is where funds disappear
the donation attack vector is basically a flash loan coupled with direct token transfers. any fork that hasnt patched the exchangeRateStored function is sitting on borrowed time
thomas the scariest part is governance can pause deposits but most of these forks dont have a circuit breaker. exploit runs to completion before anyone notices
governance pausing deposits would help but most forks dont even have that circuit breaker. youre just hoping someone is awake at 3am to notice the drain
reentrancy_42 three live protocols with the same exchangeRateStored round-down bug is wild. fork-first development means one design flaw becomes systemic across all of DeFi lending
exchangeRateStored round-down exists in every Compound v2 fork and most teams dont know its there. Sonne got exploited first but there are live protocols today with the same bug
finally someone explaining the actual code pattern instead of just posting ‘rekt’ on twitter. the collateral factor manipulation via direct transfers to ctokens is what most surface-level audits completely miss
the part about round-down precision in exchangeRateStored is the real killer here. been flagging this in audits for months before sonne happened and nobody cared until funds were gone
soren calling out the round-down issue before sonne got hit and nobody listened is the most defi thing ever. auditors flagging real bugs and getting ignored until the exploit
Soren V. the round-down in exchangeRateStored is one of those bugs that looks harmless in isolation but becomes a weapon when paired with direct ctokens transfers. great call flagging it early
reentrancy_ the exchangeratestored round-down is devastating when paired with direct ctoken transfers. most forks never patched this after sonne lost 20M
Soren V. exchangeRateStored round-down looked harmless for years until someone paired it with direct ctoken transfers. most audits still miss this
the direct transfer to ctoken pattern is well documented now but forks keep copying the same vulnerable code. compound v2 forks are a security minefield
audit_mole_ agree. actual code walkthroughs are rare. most post-mortems just say ‘donation attack’ and move on without showing the vulnerable function
BTC at $66,267 and ETH at $3,037 when Sonne got hit. billions in TVL across compound v2 forks and most of them still havent patched the donation vector
Joana compound v2 fork-first development means one design flaw becomes systemic. sonne was first but wont be last, at least 3 live protocols have the same bug
bookmarked. every lending protocol dev should have to pass a quiz on donation attack vectors before they’re allowed anywhere near mainnet deployment tbh
exchangeRateStored round-down looked harmless for years until someone paired it with direct cToken transfers. sonne lost $20M because nobody audited the combination
every Compound v2 fork copied the same vulnerable exchange rate logic. Sonne was just the one that got hit first, there are probably more sitting on the same bug right now
Amir H. every compound v2 fork copied the same exchange rate logic. Sonne was first to get exploited but definitely wont be the last
the step-by-step reproduction at the end is worth bookmarking alone. most writeups skip the actual exploit flow and just handwave
every compound v2 fork that hasnt audited for direct ctoken donations is sitting on a time bomb. sonne was may 2024 and people still havent learned