Inside the Venus Protocol Exploit: How 9 Months of Patience and a Donation Attack Bypassed Supply Caps to Drain $3.7M

On March 15, 2026, Venus Protocol — one of BNB Chain's largest lending platforms — lost $3.7 million to an attacker who had been planning the heist for nine months. This wasn't a smash-and-grab flash loan attack. It was a slow, methodical campaign that exploited a fundamental flaw in how Compound-forked lending protocols enforce supply caps.

Let's dissect every stage of this exploit, understand why it worked, and extract the defensive lessons every DeFi protocol team needs to internalize.

The Setup: 9 Months of Silent Accumulation (June 2025 – March 2026)

Starting in June 2025, the attacker began quietly purchasing THE (Thena) tokens — a relatively illiquid governance token listed as collateral on Venus Protocol. Over nine months, they accumulated approximately 84% of the 14.5 million vTHE supply cap.

This wasn't unusual enough to trigger alarms. The positions were built gradually, blending in with normal market activity. But the attacker was building a fortress of collateral that would become the foundation of the exploit.

Lesson #1: Monitor concentration risk. When a single entity controls >50% of a collateral asset's supply on your protocol, that's not just a risk — it's a loaded gun.

The Core Vulnerability: Supply Cap Bypass via Donation Attack

Here's where the exploit gets technically interesting. Venus Protocol, like most Compound forks, enforces supply caps through the mint() function. When a user deposits collateral, mint() checks whether the total supply would exceed the cap. If it would, the transaction reverts.

But the attacker found a critical gap: direct ERC-20 transfers to the vTHE contract bypass mint() entirely.

// What mint() does (simplified):
function mint(uint mintAmount) external {
    require(totalSupply + mintAmount <= supplyCap, "cap exceeded");
    // ... transfer tokens, mint vTokens
}

// What the attacker did:
// THE.transfer(address(vTHE), amount)
// This increases the contract's token balance without going through mint()

By transferring THE tokens directly to the vTHE contract address, the attacker inflated the internal exchange rate of vTHE. Their existing vTHE holdings — minted when the exchange rate was normal — now represented a claim on a much larger pool of underlying THE tokens.

The result: the attacker's effective collateral position ballooned to 53.2 million THE — roughly 3.7x the intended supply cap.

Lesson #2: Supply caps must account for direct transfers. Any Compound fork that only enforces caps in mint() has this vulnerability. The fix requires either:

• Tracking total underlying balance independently of the contract's token balance
• Using a checkpoint mechanism that detects exchange rate anomalies
• Implementing donation guards that revert on unexpected balance increases

The Manipulation Loop: Recursive Oracle Pumping

With an oversized collateral position established, the attacker executed a recursive price manipulation loop:

┌─────────────────────────────────────────────────┐
│ 1. Deposit THE (inflated position) as collateral │
│ 2. Borrow CAKE, BNB, BTCB against it           │
│ 3. Use borrowed funds to buy MORE THE on Thena  │
│ 4. THE price pumps (thin liquidity)             │
│ 5. Wait for TWAP oracle to update               │
│ 6. New oracle price → higher collateral value    │
│ 7. Borrow even more → repeat from step 3        │
└─────────────────────────────────────────────────┘

The THE token's on-chain liquidity was paper-thin. Each buy cycle moved the price dramatically — from ~$0.27 to nearly $5 at peak. Even Venus's "resilient oracle" (designed to filter outlier prices) eventually capitulated and incorporated the manipulated price.

Each loop iteration increased the attacker's borrowing power, which funded the next round of price manipulation. It was a self-reinforcing feedback loop with no circuit breaker.

Lesson #3: TWAP oracles are not manipulation-proof — they're manipulation-delayed. For illiquid assets, even multi-block TWAPs will eventually reflect sustained price manipulation. Protocols need:

• Liquidity-weighted confidence scores for oracle prices
• Maximum borrow rate limits per block/epoch
• Collateral factor reduction that scales inversely with liquidity depth

The Extraction: $3.7M Out, Bad Debt Left Behind

Once the loop had maximized borrowing power, the attacker extracted approximately:

• 20 BTCB (~$1.7M)
• 1.5M CAKE (~$1.5M)
• 200 BNB (~$500K)

After extraction, the attacker's THE position became undercollateralized. Liquidators swooped in, but THE's price crashed immediately back to ~$0.22 due to the same thin liquidity that enabled the manipulation in the first place. The liquidations couldn't recover the borrowed value, leaving Venus Protocol with ~$2.15M in bad debt.

Why This Exploit Matters Beyond Venus

This attack pattern — donation-based supply cap bypass + illiquid collateral manipulation — is not unique to Venus. Every Compound fork that enforces supply caps only through mint() is potentially vulnerable.

Let's check the attack prerequisites:

Requirement	Difficulty
Find illiquid collateral asset on lending protocol	Easy — many protocols list long-tail assets
Accumulate majority supply on protocol	Medium — requires capital and patience
Direct-transfer tokens to bypass supply cap	Easy — standard ERC-20 transfer
Manipulate price through thin DEX liquidity	Medium — depends on available liquidity
Wait for TWAP oracle to incorporate new price	Easy — just wait

The scariest part: most of these steps look like normal user behavior until the final extraction.

Defensive Architecture: What Should Have Existed

1. Donation Guards

modifier noDonation() {
    uint balanceBefore = underlying.balanceOf(address(this));
    _;
    uint balanceAfter = underlying.balanceOf(address(this));
    require(
        balanceAfter <= balanceBefore + expectedIncrease,
        "unexpected balance increase"
    );
}

2. Exchange Rate Circuit Breakers

Monitor the vToken exchange rate. If it deviates more than X% from the last checkpoint without corresponding mint() calls, pause the market.

3. Liquidity-Aware Collateral Factors

Instead of static collateral factors (e.g., 60% for THE), use dynamic factors that incorporate on-chain liquidity depth:

effectiveCF = baseCF * min(1, liquidityDepth / totalBorrowed)

4. Concentration Limits

Cap the percentage of total collateral that any single address (or linked addresses) can represent. When one entity holds >30% of a market's collateral, reduce their borrowing power proportionally.

5. Borrow Rate Throttling

Implement per-epoch borrow limits that prevent rapid extraction:

maxNewBorrowPerEpoch = totalAvailable * MAX_BORROW_RATE

The Bigger Picture: DeFi's Illiquidity Problem

The Venus exploit is a symptom of a structural problem in DeFi lending: protocols list illiquid assets as collateral because it attracts TVL, but those same assets are manipulation magnets.

The playbook is becoming standardized:

1. Eisenberg-style attacks (Mango Markets, 2022) — borrow against manipulated oracle prices
2. Donation attacks (Venus, 2026) — bypass supply caps via direct transfers
3. Governance attacks — manipulate votes to add vulnerable collateral

Until lending protocols implement liquidity-aware risk management (not just static parameters), these attacks will keep happening. The $3.7M Venus lost is a rounding error compared to what's at risk across the DeFi landscape.

---

This article is part of my DeFi Security Deep Dives series. Follow for weekly breakdowns of real exploits, audit techniques, and defensive patterns. If your protocol needs a security review, reach out — especially if you're running a Compound fork.