Explained: The Vow Hack (August 2024)

In August 2024, the Vow token contract was the victim of a hack. The attacker took advantage of the project’s smart contract testing process to mint v$2 billion, which they then sold, creating losses of an estimated $1.2 million.

Inside the Attack

The Vow hack was made possible by the project testing changes to its smart contract live on the mainnet. At the time of the hack, the team amended the rate-setting formula within its smart contract for test purposes. The test was to see if 1 million VOW would produce v$100 million. This testing was designed to support an effort to mint new tokens for the project’s lending pool and oracle.

However, the transactions to change the rate, test the change, and revert the change were submitted to the Ethereum blockchain as separate transactions. This created a window for an attacker to take advantage of the modified rate.

In the 15-30 seconds during which the rate change was in place, a bot took 20 million VOW tokens from Uniswap and submitted them to the Vow contract, creating v$2 billion. These were then sold back to the pool on Uniswap, devaluing the token to the attacker’s benefit.

The Vow team took a couple of measures to address the issue. One was for the Vow Foundation to purchase over v$700 million. Additionally, increasing the project’s v$ voucher burn rate (VSR) burned about 10% of the v$1 billion that was maliciously minted as of August 14.

Lessons Learned from the Attack

The Vow hack demonstrates the potential risks of performing critical testing on the mainnet rather than a testnet. The changes to the project’s rate setter were only intended to be active for 15-30s (1-2 Ethereum blocks); however, this was enough of a window for an automated bot to identify and exploit the change. In effect, this was a price manipulation exploit that the protocol performed on itself that an attacker then took advantage of.

When testing changes to smart contract code, it’s always best to do so on a testnet or as part of a single transaction where changes are made and reverted in the same transaction. Otherwise, there’s always the potential that an attacker could frontrun the transaction, as demonstrated here. For help in testing your contract’s functionality and security in a secure and controlled fashion, get in touch with Halborn.