The Venus Protocol Donation Attack: How 9 Months of Patience Bypassed Three Lines of Defense

TL;DR

On March 15, 2026, an attacker bypassed Venus Protocol's THE token supply cap on BNB Chain through a donation attack — directly transferring tokens to the vTHE contract instead of using the capped mint path. The result: $14.9M borrowed against artificially inflated collateral, $2.15M in bad debt for Venus, and ironically, a net loss for the attacker too. This incident exposed how all three standard lending protocol defenses (supply caps, oracle valuation, liquidation) can fail simultaneously.

The Setup: 9 Months in the Making

This wasn't a flash loan blitz. The attacker started in June 2025, nine months before execution.

The funding chain:

1. Received 7,447 ETH through Tornado Cash
2. Deposited ETH into Aave as collateral
3. Borrowed $9.92M in stablecoins (USDT, DAI, USDC)
4. Distributed funds across multiple wallets
5. Gradually accumulated THE tokens over 9 months

By attack day, the attacker held approximately 12.2M THE within Venus — 84% of the 14.5M supply cap. Every single deposit was a routine transaction. Nothing triggered alerts.

The Core Vulnerability: Supply Caps That Don't Actually Cap

The vulnerability is embarrassingly simple in hindsight. In Compound-style lending protocols (which Venus forks), supply caps only constrain the mint path — the standard deposit function that checks the cap before issuing vTokens.

But what happens if you just... transfer tokens directly to the contract?

// The "donation" — direct ERC-20 transfer
THE.transfer(address(vTHE), amount);
// No cap check. No limit. Just a bigger balance.

A direct ERC-20 transfer to the vTHE contract increases the contract's underlying token balance without minting new vTokens. In Compound-style accounting, this inflates the exchangeRate between vTokens and the underlying asset.

The math is brutal: existing vToken holders suddenly have claims on far more underlying tokens. Their effective collateral value, as seen by the protocol, skyrockets — completely bypassing the supply cap.

The attacker donated over 36 million THE tokens directly to vTHE, pushing their effective collateral position to 53.2M THE — 3.67x the intended supply cap limit.

The Three-Layer Failure

Layer 1: Supply Caps (Bypassed)

Supply caps are supposed to limit protocol exposure to volatile or low-liquidity tokens. The donation vector made them irrelevant for any token where direct transfers are possible (which is... all of them).

The lesson: Supply caps that only gate the mint path create a false sense of security. Effective exposure limits must account for the contract's actual token balance, not just what was deposited through the front door.

Layer 2: Oracle Valuation (Manipulated)

With an inflated collateral position, the attacker ran a classic oracle manipulation loop:

1. Deposit THE as collateral
2. Borrow other assets against it
3. Use borrowed funds to buy more THE
4. Repeat, synchronized with TWAP oracle updates

THE's price surged from $0.27 to nearly $5.00 — an 18.5x increase. For a low-liquidity token like THE, this was achievable because the attacker already controlled such a dominant position.

The borrowed assets: 20 BTC, 1.5M CAKE, and 200 BNB.

The lesson: TWAP oracles provide smoothing against flash manipulation, but they can't protect against sustained, well-funded manipulation campaigns. For low-liquidity collateral assets, even time-weighted prices can be gamed by patient attackers.

Layer 3: Liquidation (Insufficient)

When the position became undercollateralized, the liquidation market responded — aggressively. 254 liquidation bots competed across 8,048 transactions to unwind the position.

But it wasn't enough. Despite the frenzy, $2.15M in bad debt remained. Why?

• The liquidation relied on converting THE tokens to repay borrowed assets
• With the price artificially inflated and then crashing, the seized collateral was worth far less than the outstanding debt
• The sheer volume of THE being liquidated cratered its price further
• A classic liquidation death spiral: the more you liquidate, the less the remaining collateral is worth

The lesson: Liquidation is a last resort, not a safety guarantee. For low-liquidity assets, mass liquidation can itself become the problem. The collateral is only as good as the market's ability to absorb it.

The Plot Twist: The Attacker Lost Money Too

Here's the part most coverage missed. The attacker invested $9.92M (borrowed from Aave against their ETH collateral) and after all liquidations, retained only approximately $5.2M. That's a net loss of roughly $4.7M.

Both sides lost. The protocol lost $2.15M in bad debt. The attacker lost $4.7M. The only winners were the 254 liquidation bots that extracted value from both sides.

The Known-Unknown Problem

The most damning detail: this exact vulnerability had been identified in a prior security audit. Venus had even experienced a similar donation attack on its zkSync deployment in February 2025 — a full year before this BNB Chain exploit.

The attack was visible on-chain for 9 months. Each deposit was queryable. The concentration risk was calculable. But:

• Individual transactions looked routine
• No continuous monitoring flagged the gradual accumulation
• The known vulnerability wasn't patched across all deployments

Defensive Patterns That Would Have Helped

1. Balance-Aware Supply Caps

function effectiveSupply() public view returns (uint256) {
    // Don't just track minted amounts — track actual exposure
    return underlying.balanceOf(address(this));
}

function _checkSupplyCap() internal view {
    require(
        effectiveSupply() <= supplyCap,
        "Supply cap exceeded (including donations)"
    );
}

2. Exchange Rate Circuit Breakers

Monitor the vToken exchange rate for anomalous jumps. If the exchange rate increases by more than X% in a single block or short time window, pause operations and investigate.

uint256 constant MAX_RATE_INCREASE_BPS = 500; // 5% max per block

function _checkExchangeRateInvariant() internal {
    uint256 currentRate = exchangeRateStored();
    uint256 maxAllowed = lastRate * (10000 + MAX_RATE_INCREASE_BPS) / 10000;
    require(currentRate <= maxAllowed, "Exchange rate anomaly detected");
    lastRate = currentRate;
}

3. Concentration Risk Monitoring

When any single entity controls >50% of a market's supply, that's a systemic risk regardless of whether the supply cap is respected. Protocols should implement:

• Per-address supply limits (or at least alerts)
• Continuous monitoring of position concentration
• Automatic collateral factor reduction when concentration exceeds thresholds

4. Cross-Deployment Patch Propagation

If a vulnerability is found on one chain, patch it everywhere. Venus had the knowledge from the zkSync incident — the fix just didn't propagate to BNB Chain in time.

For Auditors: What to Check

If you're auditing a Compound-fork lending protocol, add these to your checklist:

• [ ] Do supply caps account for direct token transfers (donations)?
• [ ] Can the exchange rate be manipulated by direct balance changes?
• [ ] Are there circuit breakers for anomalous exchange rate movements?
• [ ] Is there per-address concentration monitoring?
• [ ] For multi-chain deployments: are patches applied consistently across all chains?
• [ ] What happens to liquidation efficiency when collateral liquidity is thin?
• [ ] Can a well-funded attacker gradually build a position that destabilizes the market?

The Broader Pattern

The Venus donation attack isn't novel — it's a known vulnerability class. What makes it notable is the sophistication of execution and the systemic failure of all three defense layers simultaneously.

We keep seeing the same pattern in DeFi security:

1. Vulnerability is identified (audit, prior exploit)
2. Fix is applied partially or not at all
3. Attacker finds the unpatched surface
4. Post-mortem promises better monitoring
5. Repeat on the next protocol

The industry doesn't have a knowledge problem. It has an execution problem. The vulnerabilities are known. The fixes are known. The gap is in consistently applying what we already know across every deployment, every chain, every fork.

---

If you're building or auditing lending protocols, the Venus incident is required reading. The full technical breakdown by BlockSec covers the on-chain fund flows in detail: Venus Thena Incident Analysis

Found this useful? Follow for more DeFi security deep dives — I publish vulnerability analyses, audit tool reviews, and security best practices weekly.