Here’s Why aUSD Base Layer Security Isn’t Enough in Crypto
Following an attack on one of the platform’s liquidity pools, a new type of stablecoin (aUSD) built on a platform (Acala) that was built on a blockchain (Polkadot) fell from its $1 peg to $0.009 (which rounds to zero in my opinion). If the words that follow “attack on” appear unusually specific, that’s because they are. Acala was not directly attacked, hacked, or thwarted. Rather, the iBTC/aUSD liquidity pool, which was built on top of Acala, was directly attacked, hacked, and thwarted. The exploit was successful, and bad actors were able to generate billions of aUSD for themselves. This influx of new aUSD crushed the stablecoin’s price solely through massive supply dilution.
The aUSD has since recovered, but only after the Acala community voted to destroy the billions of aUSD that were incorrectly minted. Let’s ignore the fact that the minted aUSD wasn’t actually improperly minted, and the need for a centralized force to intervene to correct this error, and instead consider how cryptocurrency protocols are only as secure as what’s built on top of them. Break everything by moving quickly. aUSD isn’t the first cryptocurrency to be broken or hacked (for example, Ronin for $625 million and Wormhole for $326 million) – it’s just the flavor of the week. But let’s be clear: aUSD didn’t necessarily stop working, and the attackers didn’t rappel into a building to physically break into the mainframe.
Instead, aUSD performed as expected. The liquidity pool was governed by buggy code, and that buggy code allowed attackers to print billions of aUSD. We should do the same here, because exploit, rather than hack, more accurately describes exploiting poorly written code. Of course, exploits aren’t limited to protocols you’ve never heard of. Polkadot, for example, is the foundation of Acala. Polkadot’s native currency, DOT, is the 11th most valuable cryptocurrency, but Polkadot is not Ethereum. Except that Ethereum had an exploit in 2016 dubbed “The DAO Attack,” which resulted in a messy chain split (look up Ethereum Classic) and a loss of credibility.
This is useful ammunition for boomer Bitcoin developers who are adamant about not changing anything about Bitcoin for fear of breaking the protocol. I’m not here to defend the halting of new Bitcoin or other cryptocurrency protocol development, but rather to provide some color as a warning given how easy it is to draw a parallel between Silicon Valley tech companies and crypto. The Silicon Valley tech ethos is (was?) “move fast and break things,” but the stakes are simply higher for cryptocurrency. If a Salesforce developer introduces a bug that negatively impacts a customer’s experience, patching that bug really only costs time to fix the mistake (there may be a reputational hit, but a company can get through a few mistakes a year without issue).
Not so in the crypto world. If a bug is introduced into a crypto protocol via a new shiny product, layer, smart contract, or whatever, and is eventually exploited, the damage could be widespread and irreversible. Things should be built on crypto protocols, and the protocols themselves should be upgraded with caution. All of this is to say that it’s fine to move quickly and break everything unless you don’t want to break everything.