Perpetual Protocol

Version 2.2.1-rc of the protocol introduces a soft circuit break, which should disallow all trades/liquidations that generate bad debt when the insurance fund has been already depleted.

Bad debt is settled by calling the public function Vault::settleBadDebt, which is called by ClearingHouse::liquidate and Vault::liquidateCollateral. ClearingHouse::liquidate implements a requirement check that ensures the insurance fund has enough settlement token balance to cover the bad debt incurred to the protocol by the liquidation. Otherwise the liquidating transaction will revert. However, Vault::liquidateCollateral does not implement such a requirement, which may allow liquidations of collateral that under certain conditions generate bad debt.

We have identified two such scenarios:

• A trader closes her unfavorable position leading to negative PnL but cannot yet get liquidated due to the value of her non-settlement collateral. The value of the trader’s collateral decreases and can no longer cover the negative PnL allowing anyone to liquidate her. Vault::liquidateCollateral is called to liquidate the trader, incurring bad debt to the system in case the insurance fund is not able to cover the debt at the moment, as there is no check against that.
• A trader that is using non-settlement tokens as collateral has her position gotten liquidated. Due to the fact that the function Vault::settleBadDebt requires the trader to not have non-settlement collateral, the bad debt will not be settled before liquidating the trader for every non-settlement collateral they have deposited. Usually a liquidator will liquidate the trader’s position and all their non-settlement collateral in a single transaction (using a specially developed smart contract). However, if this does not happen, the requirement in ClearingHouse::liquidate, which ensures that the insurance fund can cover the debt, is deemed useless as the debt might increase between the transaction that liquidates the position and the transaction(s) that liquidate the collateral(s), letting the insurance fund unable to cover it in whole.

SurplusBeneficiary::setFeeDistributor sets the new fee distributor contract and approves it to be able to transfer an infinite amount of USDC. However, the approval of the old fee distributor is not revoked, allowing it to transfer any amount of USDC even though that contract might have been deemed obsolete or even vulnerable.

SurplusBeneficiary::dispatch computes the amount of USDC that should be transferred to the treasury and executes the transfer without checking first that the transferred amount is not 0.

function dispatch() external override nonReentrant {
  // ..

  uint256 tokenAmountToTreasury =
    FullMath.mulDiv(tokenAmount, _treasuryPercentage, 1e6);
  // Dedaub: tokenAmountToTreasury might be 0 due to _treasuryPercentage
  // being 0 or due to rounding.
  SafeERC20.safeTransfer(IERC20(token), _treasury, tokenAmountToTreasury);
  // ..
}

oldBalance and newBalance are equal when

Storage variable _token of the SurplusBeneficiary contract could be declared immutable, which would reduce the gas required to access it, as it is only set in the contract’s constructor.

Functions setFeeDistributor and setTreasury of the SurplusBeneficiary contract could implement a check that ensures the new value, which is being set, is not equal to the old one.

When setting the FeeDistributor contract for the SurplusBeneficiary, infinite USDC approval is also given to it. An alternative approach would be to set the approval (in function SurplusBeneficiary::dispatch) to the amount transferred prior to every transfer happening to avoid the dangers that come with approving a contract for an infinite amount. Of course, there is a tradeoff; the extra approve call happening in every call of dispatch would translate in higher gas costs, which could be considered bearable as the protocol is deployed on Optimism.

There is no check to ensure the whitelist debt threshold cannot be set to a value that would be less than the default debt threshold. This might be intentional but the term “whitelist” could have users expect that their debt threshold can only increase from the default.

The contracts were compiled with the Solidity compiler v0.7.6 which, at the time of writing, has a few known bugs. We inspected the bugs listed for this version and concluded that the subject code is unaffected.