Cowrie Research

vow-usdratesetter-usdrate-misconfiguration-vusd-overmint-pool-drain-2024-08-13

11 min read

VOW usdRateSetter usdRate Misconfiguration / vUSD Overmint Pool Drain (2024-08-13)

  • Name: VOW usdRateSetter usdRate misconfiguration / vUSD overmint pool drain
  • Date: 2024-08-13
  • Protocol: VOW / vUSD
  • Chain: Ethereum
  • Category: oracle configuration failure / privileged parameter-testing misconfiguration / burn-mint ratio exploit / AMM drain
  • Loss: about $1.2M, commonly summarized as roughly 175 ETH, 595k USDT, and 5.8M VOW
  • Summary: On 2024-08-13, VOW’s privileged usdRateSetter address 0xbA1be907f532Ff6bb0088279e0f3DCDdD693aC7c temporarily changed the production usdRate between VOW and vUSD from 1 to 100. That parameter directly controlled how much vUSD the VSCTokenManager minted when it received burned VOW. The team later said this was a live mainnet test for upcoming lending-pool and oracle work, that they had themselves sent 1M VOW to the contract expecting 100M v$, and that the dangerous test window lasted only 15–30 seconds. Within two blocks of the public rate change, an attacker flash-borrowed 1,486,625 VOW from the VOW/WETH Uniswap pool, sent it into VSCTokenManager 0x184497031808F2b6A2126886C712CC41f146E5dC, and received 148,662,529 vUSD instead of the roughly 1.49M vUSD the normal rate would have allowed. They then used the overminted vUSD to drain the VOW/vUSD pool for VOW, repaid the flash loan, and dumped the remaining inventory through the VOW/USDT and VOW/WETH pools.
  • Trigger / entry point:
    • The live production usdRateSetter changed usdRate from 1 to 100 in transaction 0xda2a8568a5a210fdfb51880f4e8c91165ea122ada9977a4b11598d56782d49a5.
    • Public reporting after the exploit quoted the team as saying the rate change was part of testing for new lending-pool and oracle functions rather than a hostile key takeover.
    • VOW’s own statement said the team amended the USD rate and sent 1M VOW into the contract as a live test, expecting the resulting 100M v$ to be burned immediately afterward.
    • CertiK’s reconstruction noted the same setter had also performed earlier temporary rate changes, including to 150 on 2023-11-22 and to 200, then 5, then back to 1 on 2024-03-01, which makes the August event look like repeated production-side experimentation rather than a one-off accidental touch.
    • VSCTokenManager treated the live usdRate as authoritative when converting burned VOW into freshly minted vUSD.
    • The attacker had already deployed exploit contract 0xB7F221e373e3F44409F91C233477ec2859261758 110 days earlier, suggesting they were monitoring the rate-setting surface and waiting for a production misconfiguration.
  • Root cause:
    • VOW left a production-critical conversion parameter writable by a privileged address and then exercised that write path on mainnet with a wildly non-economic test value.
    • The protocol had no effective staging boundary between testing a new rate and publishing final mint truth.
    • Once usdRate = 100 was live, the system did exactly what it was configured to do: overmint vUSD against burned VOW at a 100x ratio.
    • The downstream AMM liquidity then turned that protocol-self-published fiction into realizable value.
  • Exploit path:
    1. The usdRateSetter set usdRate to 100 on the live VOW system in tx 0xda2a8568a5a210fdfb51880f4e8c91165ea122ada9977a4b11598d56782d49a5.
    2. Within two blocks, the attacker used exploit contract 0xB7F221e373e3F44409F91C233477ec2859261758 and main exploit transaction 0x758efef41e60c0f218682e2fa027c54d8b67029d193dd7277d6a881a24b9a561.
    3. They flash-borrowed 1,486,625 VOW from the VOW/WETH Uniswap pool.
    4. They transferred the borrowed VOW into VSCTokenManager, which burned the tokens and minted 148,662,529 vUSD because the live rate had been set to 100.
    5. They swapped that vUSD through the VOW/vUSD pool, pulling out roughly the entire VOW side of that market.
    6. They repaid 1,490,198 VOW to the flash-loan source, then routed the residual VOW into the VOW/USDT and VOW/WETH pools to cash out into stronger assets.
    7. A second exploit transaction 0xb569340f147cb6d5722490221ba65950a870aaa4db6ab835b8aa128c5dee36b3 and later sale transaction 0x4b439b82c8878644cd809cfafa6e5c056518a54ea4df098eb1fed9d1cce5ca5f completed the drain path.
  • What the attacker needed to be true:
    • The privileged usdRateSetter path had to remain live on production and capable of publishing an extreme conversion ratio immediately.
    • VSCTokenManager had to mint vUSD from burned VOW directly off that mutable parameter without any sanity bound, timelock, or pause.
    • The VOW/vUSD pool needed enough depth for the attacker to convert the counterfeit vUSD into real VOW inventory.
    • Secondary VOW/USDT and VOW/WETH liquidity needed to remain available so the attacker could leave the system with stronger assets after repaying the flash loan.
  • Technical anatomy worth remembering:
    • This was not classic oracle manipulation where the attacker moved an external market. The protocol itself published the bad exchange ratio.
    • The exploit also was not mainly about stealing admin keys. Public reporting points to a privileged but intentional write with production consequences: a testing action crossed directly into solvency-critical mint logic.
    • VSCTokenManager is the key accounting seam. The attack only worked because burned VOW immediately became freshly minted vUSD at the mis-set rate.
    • Public reproductions route the borrowed VOW through the attacker EOA before transferFrom(..., VSCTokenManager, ...), which is a useful reminder that the monetizable unit was not abstract rate changed state but the exact account path that VSCTokenManager credited with newly minted vUSD.
    • The attacker did not need to hold inventory up front. The AMM pools financed both the initial VOW borrow and the eventual exit once the protocol had overissued vUSD.
    • VOW’s own post-incident message described a 15–30 second testing window on production. That detail matters because it shows the protocol had no real distinction between we are momentarily experimenting with a rate and the system now honors this rate as money-good mint truth.
    • The 110-day gap between exploit-contract deployment and execution is analytically useful: it suggests the exploiter was watching the privileged rate surface and waiting for an operator mistake rather than discovering the opportunity mid-block.
    • VOW’s public summary said the bot acquired around 20M VOW and turned it into nearly v$2B, while onchain reconstructions cleanly document at least the first major leg as a 1,486,625 VOW -> 148,662,529 vUSD conversion. The safest preserved lesson is the shape of the issuance error, not the distressed-team headline numbers.

Three issuance-truth promotions this incident collapsed

  1. A privileged rate experiment existed

    • The production usdRateSetter was allowed to write a new usdRate, and operators were using that same live lever for testing.
    • That was already stronger than we are only simulating a future parameter, but it was still weaker than this new ratio now deserves to define live mint output.

  2. That experiment was promoted into canonical mint-conversion truth

    • VSCTokenManager immediately treated usdRate = 100 as the authoritative burn-to-mint ratio for VOW -> vUSD conversion.
    • This was the decisive publication step: a transient operator test value became the number that determined how many fresh claims the system would issue.

  3. That printed issuance truth still carried full external monetary authority

    • The newly overminted vUSD could still drain the VOW/vUSD pool and then exit through the VOW/USDT and VOW/WETH pools.
    • This final promotion is where a local operator-published accounting fiction became real extractable value.
  • Representative transactions and artifacts:
    • usdRate change tx: 0xda2a8568a5a210fdfb51880f4e8c91165ea122ada9977a4b11598d56782d49a5
    • Main exploit tx: 0x758efef41e60c0f218682e2fa027c54d8b67029d193dd7277d6a881a24b9a561
    • Secondary exploit tx: 0xb569340f147cb6d5722490221ba65950a870aaa4db6ab835b8aa128c5dee36b3
    • Attacker sale tx: 0x4b439b82c8878644cd809cfafa6e5c056518a54ea4df098eb1fed9d1cce5ca5f
    • Exploit-contract deployment tx: 0x6acda6ac1d7fb2a6c0c79707b0353855955ee550be8112c49490ccf6d77cc814
    • VOW token contract: 0x1BBf25e71EC48B84d773809B4bA55B6F4bE946Fb
    • VSCTokenManager: 0x184497031808F2b6A2126886C712CC41f146E5dC
    • usdRateSetter: 0xbA1be907f532Ff6bb0088279e0f3DCDdD693aC7c
    • Attacker EOA: 0x48de6bF9e301946b0a32b053804c61DC5f00c0c3
    • Exploit contract: 0xB7F221e373e3F44409F91C233477ec2859261758
    • VOW/WETH pair: 0x7FdEB46b3a0916630f36E886D675602b1007Fcbb
    • VOW/vUSD pair: 0x97BE09f2523B39B835Da9EA3857CfA1D3C660cBb
    • VOW/USDT pair: 0x1E49768714E438E789047f48FD386686a5707db2
  • Response / mitigation:
    • VOW publicly said the rate change had been part of testing around new lending-pool and oracle functionality, that the dangerous window lasted only 15–30 seconds, and that the project was evaluating options to unwind the disruption.
    • Post-incident discussion centered on reducing vUSD supply and unwinding the damage, but the deeper lesson is that production price-setting and conversion-parameter authority should never double as an ad hoc test harness.
    • The incident highlighted the need for sanity bounds, timelocks, isolated staging environments, staged preview/activation flows, and narrowly scoped emergency controls around privileged mint-rate changes.

Pattern tags

Why the exploit worked

  • VOW let one authenticated production setter publish a 100x burn-to-mint ratio directly into live mint logic. The decisive bug was not attacker manipulated an external price; it was the protocol treated an operator test value as final money-good conversion truth.
  • VSCTokenManager had no hard plausibility band, canary state, or second-step activation between usdRate changed and fresh vUSD may now be minted against burned VOW. Once usdRate = 100 landed, the overmint path was already complete.
  • External AMM liquidity converted the local accounting fiction into realizable value. The attacker did not need VOW inventory up front; the VOW/WETH pool financed the borrow, the VOW/vUSD pool honored the counterfeit vUSD, and the VOW/USDT / VOW/WETH pools completed the exit into stronger assets.
  • The attack window was short but still economically infinite in practice because monetization fit inside the same transaction bundle. A 15–30 second production experiment is still an eternity if the changed parameter already controls mint authority.

Detection and audit pivots

  • Alert on production-impossible step changes for mint-critical ratios: if a burn-to-mint parameter jumps from 1 to 100, detection should fire before or at the same time as any mint event that can monetize the new state.
  • Inventory every path where a privileged parameter write immediately changes issuance, redemption, collateral, or liquidation truth. Here the key audit seam was not only who can call usdRateSetter, but which contract starts honoring that value as reserve-spend or mint authority.
  • Correlate privileged parameter changes with immediate issuance spikes and pool-balance distortions. A sudden VOW -> vUSD mint explosion plus same-block reserve drain from the paired VOW/vUSD market is the signature to watch, not only the setter call alone.
  • Review prior operator behavior around the same setter. Repeated historical usdRate experiments were already evidence that production and testing shared one lever, which is itself a red flag even before the exploiter appears.

Failure-prevention checklist

  • Separate preview / simulate / observe from activate live mint authority; operators should be able to test a candidate conversion ratio without any production path honoring it for issuance.
  • Put machine-enforced step-size and semantic bounds on mint-critical rate changes so absurd but authenticated values fail closed before any user can burn into freshly overissued claims.
  • Default fresh or changed conversion paths into bounded authority states: mint caps near zero, borrow / swap routes paused, or redemption disabled until the new parameter survives a canary window.
  • Give operators a narrow freeze path for the exact issuance surface that changed so one bad conversion parameter can be quarantined faster than AMM liquidity can cash it out.
  • Treat test setters, deployment scripts, and generated parameter payloads as balance-sheet infrastructure. If they can redefine what one burned unit is worth, they deserve the same review rigor as custody or mint contracts.

Audit prompts

  • What exact balance-sheet object does this setter publish if activated right now: a mint ratio, collateral mark, liquidation threshold, or reward issuance budget?
  • Can operators preview the downstream issuance effect of a new parameter without granting it live mint authority on production?
  • Which hard invariants stop an authenticated but absurd rate change from turning one burned token into a wildly larger redeemable claim?
  • If a changed conversion ratio is wrong, how fast can the protocol freeze just that mint path relative to the fastest AMM or borrow-side cash-out rail?
  • Does any temporary test, migration, or just for a few seconds workflow still reuse the exact same lever that production uses for final balance-sheet truth?

Lessons that should already be standard

  • A production rate setter that controls mint output is already custody-grade infrastructure. Trusted operator is not a substitute for bounded authority.
  • A same-mainnet test is still a live exploit surface when the tested value immediately defines how many fresh claims the protocol will honor.
  • Overissuance incidents are not safely local just because the bad number originated inside the protocol. If AMMs or sibling reserves still honor the printed claim, the accounting mistake is already spendable.
  • One-block monetization should be the baseline threat model for any authenticated parameter that touches mint, collateral, liquidation, or reward truth.
  • We intended to revert or burn it later is not a control. Healthy systems stop bad publication before outside liquidity can treat it as real.

Why this incident matters

  • It is a clean example of a protocol self-inflicting a monetizable pricing error without any external market manipulation.
  • It preserves the operational subfamily where a privileged parameter is not stolen or spoofed; it is used directly in production under unsafe assumptions.
  • It also shows how quickly AMM liquidity can convert a local conversion rate is temporarily wrong mistake into irreversible reserve loss.

Internal linkages

Control surface

Graph View

Backlinks