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.
some info on the developing @harvest_finance exploit 🧐 ~$24MM exploited 👉etherscan.io/tx/0x53fae6f1d… ~$2.5MM sent back to deployer 👉 etherscan.io/tx/0x25119cd54… hacker cashed out almost all of it via renBTC and tornado in the last ~1 hour 👉 app.zerion.io/0x3811765a53c3… h/t @jiecut42
October 26th 2020
118 Retweets254 Likes
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,
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.