ohmygod

Posted on Mar 28

The Venus Protocol Donation Attack: How a Dismissed Audit Finding Became a $2.15M Bad Debt — Twice

#security #blockchain #defi #smartcontracts

On March 15, 2026, Venus Protocol on BNB Chain was hit by an exploit that left it with $2.15 million in bad debt. The attack targeted the THENA (THE) token market using a donation attack — a vulnerability class so well-known it was literally flagged in Venus's own Code4rena audit.

The protocol dismissed the finding. Then it got exploited. Again.

Here's the anatomy of what went wrong, why three separate lines of defense failed simultaneously, and what every Compound-fork lending protocol needs to learn from this.

The Vulnerability: Donation Attacks in Compound Forks

In Compound-style lending protocols, supply caps limit how much of a given token can be deposited as collateral. But here's the critical design flaw: most implementations only enforce this cap on the mint path — the standard deposit function that issues vTokens (or cTokens).

They don't account for tokens transferred directly to the contract address.

// The mint path checks the supply cap
function mintInternal(uint mintAmount) internal {
    require(totalSupply + mintAmount <= supplyCap, "supply cap exceeded");
    // ... mint vTokens
}

// But a direct ERC-20 transfer bypasses everything:
// IERC20(THE).transfer(address(vTHE), amount);
// No cap check. No access control. Just... more tokens.

When tokens are sent directly to the vToken contract, the contract's underlying balance increases without minting new vTokens. Since the exchangeRate is calculated as:

exchangeRate = (underlyingBalance + totalBorrows - reserves) / totalSupply

This inflates the exchange rate. Every existing vToken holder suddenly has more borrowing power — without any supply cap check firing.

The 9-Month Setup

This wasn't a flash loan one-block wonder. The attacker started in June 2025:

Funded via Tornado Cash: 7,447 ETH → deposited into Aave as collateral → borrowed $9.92M in stablecoins
Gradual accumulation: Over 9 months, systematically bought THE tokens across multiple wallets
Reached 84% of supply cap: By March 15, the attacker controlled ~12.2M THE out of the 14.5M cap

Every single one of these transactions was visible on-chain. The address had even been flagged by community members. Venus declined to act, citing decentralization.

The Execution

On March 15, 2026 at 11:00 UTC, the attacker deployed a malicious contract and executed the donation attack:

Donated THE directly to the vTHE contract, bypassing the supply cap
Exchange rate inflated 3.81x, massively increasing borrowing power
Borrowed ~$14.9M in BTCB, CAKE, USDC, and BNB against the inflated collateral
Repeated the cycle: borrowed → swapped for THE → donated → borrowed more
THE price pushed from $0.263 to over $0.51 during the manipulation
Total THE in Venus reached 53.23M — that's 367% of the 14.5M supply cap

Three Lines of Defense, Three Failures

1. Supply Cap (Bypassed)

The supply cap only guarded the mint function. Direct transfers went unchecked. This is the core vulnerability.

Fix: Supply caps must account for the contract's actual underlying balance, not just minted supply. The getCashPrior() function reads the raw token balance — any discrepancy between this and the tracked supply should trigger circuit breakers.

2. Oracle-Based Collateral Valuation (Manipulated)

The attacker's buy-and-donate cycle artificially inflated THE's market price alongside the exchange rate manipulation. The oracle faithfully reported the manipulated price.

Fix: TWAP oracles with longer windows, circuit breakers on rapid price movements, and collateral factor adjustments based on on-chain liquidity depth.

3. Liquidation Market (Overwhelmed)

254 liquidation bots competed across 8,048 transactions to unwind the position. Despite this aggressive competition, $2.15M in bad debt remained. The THE token's price collapsed from $0.51 to $0.22 during the liquidation cascade — below its pre-attack level — making each successive liquidation less effective.

Fix: Gradual liquidation mechanisms (like Aave's soft liquidation), protocol-owned liquidation reserves, and dynamic liquidation incentives that scale with position risk.

The Audit Finding That Was Dismissed

This is the most damning part. The donation attack vector was explicitly identified during Venus Protocol's Code4rena security audit. The Venus team's response:

"Donations are an intentional feature with no negative side effects."

This wasn't ignorance. It was a conscious decision to accept risk that the team didn't fully understand.

And it wasn't even the first time. In February 2025, Venus suffered the same class of attack on its zkSync deployment, resulting in $700K+ in bad debt. The protocol saw the same vulnerability exploited, patched the specific instance, and still didn't address the systemic issue across all deployments.

Detection Opportunities That Were Missed

The 9-month preparation window provided multiple detection signals:

Single entity accumulating 84% of supply cap — visible from June 2025 onwards via position concentration monitoring
Tornado Cash-funded address active in protocol — visible from June 2025 via funding source analysis
Community flagging of suspicious address — months before exploit via governance alerts
Rapid position changes on attack day — March 15, 11:00 UTC via real-time transaction monitoring

None of these required sophisticated tooling. Basic position concentration alerts — "notify when any address holds >50% of a market's supply" — would have surfaced this months in advance.

Takeaways for Builders and Auditors

If You're Building a Compound Fork

Validate supply against actual balance, not just mint accounting. Add invariant checks:

require(
    IERC20(underlying).balanceOf(address(this)) <= expectedBalance + DUST_THRESHOLD,
    "unexpected balance increase"
);

Don't dismiss audit findings because the behavior is "intentional." Intent doesn't equal safety.
Monitor position concentration as a first-class risk metric, not an afterthought.
Implement exchange rate change limits — if the rate jumps >X% in a single block, pause the market.

If You're Auditing

Test the full deposit surface, not just the intended entry points. Direct transfers, transferFrom with pre-approved amounts, and callback-based deposits should all be validated.
Challenge "won't fix" responses with concrete attack scenarios. "This is intended behavior" is not a security argument.
Check for repeat vulnerabilities across different deployments of the same protocol. If it happened on zkSync, it can happen on BNB Chain.

If You're Running a Lending Protocol

Position concentration is a leading indicator. A single address at 84% of your supply cap is a red flag, not a feature.
Historical exploits on your own protocol are the highest-signal intelligence you have. Venus ignored its own zkSync incident. Don't repeat this pattern.
Liquidation markets have limits. 254 competing bots still couldn't prevent $2.15M in bad debt. Design for liquidation failure, not just liquidation success.

Timeline

June 2025 — Attacker begins accumulating THE via Tornado Cash funding
Feb 2025 — Venus zkSync deployment suffers similar donation attack ($700K+ bad debt)
Pre-attack — Community flags suspicious address; Venus declines action
Mar 15, 2026 11:00 UTC — Attacker deploys malicious contract, begins donation attack
Mar 15, 2026 ~12:00 UTC — 8,048 liquidation transactions begin unwinding the position
Post-attack — Venus suspends THE lending/borrowing, sets collateral factor to zero

The Venus incident is a masterclass in how DeFi protocols fail: not because the vulnerability was unknown, but because the warning was ignored. The audit found it. The community flagged it. A previous exploit demonstrated it. And still, three lines of defense crumbled against an attacker who took nine months to prepare.

The lesson isn't "get better audits." It's listen to the audits you already have.

References: Venus Post-Mortem, BlockSec Analysis, Halborn Writeup

DEV Community