Incident with non-standard ERC20 deflationary tokens
An incident occurred on Balancer today which allowed an attacker to drain funds from 2 pools that contained tokens with transfer fees (sometimes referred to as deflationary tokens). STA and STONK were the tokens in each pool. Note: this only affects pools where a token has these transfer fees.
https://oko.palkeo.com/0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16fdc08c78106/
A high level description of how this works:
- Flash lend ETH from dYdX and convert to WETH
- Continuously trade WETH & STA in increasing quantities
- On each trade, STA has a transfer fee and the pool expects it receive a balance without the fee.
- After enough calls, the attacker calls
gulp()which syncs the internal pool accounting of a token balance to the actual balance as stored in the token tracker contract - Because the balance of STA is close to zero, its price relative to the other tokens is extremely high and the attacker can now use STA to swap for other assets in the pool extremely cheaply
Although we were not aware this specific type of attack was possible, we have consistently in our docs, discord, and other channels warned about the unintended effects ERC20s with transfer fees could have in the protocol. This is explicitly why STA was not included in the BAL mining whitelist that was recently put together. The system is designed for compliant ERC20’s and when tokens behave unintended ways, bad things can happen. Balancer is a permission-less protocol and broken or malicious tokens will always be able to be added at the contract level.
Next Steps:
- We will begin adding transfer fee tokens to the UI blacklist similarly to what we have done for no bool transfer tokens. Note that these lists will be non-exhaustive and any new tokens can be added to Balancer at any point.
- We will be adding more documentation around the risks of how these pools work and how broken or maliciously designed tokens can potentially drain assets from a pool.
- Balancer has undergone 2 full audits and already has a 3rd planned (before today) that will be starting shortly. We will continue to audit and review the protocol.
