DeFi hacks — when is it criminal, when is it helpful?

Tara Annison
5 min readOct 28, 2022

In a recent Blockworks newsletter, Byron Gilliam, raised a really important discussion point around the narrative for all the DeFi hacks we’ve been seeing and it resonated with me because I often struggle to decide whether something really is a malicious ‘hack’ where we should demonise the perpetrator, or if it’s the result of poor build/design and therefore the responsibility of project team.

This has certainly been the case with the recent Mango Market situation where self-doxx’d attacker Avraham Eisenberg explained his actions as “running profitable strategies in crypto, with very attractive risk structures”.

https://deepfivalue.substack.com/p/how-our-team-makes-millions-in-crypto

He doesn’t see it as hacking in the way that many in tradfi, and some in crypto do. He sees it as utilising dApps in the way they have been built (e.g he’s not injecting malicious code or using social engineering) but he’s finding clever trading strategies which will net a solid income.

He’s also been incredibly transparent about other dApps he sees trading strategies/holes in and is looking to execute on, and even created his own sh*tcoin to highlight the naïveté still in the crypto markets from investors and bots who don’t assess the value in a project before putting their funds into them.

This mirrors one of my all time favourite Initial Coin Offerings — Useless Ethereum Token (UET) which launched in the 2017 ICO boom and even though it was completely transparent about the fact the team were just going to take the money and run — over $40,000 was invested in the token in just 3 days! Literally madness.

However Avraham’s actions poses at least a philosophical problem since in the tradfi space they would most likely be illegal — frontrunning, market manipulation, and holding a corporation to ransom (as he somewhat did with the DAO vote post hack:) https://www.linkedin.com/posts/tarannison_mangodao-mangomarkets-defihack-activity-6985917429205901313-zVBp?utm_source=share&utm_medium=member_desktop

but crypto =/= tradfi

All of this information is on chain and since all trades can be viewed in the mempool pre-execution, arguably this perhaps isn’t even MNPI. Likewise with the category of most crypto assets still being undefined or defined differently between jurisdictions, there’s a question mark on what existing financial markets regulations could or should apply here. I certainly don’t have the answers but I worry if we just try to copy and paste tradfi regulation across then we risk creating broken, unenforceable and disproportionate regulation. Existing regulation simply doesn’t recognise the concept of maximal extractable value (MEV), the radical transparency we have from blockchains, the democratisation of control through smart contracts, and the 1,000mph innovations in the space like ZK-rollups, encrypted mempools (e.g Flashbot’s SUAVE), atomic cross chain swaps, etc etc

Another stark difference between tradfi and crypto is the widespread use of bug bounties. The aim is to incentivise hackers to report exploits for a reward, rather than utilise them to make off with funds. In crypto this takes two forms, 1) official bounties being claimed through established procedures, and 2) hackers offering a portion of ‘stolen’ funds back in exchange for no criminal proceedings. In tradfi, the latter would likely end up with a prison sentence!

Byron puts this really nicely in his newsletter:

“You cannot, for example, break into someone’s house, steal 5% of their stuff and then expect to be thanked for demonstrating the flaws in the homeowner’s security system.”

So we find ourselves in a situation where we have on one hand bug bounty finders helping to keep protocols working as originally intended; and on the other hand, nefarious actors looking to cause chaos (and likely financially profit) by maliciously accessing services. But there’s also an increasingly growing middle ground of actors who might be financially motivated, driven by code/industry improvements, or just curious, and who will pick holes in the design and implementation of dApps.

Are they criminals, or are they unofficial auditors?

Are they good if they give most of it back and bad if they keep the lion’s share for themselves?

As with many things in crypto, it’s all a bit TBC. But I hope that as an industry we can come up with a solution before traditional regulation is imposed upon us and which will undoubtedly not utilise the opportunities this grey area provides.

Before I close out my thoughts on this, I also wanted to highlight some historical context for those newer to the space. It’s worth noting that whilst DeFi, specifically bridges and borrowing & lending protocols, seem to be the flavour of the month for ‘criminals’, earlier on in crypto’s history you could hardly go a month without a centralised exchange being hacked. The most notable is perhaps still Mt Gox in 2011 which saw1.35m bitcoin stolen (now with a street value of $27.7billion! This is followed by the less well known BitFloor hack of 2012 where 24,000BTC were taken. Since these very early days, most CEXs have had some level of hack situation. Poloneix in 2017 saw 97 BTCs disappear, Bitstamp in 2015 was hacked for $5m, Bitfinex users lost $72m (120,000 BTC!) from the now-famous 2016 hack, 2018 started awfully for Coincheck with $523m worth of NEM being pilfered, soon followed by Bitgrail who lost $170m in NANO tokens, and even #1 exchange by volume, Binance hasn’t been immune when it was hacked for $40m in 2019.

There’s countless more CEX hacks I could mention here but I highlight this to show that whilst many users sadly lost funds through this nefarious activity, the result was strengthened security at exchanges, and better understanding from consumers about keeping their funds safe.

Possibly the actions across DeFi at the moment will help to see a similar trend where we have more robust code audits, more carefully created dApps and better consumer awareness about the risks involved in using some of the services.

Originally published at https://www.linkedin.com.

--

--