DEV Community

ohmygod
ohmygod

Posted on

The Venus Protocol Donation Attack: How 9 Months of Patience and 3 Lines of Missing Code Led to a $3.7M Extraction

#security #blockchain #web3 #defi

TL;DR

On March 15, 2026, Venus Protocol on BNB Chain suffered a $3.7M exploit from a donation attack that bypassed supply caps on the low-liquidity THE (Thena) token. The attacker spent 9 months accumulating 84% of Venus's THE supply cap, then used a direct token transfer to the vTHE contract to inflate the exchange rate — a known vulnerability class in Compound-forked lending protocols. The protocol was left with $2.15M in bad debt.

This wasn't sophisticated. It was patient.

The Setup: 9 Months of Quiet Accumulation

Starting in June 2025, the attacker moved 7,400 ETH through Tornado Cash and began systematically buying THE tokens. Over nine months, they accumulated approximately 84% of Venus's 14.5 million THE supply cap — roughly 12.2 million tokens.

This is the part that should alarm every DeFi protocol: no alerts fired. A single entity quietly cornered the market on a listed collateral asset, and the monitoring systems didn't flag it.

Red Flags That Were Missed

  • Tornado Cash-sourced funds flowing into a single accumulation pattern
  • One address holding a dominant share of a listed collateral token
  • Gradual approach toward the supply cap over months
  • Concentration risk in a low-liquidity asset

The Attack: Donation-Based Supply Cap Bypass

The core vulnerability is elegant in its simplicity. Venus (like all Compound forks) tracks deposits through a minting mechanism — you deposit THE, you receive vTHE. The supply cap limits how many THE tokens can be deposited through this normal pathway.

But what happens when you directly transfer THE tokens to the vTHE contract?

// The normal path (supply cap checked)
function mintInternal(uint mintAmount) internal {
    // ✅ Supply cap check happens here
    comptroller.preMintHook(address(this), minter, mintAmount);
    // ... minting logic
}

// The donation path (NO supply cap check)
// Attacker simply calls: THE.transfer(address(vTHE), amount)
// This increases the contract's THE balance without minting vTHE
// Result: exchange rate inflates
Enter fullscreen mode Exit fullscreen mode

The exchange rate for a cToken/vToken is calculated as:

exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply
Enter fullscreen mode Exit fullscreen mode

When you "donate" tokens directly, totalCash increases but totalSupply stays the same. The exchange rate spikes. If you already hold vTHE from a previous legitimate deposit, your position is now worth far more than what you deposited.

The Attack Flow

  1. Deposit THE normally → receive vTHE (within supply cap)
  2. Donate THE directly to vTHE contract → bypass supply cap, inflate exchange rate
  3. Collateral position inflates → attacker's THE collateral now valued at 53.2M THE (3.7x the supply cap)
  4. Borrow liquid assets → BTC, CAKE, BNB, USDC against inflated collateral
  5. Buy more THE → low liquidity means price spikes from ~$0.27 to ~$5
  6. Repeat → synchronized with oracle price updates to maximize borrowing power

The result: $3.7M extracted in BTC (20), CAKE (1.5M), and BNB (200).

Why This Bug Class Won't Die

The donation attack on Compound-fork lending protocols is not new. It's been documented extensively:

  • Hundred Finance (2023) — similar exchange rate manipulation
  • Venus ZKSync deployment (Feb 2025) — same donation vector, $700K bad debt
  • Venus BNB Chain (Mar 2026) — the incident we're discussing

So why does it keep happening?

1. The Compound Codebase Assumption

The original Compound design assumed that tokens would only enter the contract through the mint() function. Direct transfers weren't considered in the exchange rate security model. Every fork inherits this assumption unless explicitly patched.

2. Supply Caps Are Incomplete Guards

Supply caps only gate the mint() pathway. They create a false sense of security — teams think "we've limited exposure to 14.5M THE" when in reality, the effective exposure is unbounded through direct transfers.

3. Low-Liquidity Assets Are Force Multipliers

The attack economics only work when:

  • The attacker can corner a significant portion of the supply
  • Price impact from buying is high (low liquidity)
  • Oracle updates create exploitable windows

Listing low-liquidity tokens as collateral is essentially handing attackers a loaded gun.

The Three Lines of Defense (All Failed)

Defense 1: Supply Cap Enforcement

Expected behavior: Limit collateral exposure to 14.5M THE
Reality: Bypassed through direct token transfer
Fix: Track balanceOf changes independently; reject exchange rate changes that exceed a threshold between blocks

Defense 2: Liquidation Mechanism

Expected behavior: Liquidators would reduce the position before bad debt accrued
Reality: No liquidator could absorb 53.2M THE — the market depth didn't exist
Fix: Implement protocol-level position size limits relative to on-chain liquidity; auto-pause markets when position concentration exceeds safe thresholds

Defense 3: Monitoring and Circuit Breakers

Expected behavior: Alert on anomalous collateral concentration
Reality: 9 months of accumulation went undetected; no circuit breaker fired
Fix: Real-time monitoring for collateral concentration; automated market pauses when single-entity exposure exceeds X% of supply cap

Defensive Patterns: What Lending Protocols Should Implement

Immediate Fixes 

// 1. Track and validate exchange rate changes
modifier validateExchangeRate() {
    uint rateBefore = exchangeRateStored();
    _;
    uint rateAfter = exchangeRateStored();
    require(
        rateAfter <= rateBefore * MAX_RATE_CHANGE / PRECISION,
        "Exchange rate manipulation detected"
    );
}

// 2. Account for direct transfers in supply cap
function effectiveSupply() public view returns (uint) {
    return totalSupply * exchangeRateCurrent() / 1e18;
}
Enter fullscreen mode Exit fullscreen mode

Architectural Improvements

  1. Liquidity-Adjusted Collateral Factors — Don't assign the same collateral factor to THE (avg daily volume: $2M) as you would to ETH (avg daily volume: $20B). The factor should reflect how quickly a liquidation could actually execute.

  2. Concentration Limits Per-Account — No single account should hold more than X% of a market's total supply. This prevents the accumulation phase entirely.

  3. Oracle Manipulation Resistance — Use TWAP with outlier rejection. Venus's oracle updated in sync with the attacker's buys — a TWAP with a longer window would have dampened the price inflation.

  4. Automated Market Suspension — When any of these conditions are met, auto-pause the market:

    • Single account holds >30% of supply
    • Exchange rate changes >5% in a single block
    • Collateral value exceeds on-chain liquidatable depth by >2x

The Uncomfortable Truth

Venus acknowledged this was a known risk. The donation attack vector had been discussed. Their ZKSync deployment was hit by the same bug class just 13 months earlier.

The uncomfortable truth is that many live Compound forks still carry this vulnerability. If your protocol:

  • Forks from Compound or Venus
  • Lists low-liquidity tokens as collateral
  • Relies solely on supply caps for exposure management
  • Doesn't monitor for donation-based exchange rate inflation

...you're running on borrowed time.

Audit Checklist: Donation Attack Resistance

Check Status
Supply cap accounts for direct transfers? ⬜
Exchange rate change limits per-block? ⬜
Per-account concentration limits? ⬜
Liquidity-adjusted collateral factors? ⬜
Real-time collateral concentration monitoring? ⬜
Automated market pause on anomalous conditions? ⬜
Oracle uses TWAP with outlier rejection? ⬜
Listed tokens have minimum liquidity requirements? ⬜

If you checked fewer than 5, schedule a review. If fewer than 3, consider it urgent.

References

This analysis is part of the DreamWork Security research series. Follow for weekly deep dives into DeFi exploits, audit tooling, and security best practices.

Top comments (0)