Studying past smart contract exploits is excellent for becoming a better Solidity dev. I've spent some time recently reviewing many of the exploits that have occurred over the last couple of years. Understanding the root cause of a hack is a great way to learn how to think differently about writing code. It also gives you a better intuition for which components are most critical when looking at new code bases. I recommend anyone who wants to improve their Solidity game to go through past exploits on @RektHQ or check out the @phylaxsystems docs, where we have breakdowns of hacks and how assertions could have prevented them. By studying these past hacks, I've realized that often the exploits are possible due to missing checks in the code or incorrect calculations that lead to protocols entering states they're not intended to be in. Once the exploit has happened, the bug often seems obvious. We need to ensure that protocols have an easier time identifying these. Many protocols would benefit from spending time defining invariants and ensuring that these can't be violated. Writing assertions is a great way to make sure that these invariants can never be violated. The latest exploit I spent time looking into was the Abracadabra exploit from March 2025 where ~$13m was lost: The Bug: sendValueInCollateral() extracted real tokens but forgot to update internal accounting variables The Exploit: orderValueInCollateral() kept reporting the same collateral value even after tokens were removed Result: Attacker borrowed against "phantom collateral" repeatedly until funds were drained An assertion that checks the simple invariant that the "reported collateral" matches the "actual collateral" would have prevented the hack.