[Multi-chain] Patch Fix for THE Market Donation Attack

Venus Governance Venus - Governance Proposals
1

This proposal consists of two key actions executed across two separate Venus Improvement Proposals (VIPs):

  1. BNB Chain vToken Patch — Deploys the internalCash fix to the vToken contracts on BNB Chain, closing the donation attack vulnerability that caused the THE market incident.
  2. Non-BNB Chain vToken Patch + Borrow Resume — Deploys the same internalCash fix to all non-BNB Chain Venus deployments, and unpauses borrowing across all affected markets upon completion.

Background

On March 15, 2026, Venus Protocol experienced a price manipulation attack targeting the THE market, the native token of Thena, on BNB Chain. The attacker exploited a donation attack vector in the protocol’s vToken contracts: rather than depositing through the standard minting process, they transferred more than 36 million THE tokens directly to the vTHE contract address. This bypassed supply cap enforcement entirely and inflated the market’s exchange rate by approximately 3.8 times. Using this artificially inflated THE as collateral, the attacker borrowed assets including CAKE, USDC, BNB, and Bitcoin from the protocol. The incident resulted in approximately $2.15 million in bad debt.

This vulnerability is a known weakness in Compound-forked lending protocols. It had been identified in a prior Code4rena security audit of Venus, and the same technique was used in a February 2025 attack on Venus’s ZKSync deployment, which caused over $700,000 in bad debt. A full post-mortem has been published by Allez Labs here.

As a precautionary measure, borrowing on all non-BNB Chain markets has been paused as of March 20, 2026. Supply, repay, and withdraw actions remain fully operational. The pause will be lifted as part of the upcoming VIPs once the patch is deployed and validated.

As the patch involves changes to core vToken contract logic, and due to on-chain code size limitations, execution is split into two VIPs: one covering BNB Chain, and one covering all non-BNB Chain deployments.

Details

1. BNB Chain — vToken Contract Patch

The root cause of the attack is that _getCashPrior() — the internal function that reports available cash in a vToken market — previously returned the raw result of balanceOf(address(this)) on the underlying token. This meant that any direct token transfer to a vToken contract (a “donation”) would immediately inflate the reported cash balance, distorting the exchange rate and collateral values.

The fix replaces this with an internalCash storage variable that is only ever updated through the protocol’s own transfer functions:

  • _doTransferIn increments internalCash by the actual amount received when users supply assets
  • _doTransferOut decrements internalCash before transferring assets back to users on redemption or borrow
  • badDebtRecovered() increments internalCash when bad debt is settled via Shortfall auctions, keeping cash accounting consistent

A new syncCash() function is also introduced to bootstrap internalCash to the real underlying balance immediately after the upgrade. It is gated by the AccessControlManager (ACM) and emits a CashSynced event. Direct token donations to the vToken contract can no longer influence the exchange rate, supply caps, or collateral valuations.

2. Non-BNB Chain — vToken Contract Patch + Borrow Resume

The same internalCash fix is deployed to all seven non-BNB Chain Venus Isolated Pool networks: Arbitrum One, Base Mainnet, Ethereum Mainnet, opBNB Mainnet, OP Mainnet, Unichain Mainnet, and zkSync Mainnet.

The upgrade process per network is:

  • The VToken beacon is upgraded to the new implementation via upgradeTo()
  • syncCash() is called on every market to initialize internalCash from the real underlying balance
  • Borrowing is unpaused across all markets on each network

Only borrowing was paused as a precautionary measure — supply, repay, and withdraw have remained fully operational throughout. The borrow pause will be lifted as part of this VIP once the patch has been deployed and syncCash() called on all markets.

Action

This proposal spans two VIPs:

1. BNB Chain Patch Fix

  • Deploy the patched vToken implementation to BNB Chain
    • Replaces balanceOfbased cash reporting with internalCash tracked internally via _doTransferIn, _doTransferOut, and badDebtRecovered()
    • Calls syncCash() on all affected markets to initialize internalCash post-upgrade

2. Non-BNB Chain Patch Fix

  • Deploy the patched vToken implementation to all seven non-BNB Chain networks via beacon upgrade
    • Arbitrum One, Base Mainnet, Ethereum Mainnet, opBNB Mainnet, OP Mainnet, Unichain Mainnet, zkSync Mainnet
    • Calls syncCash() on every VToken market across all seven networks post-upgrade
  • Unpause borrowing across all markets on all non-BNB Chain deployments
    • Supply, repay, and withdraw actions were never affected and remain operational

Summary

If approved, these VIPs will:

  • Close the donation attack vulnerability on BNB Chain and all non-BNB Chain vToken contracts by replacing raw balanceOf cash reporting with internally tracked internalCash
  • Restore borrowing across all affected markets on all seven non-BNB Chain networks (Arbitrum One, Base, Ethereum, opBNB, OP Mainnet, Unichain, zkSync)
  • Ensure exchange rates, supply caps, and collateral valuations can no longer be manipulated via direct token transfers to vToken contracts
  • Maintain uninterrupted supply, repay, and withdraw functionality for all users throughout the patch deployment

We welcome community feedback on this proposal ahead of submitting it for a VIP vote.

3 Likes
2

Please audit audit audit audit audit audit audit audit this modification.

Please let SlowMist audit this.

1 Like
4

Lmao

So this was the same attack on wusdm?

And never looked into it and patch it, crazy omg

5

Can you please share the Audit link for that change?

6

To clarify, the contents of this update will need to be carried out in 3 VIPs.

VIP 600 will address the update on BNB Chain, while VIPs 601 and 602 will address the change on the remaining non-BSC chains.

7

Yes, you can find it on Github: [VPD-808] Add internal cash to prevent donation attack by Debugger022 · Pull Request #664 · VenusProtocol/venus-protocol · GitHub

8

I appreciate the technical clarity provided in this remediation plan, but the background section raises serious governance concerns regarding Venus Labs’ risk management process over the past three years.

As documented:

  • The donation/exchange-rate manipulation attack class was identified in a 2023 Code4rena audit.
  • The same attack vector was later exploited in February 2025 on zkSync, resulting in approximately $700k in bad debt.
  • Despite these clear external signals, the Venus Core Pool on BNB Chain remained unpatched until March 2026, resulting in a further $2.15M in bad debt.

This is not a technical oversight or isolated issue. It reflects a failure in vulnerability lifecycle management and cross-chain risk escalation processes over time.

The key governance question is not the existence of the vulnerability itself, but the decision-making process that allowed a known attack class to remain unmitigated across multiple audit cycles and after a real-world exploit event.

If the internalCash mitigation was already known and considered necessary, what risk assessment process justified not prioritizing it after the 2023 audit or immediately following the 2025 exploit?

The protocol treasury is now being used to absorb losses resulting from this delay. Therefore, clear accountability is required at the level of risk ownership and risk acceptance decisions, not only technical remediation.

We request a formal clarification on:

  • Which governance or core team process explicitly classified this vulnerability as non-urgent after the 2023 audit and after the 2025 exploit?
  • What criteria were used to override or defer mitigation of a previously exploited attack class?
  • How will future governance processes ensure that externally validated exploit patterns trigger mandatory remediation timelines rather than discretionary prioritization?

Without this clarity, the protocol is effectively socializing losses while keeping risk decision-making opaque.

1 Like
9

Hi, thank you for voicing your concerns. You may find the Code4rena audit here.

And as you pointed out, this issue was raised and acknowledged and ultimately dismissed as you can read in this comment by Jesus here. You may read the exchange to understand with greater clarity the thought process of the team at the time.

To summarise, the thought process was that this mode of attack is not a profitable one. In the case of the recent situation, it was true – the attacker did not manage to profit doing this. Donating tokens would benefit all vToken holders, not just the attacker. To do this, the attacker accumulated vTHE tokens across a span of months. If you read the discussion, I do believe the issues raised by the Code4rena team missed this specific critical edge case — an attacker with illiquid tokens who can’t sell on DEX. In the THE incident:

  • The attacker held 36M THE (~12.6% of supply) that couldn’t be sold due to slippage
  • Donating was the only way to extract value from those tokens
  • The donated tokens inflated other users’ collateral too, but the attacker was the one who had borrowing positions set up to exploit it
  • The attacker didn’t care about “losing” the donation because those tokens were effectively worthless to them.

I am explaining this only to address your request for more information on what occurred in the past. Regardless of rationale, the team is responsible for this oversight. As such, we are committed to doing a full re-audit that will, as with all other audits, be available to be reviewed publicly. We invite all community members to review the audits together with us and share any and all concerns. We are committed to fully resolving any legacy issues and keeping the protocol secure.