Another day, another DeFi exploit. In case you missed it, an attacker was able to drain around $24 million out of Harvest.Finance (a popular yield farming app) and then they sent $2.5 back to the deployer address (the one that the Harvest team controls). This theme of stealing funds and then returning a portion of them is quite funny (and not in the βha haβ sense - more like the βthis is so bizarreβ sense).
Here is a step by step on how the attack worked (as I understand it):
Flash loan $50 million worth of USDT and USDC from Uniswap
Trade $10 million USDT to USDC in the Curve Y pool which increases the exchange rate for USDT/fUSDT
Deposit $40 million into fUSDT
Swap $10 million USDC to USDT using the Curve Y pool (which means fUSDT is now worth less USDT)
Withdraw USDT from fUSDT at a discount
Repeat until all funds drained (though the attacker stopped at $24mil)
This is the danger of the βmove fast and break thingsβ approach that some developers tend to take in crypto - especially when their protocol grows very quickly and attracts a lot of attention. Harvest.finance went from $150 million to over $1 billion value locked in just the month of October alone which obviously made it a large honeypot for attackers. The Harvest team did have multiple audits under their belt but I believe that if they moved slower, they may have been able to catch this exploit during the research and development phase of their contracts (itβs the same exploit that was patched on Yearnβs contracts a few weeks ago). Of course, optimizing for every attack vector is impossible but moving slower increases your chances of spotting exploits before they end up on mainnet.
This kind of thing is also known as the βtest in prodβ approach and is obviously something that the Yearn project played around with early-on. Ultimately though, this approach was a negative for the project because of what happened with the Eminence exploit. Since then, the Yearn/YFI community and core team have opted for a slower development process in order to ensure that theyβve covered all of their bases when deploying new contracts. Iβve seen people criticise this approach and become disappointed that Yearn is βtoo slowβ to ship new products but this is short-sighted and I believe, as always, that playing long-term games is the right approach. Itβs much better to take a slow and methodical approach to smart contract development than to lose all of your users money because you were reckless.
If we take a look at the slow and methodical process of other projects - such as Compound and Uniswap - a common theme reveals itself; these projects have never been hacked or exploited (that I know of, at least). Even Maker has had a very clean history with only one instance of something going wrong (the oracle/keeper bot failure on Black Thursday). These projects havenβt suffered from moving slower either - they are all in the top 5 as measured by TVL and they all have very active communities.
The lesson in all of this is that it is critical for developers creating smart contracts to take the slow and methodical approach rather than rush to get their products out. The reason for this should be obvious to most but basically if you are handling hundreds of millions of dollars of usersβ money, you want to be damn sure that your product is as secure as it can be - this is your moral responsibility as a developer. I do hope that after todayβs events, the βmove fast and break thingsβ approach is behind us - though, unfortunately, Iβm not counting on it.
Have a great day everyone,
Anthony Sassano
Enjoyed this piece? You can get a fresh one sent straight to your inbox every week day by simply hitting that subscribe button below!
All information presented above is for educational purposes only and should not be taken as investment advice.