BUSD Deprecation - Forced Liquidations


A proposal to implement a “Forced Liquidation” mechanism. This mechanism aims to liquidate accounts holding BUSD borrow positions, thereby returning BUSD to the Venus Core Pool and allowing users to redeem their supplied BUSD. This initiative is part of an ongoing effort to wind down the market.


The community has approved the initial stage of the BUSD deprecation plan, which involved:

  • Freezing new supply and borrow by reducing supply and borrow caps to 0.
  • Increasing BUSD Reserve Factor to 100%
  • Pause MINT - complementary to setting supply caps to 0
  • Pausing BORROW - complementary to setting borrow caps to 0
  • Pausing ENTER_MARKET - will not allow users to start using BUSD as collateral. Users who have already enabled BUSD as collateral will not be affected by this update.
  • Setting XVS rewards in the BUSD market to 0.

Since the proposal has been implemented, nearly 35M BUSD supplied have been redeemed, and over 23M BUSD borrows have been repaid.

At this time, there are millions of outstanding borrowed BUSD by users that haven’t been repaid despite the borrow APYs surpassing 70% since August 28, 2023. Given that these positions are inelastic to the high APYs and could potentially be inactive, the community can choose to utilize a “Force Liquidation” mechanism. This would facilitate the liquidation of these positions, returning BUSD to the Venus Core pool and allowing suppliers to redeem them prior to Paxos discontinuing its support for BUSD in February 2024.

The “Force Liquidation” mechanism permits the liquidation of borrow positions within a specific market, even when a user’s health rate is above 1. Additionally, it bypasses the close factor check, enabling the liquidation of the entire debt in a single transaction.

Implementation Details

This feature is based on the implementation done by Compound V2 here. Compound V2 allows “forced liquidations” on markets as soon as the Collateral factor is zero, the Reserve factor is 100%, and the borrows are paused. Venus defines a feature flag to enable/disable “forced liquidations”, configurable directly via VIP, not based on other parameters. The discussion about this feature on the Compound governance forum can be found in this post.


  • Initially: Core pool
  • Upcoming weeks: isolated pools

Details of Implementation:

  • Add a new storage variable: mapping(address ⇒ bool) public isForcedLiquidationEnabled in a new ComptrollerStorage contract. It’ll have a feature flag per market in the pool, setting if the “force liquidation” feature is enabled or disabled (default).
  • Add a new function in the Comptroller contract to allow the set of this variable only by authorized accounts, accepting a market address as a parameter and checking if the address is for a valid and listed market. This function should be controlled by the AccessControlManager contract. Only the Normal, Fast-track, and Critical timelocks should be authorized to invoke it, so only Normal, Fast-track, and Critical VIPs will be able to invoke it. This function will enable or disable the “force liquidation” feature in a specific market.
  • Modify the *Comptroller.liquidateBorrowAllowed* function to check isForcedLiquidationEnabled. If force liquidation is enabled for the borrowed vToken, the checks on the existence of a shortfall and the close factor limit will be skipped, and the liquidation will be allowed (if the repayment amount is lower than or equal to the debt).



  • vUSDT collateral factor: 80%
  • 1 USDT = 1 BUSD = 1 USDC = $1 (for simplicity)
  • Close factor: 50%
  • Liquidation incentive: 10%
  • User with the following positions:
    • Supply: 500 USDT
    • Borrow: 200 BUSD
    • Borrow: 100 USDC

The health rate for this user would be (500 * 0.8) / (200 + 100) = 1.33. So, in normal circumstances, this user is not eligible to be liquidated.

Now, let’s say we enable the forced liquidations in the BUSD market (via VIP). Then:

  • Anyone will be allowed to liquidate the BUSD position of the previous user. Moreover, the close factor limit won’t be taken into account. So, the following liquidation would be doable:
    • Repay amount: 200 BUSD
    • Collateral market to seize: USDT
  • By executing this liquidation, 220 USDT (repay amount + liquidation incentive) would be seized from the user’s collateral.
  • After the liquidation, the global position of our user would be:
    • Supply: 280 USDT (500 USDT - 220 USDT seized during the liquidation)
    • Borrow: 0 BUSD
    • Borrow: 100 USDC
  • So, the new health rate would be (280 * 0.8 / 100) = 2.24. They will still be ineligible for regular liquidations
  • Because forced liquidation is not enabled in the USDC market, the USDC debt cannot be liquidated (because the health rate is greater than 1).

Next Steps

If the community approves this proposal (via Snapshot), we recommend implementing the forced liquidation no later than November 1st, but with a preference for one month after approval. This approach should grant users ample time to make necessary preparations and potentially repay their BUSD positions, all while ensuring a reasonable buffer period before Paxos halts its support for BUSD.


09.22.2023 - Update

Since the release of this proposal, an additional $1.15 million in BUSD has been repaid and redeemed. Following the implementation of the forced liquidation mechanism and considering the limited number of repayments observed in recent weeks, we recommend executing forced liquidations after conducting a community Snapshot. As outlined in the initial post, this action will facilitate the return of BUSD to the Venus Core pool and enable suppliers to redeem their BUSD positions.

Enabling users to redeem their BUSD positions serves to reduce the protocol’s exposure to potential bad debt in cases of future BUSD price fluctuations and liquidity declines, especially as we approach Paxos discontinuing its support for BUSD in February 2024. Furthermore, given the compounding borrow interest rates given 100% utilization (borrow rates are currently at nearly 96%), initiating forced liquidations, where some accounts are potentially inactive, can safeguard them from larger losses resulting from the accumulation of additional BUSD debt and potential future “organic” liquidations.

Impacted Accounts:

As of today, considering accounts that have borrowed at least $1 of BUSD, a total of approximately $6.5 million across over 2.5K accounts will be eligible for liquidation.

A complete list of affected accounts can be found here.

Next Steps:

  1. Snapshot to approve the use of the forced liquidation mechanism.
  2. Should the community approve the above, target a VIP to execute the forced liquidations on the second week of October. The exact date for VIP launch is contingent upon additional development and will be communicated to the community at least seven days in advance.
  3. Chaos Labs will continue to publicly communicate the planned amendments and list of affected accounts leading to the on-chain execution.

I personally agree and think that Venus should proceed. At the current pace BUSD borrowers are accumulating interests, they will end-up losing a LOT MORE money if waiting for their collateral to be liquidated because of interest accrued.

These borrowers should be aware of the BUSD deprecation after 7 months of it being announced by Paxos and Binance and, after several reminders over the past weeks from Venus. They might not have access to their wallets at this time and I think it’s unfair they should pay a 90%+ premium and maybe lose their collateral entirely instead of a small liquidation fee.


for the protocol health and the sustainablty of protocol, we have to do it asap.

Are there any specific conditions for setting an address to be forced liquidation? Why is there only 5.6 million instead of the exact borrowed amount of 19 million?

It’s $6.5M and there is no specific conditions. All BUSD borrowers would be forced liquidated. The remaining part of missing BUSD is part of the existing shortfall which will have to be handled as per the shortfall recovery plan, which includes the Venus Risk fund.

Venus Dev team proposes the following:


  • Enable “forced liquidations” in the BUSD market
  • Allow, only, an authorized account (authorized via VIP) to liquidate the BUSD positions
  • Send (almost) 100% of the liquidations incentive to the Venus Treasury contract. It will be used to repay the BUSD shortfall in the future
    • The “almost” term is because we should compensate the operator of the BUSDLiquidator contract. If this operator gets the BUSD funds from a flash swap, they will have to pay a fee, that should be covered with part of the liquidation incentive.


  • Deploy a contract BUSDLiquidator with a function to perform liquidations.
    • Params:
      • User address of the borrower to liquidate
      • Market address of the collateral to seize
      • Amount of BUSD to repay (optional, if it’s not provided 100% of the BUSD position will be liquidated)
    • The sequence of actions (ignoring the needed checks):
      • Transfer BUSD from the sender to the BUSDLiquidator (the sender should allow beforehand the BUSDLiquidator to transfer the BUSD tokens to the BUSDLiquidator contract)
      • Enable liquidations on the BUSD market
      • Invoke Liquidator.liquidateBorrow, hardcoding the BUSD market address, to perform the liquidation
      • Split the seized tokens:
        • 5/105 should be transferred to the Venus Treasury
        • 100/105 should be transferred to the sender
          • it should transfer the sender more than 100/105, assuming they will use a flash swap, there should be some margin to repay the liquidity provider fee
      • Pause liquidations on the BUSD market
    • Anyone would be authorized to invoke this function
    • The invoker should be able to do a flash swap
  • VIP:
    • Pause liquidations on the BUSD market
    • Authorize the BUSDLiquidator to resume and pause liquidations
    • Enable “forced liquidations” in the BUSD market
    • Set to zero the Interest rate in the BUSD market, to stop accruing interest on the bad debt

The following diagram shows the main transfers of tokens: