The bZx attacks can be attributed to a number of reasons, one being the use of a single price oracle.
Over the last few days, decentralized trading and lending platform bZx was attacked twice. These attacks resulted in nearly $1 million of profits gained by the perpetrators, as well as lots of Crypto Twitter discussion.
While there are a few issues that led to these exploits, one of the primary concerns is the use of Kyber Network as a single price oracle.
The use of oracles is a hot topic in blockchain and crypto, as they can be a single source of failure in otherwise decentralized finance (DeFi) applications.
Let’s dig into each of the attacks on bZx to better understand what went wrong, the role oracles played in the exploits, and how the oracle problem can be solved.
Overview of the attacks on bZx
The first attack took place on the night of Friday, February 14 (not a great Valentine’s Day for bZx). This was a perfectly timed attack because many of the bZx team members were hacking on projects at ETHDenver.
Anyway, here’s a summary of what the attacker did to execute the exploit:
- Took out a flash loan of 10,000 ETH ($2.7 million) from dYdX
- Used 5,500 ETH as collateral to acquire 112 wBTC on Compound Finance
- Sent 1300 ETH to bZx’s Fulcrum pToken sETHBTC5x, opening a 5x-leveraged short position against the ETHBTC ratio (essentially, shorting ETH in favor of BTC)
- Borrowed 5637 ETH and swapped it to 51 wBTC through Kyber Network’s Uniswap reserve, which spiked the price of wBTC on Uniswap to 3x the norm
- Sold the 112 wBTC for 6871 ETH on Uniswap
- Repaid the flash loan of 10,000 ETH to dYdX from the proceeds
- Reaped profits of about 1,271 ETH (about $350,000)
Read this for a full analysis of the attack by Peckshield.
bZx wound up pausing their network using their admin key. Check out bZx’s post-mortem here.
The second attack occurred in the wee hours of the morning of February 18 (depending on where you live). The full details are still being fleshed out at the time of publishing this post, but this is essentially what the exploiter did (H/T to Larry Cermak’s Twitter thread):
- Took out a flash loan of 7,500 ETH on bZx
- Traded 3,517 ETH on Synthetix for $940,000 sUSD (at an approximate price of $1)
- Used 900 ETH to buy sUSD on Kyber and Uniswap, spiking the price of sUSD to about $2.30
- Borrowed 6,796 ETH on bZx using the sUSD as collateral (this loan was much larger than normal, since the collateral appeared to be much larger than it actually was)
- Repaid the flash loan of 7,500 ETH
- Pocketed 2,379 ETH as profit (about $640,000)
bZx paused their network again to deal with this attack.
Issues that led to the attacks
There are a few issues that allowed these exploits to happen.
The first reason why these attacks are possible is the composability between multiple DeFi platforms such as Kyber, Uniswap, bZx, Compound, and others. These platforms share token liquidity with one another, which allows attackers to 1) use illiquid assets to borrow a large amount of tokens at low cost (specifically, the 5x margin position in Step 3 of Attack #1) and 2) manipulate prices across platforms to facilitate these pump-and-dump exploits.
Next, there was a hidden bug in the bZx smart contract implementation that allowed for undercollateralized positions the attackers took in Step 3 of Attack #1 (and presumably for Step 4 of Attack #2 as well). Basically, there was a sanity check in bZx’s code that inspects whether the transaction position is healthy or unhealthy. This sanity check was bypassed, allowing the exploit to be successful. Again, Peckshield does a great job on analyzing the bug here.
Finally, bZx singularly used Kyber as an oracle for their price feeds.
The attackers were able to manipulate the prices of wBTC and sUSD in Attacks #1 and #2, respectively, on Kyber and Uniswap. Kyber uses Uniswap reserves, so a change in price on Uniswap leads to a change in price on Kyber, which then gets fed into bZx’s smart contracts.
Let’s dig deeper into the problems with using oracles for decentralized financial applications, and how these problems can be solved.
How to solve the oracle problem in decentralized finance
As mentioned before, bZx used Kyber as a single oracle. If you have to rely on a single oracle for your DeFi app, you are sacrificing the decentralized, trustless nature that you’re trying to achieve.
One way to avoid the oracle problem in DeFi is to use a decentralized oracle service.
bZx has already announced that they’ll use Chainlink as a supplement to Kyber for their price oracle. Other decentralized oracle services include Delphi, Oraclize, Band Protocol, Razor, Tellor, and others.
Even though decentralized oracles are a better solution than a single oracle, you’re still depending on external parties to act in an appropriate manner.
A better option is to build your own decentralized oracle.
A great example of this is Augur, a decentralized prediction platform run on Ethereum that allows you to place bets on future events. You can bet on whether Donald Trump will win the 2020 election, who will win the Lakers vs. Celtics game, and much more. (Disclosure: the founder of Augur, Joey Krug, is one of Meter’s investors via Pantera Capital.)
While Augur can rely on an external oracle to provide the results of these events, they’ve chosen to create their own decentralized oracle. They have developed a crowdsourced consensus system where REP (the native token of Augur) holders can vote on the truthful outcome of these events. If other REP token holders disagree with the outcome, they can dispute these votes, and this process is repeated until a reliable output is agreed upon.
If you can avoid using third-party oracles like Augur does, you should do it.
An even better solution is to design your system to completely avoid oracles.
How Meter avoids using oracles in currency creation
Dai, created by MakerDAO, is currently the most decentralized stablecoin. Dai’s value is pegged to the US Dollar, but it is backed by ETH that is locked up in smart contracts.
You can mint Dai by depositing ETH as collateral at a current collateralization ratio of 1.5 (i.e. you would need to deposit $150 worth of ETH to receive $100 worth of Dai). This vehicle is called your Vault.
But if the value of ETH drops below a certain price that threatens the stability of your Vault, your position can be liquidated to cover the amount of Dai issued plus the liquidation fee.
How does the MakerDAO system determine this oh-so-important price of ETH?
An oracle, that’s how.
MakerDAO has built and continues to improve their own oracle. But the fact of the matter is that their system is highly dependent on this oracle to function properly. And as decentralized as this oracle may be, there are risks involved.
The Meter ecosystem, on the other hand, creates the MTR stablecoin independent of oracles.
The system uses Proof of Work, the same consensus mechanism as Bitcoin, to create MTR with the highest level of decentralization and thus no counterparty risk.
There is no collateral necessary to mint currency, no oracle risk, no threat of liquidation, and no regulatory issues.
There is no doubt that the external data provided by oracles is extremely important to the utility of decentralized applications.
As you can see in the bZx attacks, the reliability and accuracy of oracle data is paramount. And if this data can be manipulated, it can break the system.
Decentralized third-party oracles are a good solution. A decentralized oracle specific to the Dapp is even better. Not using an oracle at all is the best.
We don’t believe that a financial system should depend on oracles, and oracles absolutely should not be a part of currency creation.
That’s why we designed Meter the way we did - to create the most decentralized currency in existence.
What do you think of the bZx attacks? What could have been done to prevent them, and do you think they'll have a positive or negative impact on DeFi? Let us know your thoughts in the comments!
We hope you liked this article! If you did, please share it with the share buttons on your left so others can discover it.