The Venus Protocol Donation Attack: How a 9-Month Setup Broke Three Lines of Defense

On March 15, 2026, an attacker bypassed the THE (Thena) market's supply cap on Venus Protocol, inflated their collateral position to 3.67× the intended limit, and borrowed ~$14.9M in assets. What makes this attack remarkable isn't its novelty — it's the opposite. The vulnerability was known, flagged in audit, and explicitly dismissed by the team.

This article dissects why three independent safety layers failed simultaneously, and what protocol teams should actually do to prevent the next donation attack.

The Three-Layer Defense Model (And Why It Failed)

Compound-forked lending protocols like Venus rely on a three-layer defense:

1. Supply caps — limit how much of an asset can be deposited as collateral
2. Oracle-based collateral valuation — determine borrowing power
3. Competitive liquidation — third-party bots unwind underwater positions

The Venus THE incident stress-tested all three. All three broke.

Layer 1: Supply Cap Bypass via Donation

Supply caps in Compound forks only constrain the mint path — the standard deposit function that checks the cap before issuing vTokens. They don't account for direct ERC-20 transfers to the contract.

The attacker exploited this gap with surgical precision:

// Standard deposit: cap-checked
function mintInternal(uint mintAmount) → checks totalSupply vs supplyCap ✓

// Direct transfer: unchecked
THE.transfer(address(vTHE), amount) → increases balance, no cap check ✗

When tokens are transferred directly to the vTHE contract, the underlying balance increases without minting new vTokens. Because Compound-style accounting reads token balance via getCashPrior() (which calls balanceOf(address(this))), this inflates the exchangeRate. Existing vToken holders suddenly have collateral worth more than what they deposited.

The result: THE supply in Venus reached 53.23 million tokens — 367% of the 14.5M supply cap.

Why This Defense Failed

Supply caps only guard the front door. The donation vector is the equivalent of climbing through the window. Any Compound fork that enforces caps solely on the mint path is vulnerable.

The fix: Implement supply cap checks that account for total underlying balance, not just minted supply. Use totalSupply * exchangeRate as the effective cap metric, or add balance-change hooks that detect direct transfers.

Layer 2: Collateral Valuation Under Manipulation

With the exchange rate inflated 3.81×, the attacker's existing vTHE position suddenly represented far more borrowing power than intended. They then entered a recursive loop:

1. Borrow assets (CAKE, BNB, BTCB, stablecoins) against inflated collateral
2. Swap borrowed assets for THE on the open market
3. Donate THE back to the vTHE contract
4. Repeat — each cycle further inflates the exchange rate

THE's spot price surged from $0.263 to over $0.51 — nearly doubling — as the attacker became the dominant buyer in a thin-liquidity market.

Why This Defense Failed

Oracle-based valuation is only as good as the market it references. When an attacker controls 84% of a token's supply within a protocol and can move the spot price at will, the oracle faithfully reports the manipulated price. The oracle isn't broken — it's working exactly as designed, just on corrupted inputs.

The fix: Implement borrowing rate limits (maximum borrow per block/time window), concentration alerts that trigger when a single address controls >50% of a market's supply, and TWAP-based or multi-source oracle feeds for low-liquidity assets.

Layer 3: Liquidation Couldn't Keep Up

When the attacker's health factor approached 1.0, selling pressure triggered a liquidation cascade. 254 bots competed across 8,048 transactions to unwind the position. THE's price collapsed to $0.22 — below pre-attack levels.

But even with hundreds of bots fighting for liquidation profits, $2.15M in bad debt remained. Why?

The math is brutal: when a collateral token loses 60%+ of its value during liquidation, there simply isn't enough value left to make the protocol whole. Liquidators seize collateral at a discount, but if the collateral is in freefall, the discount isn't enough to cover the outstanding debt. It's a liquidation death spiral.

Why This Defense Failed

Liquidation markets assume adequate liquidity and orderly price discovery. Neither existed here. THE's thin liquidity meant that the liquidation itself was the price crash. Every liquidation bot dumping THE made the remaining collateral worth less, making subsequent liquidations less effective.

The fix: Circuit breakers that pause borrowing when collateral concentration exceeds thresholds. Gradual liquidation mechanisms that prevent fire-sale cascades. Protocol-owned liquidity reserves specifically for liquidation emergencies.

The 9-Month Warning That Nobody Acted On

Perhaps the most damning detail: the attacker spent nine months accumulating their position. Starting in June 2025, funded by 7,447 ETH laundered through Tornado Cash, they gradually built a position controlling 84% of Venus's THE supply cap.

Each individual transaction looked routine. But the aggregate pattern was screaming:

• A single cluster of addresses (all traceable to one Tornado Cash source) accumulating a dominant share of one market
• Position concentration approaching supply cap limits over months
• Funding source: Tornado Cash → Aave collateral → stablecoin borrows → THE purchases

The community even flagged the address. Venus declined to act, citing decentralization.

The Real Lesson

On-chain monitoring isn't optional anymore. Protocols need:

• Concentration monitoring: Alert when any address cluster exceeds 30-50% of a market's supply
• Funding source analysis: Flag positions funded through privacy mixers
• Governance fast-paths: Emergency parameter changes shouldn't require week-long governance votes when risk indicators are flashing red

The Attacker Lost Money Too

Here's the twist: the attacker also lost. They invested $9.92M (via Tornado Cash → Aave → stablecoins → THE) and retained only ~$5.2M after liquidations — an on-chain net loss of ~$4.7M.

The prevailing theory: the attacker pre-positioned short trades on centralized exchanges. By triggering THE's collapse from $0.51 to $0.22, they could profit from shorts even while losing on-chain. If true, this represents a new class of cross-venue attack where the on-chain exploit is just the setup for off-chain profit extraction.

This makes the attack nearly impossible to trace to a net-positive outcome using only on-chain data — a significant blind spot for current forensics tooling.

The Audit That Flagged It (And Was Ignored)

The donation vulnerability was identified during Venus's Code4rena security audit. The team disputed the finding, claiming donations were "an intentional feature with no negative side effects."

Venus had already experienced a similar donation attack on its zkSync deployment in February 2025, causing over $700K in bad debt.

Two warnings. Two incidents. Same root cause.

Protocol Teams: How to Not Be Venus

1. Take audit findings seriously. If auditors flag a theoretical attack vector, assume someone will eventually exploit it.
2. Cross-reference incidents across deployments. A bug on your L2 deployment is a bug on your L1 deployment.
3. Don't dispute findings based on current conditions. "No one would do this because liquidity is too thin" is not a valid security argument — it's an invitation.

Defensive Checklist for Compound-Fork Protocols

If you're running a Compound-forked lending protocol, here's what to audit today:

• [ ] Supply cap enforcement: Does your cap check account for direct transfers, or only minted deposits?
• [ ] Exchange rate manipulation: Can direct token transfers inflate exchangeRate beyond expected bounds?
• [ ] Concentration limits: Do you monitor and restrict single-address dominance in any market?
• [ ] Low-liquidity asset parameters: Are collateral factors, supply caps, and borrow caps appropriately conservative for thin markets?
• [ ] Liquidation stress testing: Have you simulated cascading liquidations in your lowest-liquidity markets?
• [ ] Emergency governance: Can you freeze markets within minutes, or does it require a multi-day vote?
• [ ] On-chain monitoring: Are you running continuous position concentration and funding source analysis?

Conclusion

The Venus donation attack isn't a story about a clever zero-day. It's a story about a known vulnerability, identified in audit, previously exploited on another chain, and still left unpatched. The attacker didn't need innovation — they needed patience and capital.

For the broader DeFi ecosystem, this incident reinforces an uncomfortable truth: the biggest risk isn't unknown vulnerabilities. It's known vulnerabilities that teams choose not to fix.

---

DreamWork Security publishes technical analyses of DeFi security incidents. Follow for weekly deep dives into smart contract vulnerabilities, audit methodologies, and defensive best practices.