In Crypto, Base Layer Security Isn’t Enough

Earlier this week a new type of stablecoin (aUSD), built on a platform (Acala), which itself was built on a blockchain (Polkadot), fell from its $1 peg to $0.009 (which rounds to zero as far as I’m concerned), following an attack on one of the platform’s liquidity pools. If the words following “attack on” seem to be oddly specific, that’s because they are.

Acala wasn't attacked, hacked and thwarted directly. Rather, the iBTC/aUSD liquidity pool, something built on top of Acala, was attacked, hacked and thwarted directly. The exploit was successful and allowed bad actors to create billions of aUSD for themselves. This influx of new aUSD crushed the price of the stablecoin strictly through immense supply dilution.

This article is excerpted from The Node, CoinDesk's daily roundup of the most pivotal stories in blockchain and crypto news. You can subscribe to get the full newsletter here.

aUSD has since recovered, but only after the Acala community voted to destroy the billions of the improperly minted aUSD. Never mind that the minted aUSD wasn’t really improperly minted and never mind the need for a centralizing force to come in to fix this mistake, let’s instead look at how cryptocurrency protocols are only as secure as what’s built on top of them.

aUSD isn’t the first crypto thing that has been broken or hacked (e.g. Ronin for $625 million and Wormhole for $326 million) – it’s just the flavor of the week. But we should be clear here: aUSD didn’t necessarily stop working, and the attackers didn’t rappel into a building to physically break into the mainframe or something.

Instead, aUSD worked as designed. Buggy code governed the liquidity pool, and that buggy code allowed attackers to print billions of aUSD.

This is the same as the two other examples provided – with each CoinDesk article accurately using the term “exploit” to describe the attacks. We should do the same here, because exploit, rather than hack, more accurately defines taking advantage of poorly constructed code.

Exploits, of course, aren’t isolated to protocols you’ve never heard of. Acala is built on Polkadot, for instance. Sure, Polkadot’s native currency DOT is the 11th-most valuable cryptocurrency, but it’s not like Polkadot is Ethereum. Except Ethereum did have an exploit in 2016 – colloquially called The DAO Attack – which led to a messy chain split (look up Ethereum Classic) and a loss of credibility.

This is good ammo for the boomer Bitcoin developers who are hellbent on changing absolutely nothing about Bitcoin because they’re afraid that would break the protocol. I’m not coming here in defense of halting new development of Bitcoin or other cryptocurrency protocols, but rather, I simply want to provide some color as a warning given how easy it is to draw a parallel to Silicon Valley tech companies and crypto.

The ethos of Silicon Valley tech is (was?) to “move fast and break things,” but the stakes are simply higher for crypto. If a developer at Salesforce introduces a bug that hurts a customer’s experience, patching that bug really comes only at the expense of time to fix the mistake (maybe there’s a reputational hit, but a company can get through a few mistakes a year with no issue).

See also: Calling a Hack an Exploit Minimizes Human Error | The Node

Not so in crypto. If a bug is introduced to a crypto protocol through a new shiny product or layer or smart contract or whatever and is eventually exploited, the damage could spread far and wide and could be irreversible. Things should be built on crypto protocols and the protocols themselves should be upgraded, but that should be done with care.

All said, the main point is: It’s fine to move fast and break everything, unless you don’t want to break everything.