Polkadot’s decentralized finance (DeFi) hub Acala suffered a major attack on its newly launched liquidity pool on Sunday. The exploit allowed the hacker to mint more than 1.2 billion aUSD, the project’s stablecoin.
Shortly after the hack, the Acala team updated users on Twitter, noting that the exploit originated from a “misconfiguration of the iBTC/aUSD liquidity pool.” The misconfiguration has now been rectified, according to the project.
Acala Suspends On-chain Activities
Onchain data reveals that most of the minted stablecoins are still in the Acala account. The attacker swapped a tiny fraction of the stablecoins for Acala’s native token ACA and four other tokens. At the time of writing, the account was holding about $1.27 billion worth of aUSD, representing more than 99% of the minted tokens.
While the Acala community is yet to make a final decision on the exploit, the team noted that it had suspended the accounts involved from transferring the tokens.
According to the project, on-chain activities such as swaps and cross-chain messaging have also been halted for other users until further notice. The protocol noted that its oracle pallet was also suspended, so users do not have to worry about forced liquidation.
Meanwhile, aUSD, the first stablecoin on Polkadot, reacted negatively to the incident and lost its USD parity. After dropping by almost 50% to a trading price of $0.57, the stablecoin traded at $0.89 at press time.
Acala’s Attack Might Not be the End
Although Acala has rectified the misconfiguration in its pool, the incident adds to the number of decentralized applications (dApps) that have fallen victim to hackers who always look out for smart contract bugs to exploit.
Victor Young, the founder of Analog, a layer-0, proof-of-time (PoT)-based project, commented on the Acala hack, noting that Polkadot is “secure by design” due to its relay chain, but the same cannot be said about parachains
He stated that such dApp exploits might occur in the future if smart contract developers do not regularly check their codes.
“In my view, we’ll continue to see more of these attacks because many dApp developers don’t put in the legwork when defining their code’s security properties. Even if the smart contract is audited, the code may not be foolproof. In this regard, developers and QA experts need to continuously evaluate to ensure the code achieves its objectives,” he said.