LUSD Chicken Bonds

Smart Contract Security Assessment

13.07.2022

SUMMARY​

ABSTRACT​

Dedaub was commissioned to audit the LUSD Chicken Bonds protocol. The LUSD Chicken Bonds protocol is a specific implementation of the General Chicken Bonds model which aims to acquire protocol-owned liquidity for the LUSD token at no cost while boosting the yield opportunities for end users.

SETTING AND CAVEATS​

The code and accompanying artifacts (e.g., test suite, documentation) are of excellent quality, developed with high professional standards. The overall financial logic is described in https://www.chickenbonds.org, with a detailed accompanying whitepaper.

The scope of the audit includes the ChickenBondManager contract as well as its direct dependencies and related tokens (BLUSD and Bond NFTs). Specifically, files:

BLUSDToken.sol

BondNFT.sol

ChickenBondManager.sol

utils/BaseMath.sol

utils/ChickenMath.sol

This audit report covers commit hash 6f32111942acc257e55337cac73f2843a22f15e8. Two auditors and a mathematician worked over the codebase over 1.5 weeks.

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than regular use of the protocol. Functional correctness (i.e., issues in "regular use") was a secondary consideration, however intensive efforts were made to check the correct application of the mathematical formulae in the reviewed code. Functional correctness relative to low-level calculations (including units, scaling, quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

The scope of the audit also included crypto-economic considerations. A number of checks have been carried out, however the crypto-economic effectiveness of this specific design is novel. Therefore, the financial viability of this protocol in real market conditions cannot be fully established. In terms of protocol completion, the protocol appears to be ready for staging.

The resolution of report items is determined by local inspection of changes, not a full re-audit. Therefore, locally sound fixes may have issues in a broader context. The development team is advised to be especially vigilant with testing the consequences of fixes performed after the initial audit.

PROTOCOL-LEVEL CONSIDERATIONS​

There are elements of the design that can have significant financial implications, yet cannot be attributed to a specific part of the code, but to the overall architecture. The main one is the functionality to remove LUSD from the Liquity Stability pool in order to support the peg on the price of LUSD (indirectly, through a Yearn vault) in a Curve meta pool of LUSD+3CRV.

Since the goal is for significant liquidity (in the hundreds of millions, as mentioned in accompanying documentation) through the Chicken Bonds facility, the financial considerations become non-negligible. Namely, LUSD will then become a prop for USDT, USDC, and DAI. For instance, in case of a USDT de-pegging (collapse to much below $1), the Curve pool token will be flooded with USDT. USDT holders will be able to exit to LUSD, through the meta pool (i.e., getting 3CRV tokens and swapping them for LUSD). A rise to the price of LUSD will be countered by the Chicken Bonds “shift” mechanism which allows shifting liquidity from the Stability Pool to add LUSD to Curve, effectively propping up USDT for as long as the ChickenBonds protocol has SP liquidity.

We bring this consideration to the protocol designers’ attention, for further discussion. The main threat is to Chicken Bonds investors (specifically, bLUSD holders, not bonders, since bonds are backed only by Stability Pool holdings, not Curve) but there may be wider consequences, such as pressure to LUSD and to Liquity, through large amounts of LUSD seeking to exit quickly.

A general protocol-level threat is that much of the design has been done with the implicit understanding that yield-bearing investments (to the SP or to Curve) never lose value (either on paper or in real terms). For instance, consider the whitepaper invariant "redemption price never decreases”. This is not an invariant, i.e., it is not literally true at all times. If there are investment losses, there is not enough LUSD to cover redemptions, so the invariant is not true when combined with the definition of “redemption price”:

"we call the amount of TKN for which each bTKN can be redeemed for the redemption price”.

We recommend to the development team a critical review of the stated properties with losses considered a possibility, however unlikely.

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues that affect the functionality of the contracts. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.

CRITICAL SEVERITY​

[No critical severity issues]

HIGH SEVERITY​

  uint256 private permanentLUSDInCurve; // Yearn Curve LUSD-3CRV vault
  …
  function shiftLUSDFromSPToCurve(uint256 _maxLUSDToShift) external {
    ...
    	uint256 permanentLUSDCurveIncrease = (lusdInCurve -
        lusdInCurveBefore) * ratioPermanentToOwned / 1e18;
    	permanentLUSDInCurve += permanentLUSDCurveIncrease;
    ...
  }

  function shiftLUSDFromCurveToSP(uint256 _maxLUSDToShift) external {
    ...
    uint256 permanentLUSDWithdrawn =
      lusdBalanceDelta * ratioPermanentToOwned / 1e18;
    permanentLUSDInCurve -= permanentLUSDWithdrawn;
    ...
  }

function getAcquiredLUSDInCurve() public view returns (uint256) {
  uint256 acquiredLUSDInCurve;

  // Get the LUSD value of the LUSD-3CRV tokens
  uint256 totalLUSDInCurve = getTotalLUSDInCurve();
  if (totalLUSDInCurve > permanentLUSDInCurve) {
    acquiredLUSDInCurve = totalLUSDInCurve - permanentLUSDInCurve;
  }

  return acquiredLUSDInCurve;
}

function redeem(uint256 _bLUSDToRedeem, uint256 _minLUSDFromBAMMSPVault)
external returns (uint256, uint256) {
  …
  uint256 acquiredLUSDInCurveToRedeem = getAcquiredLUSDInCurve() *
                                        fractionOfBLUSDToRedeem / 1e18;
  uint256 lusdToWithdrawFromCurve = acquiredLUSDInCurveToRedeem *
                                  (1e18 - redemptionFeePercentage) / 1e18;
  uint256 acquiredLUSDInCurveFee = acquiredLUSDInCurveToRedeem -
                                   lusdToWithdrawFromCurve;
  yTokensFromCurveVault =
    _calcCorrespondingYTokensInCurveVault(lusdToWithdrawFromCurve);
  if (yTokensFromCurveVault > 0) {
    yearnCurveVault.transfer(msg.sender, yTokensFromCurveVault);
  }

MEDIUM SEVERITY​

[No medium severity issues]

LOW SEVERITY​

function _firstChickenIn(uint256 _bondStartTime, uint256 _bammLUSDValue,
                         uint256 _lusdInBAMMSPVault) internal returns (uint256) {
  …
  // From Curve Vault
  uint256 lusdFromInitialYieldInCurve = getAcquiredLUSDInCurve();
  uint256 yTokensFromCurveVault =
    _calcCorrespondingYTokensInCurveVault(lusdFromInitialYieldInCurve);

  // withdraw LUSD3CRV from Curve Vault
  if (yTokensFromCurveVault > 0) {
    _withdrawFromCurveVaultAndTransferToRewardsStakingContract(
     yTokensFromCurveVault);
  }
  …
}
function _withdrawFromCurveVaultAndTransferToRewardsStakingContract(
 uint256 _yTokensToSwap) internal {
  uint256 LUSD3CRVBalanceBefore = curvePool.balanceOf(address(this));
  yearnCurveVault.withdraw(_yTokensToSwap);
  uint256 LUSD3CRVBalanceDelta = curvePool.balanceOf(address(this)) -
    LUSD3CRVBalanceBefore;
  // obtain LUSD from Curve
  if (LUSD3CRVBalanceDelta > 0) {
    uint256 lusdBalanceBefore = lusdToken.balanceOf(address(this));
    // Dedaub: attackable!
    curvePool.remove_liquidity_one_coin(LUSD3CRVBalanceDelta,
                                        INDEX_OF_LUSD_TOKEN_IN_CURVE_POOL, 0);

    uint256 lusdBalanceDelta = lusdToken.balanceOf(address(this)) -
                               lusdBalanceBefore;
    _transferToRewardsStakingContract(lusdBalanceDelta);
  }
}

OTHER/ ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

    	while (n > 1) {
        	if (n % 2 == 0) {
            	x = decMul(x, x);
            	n = n / 2;
        	} else { // if (n % 2 != 0)
            	y = decMul(x, y);
            	x = decMul(x, x);
            	n = (n - 1) / 2;
        	}
    	}

    	while (n > 1) {
        	if (n % 2 != 0) {
            	y = decMul(x, y);
        	}
           	x = decMul(x, x);
           	n = n / 2;
    	}

function _firstChickenIn(...) internal returns (uint256) {
    	assert(!migration);

   if (bLUSDToken.totalSupply() == 0 && !migration) {
     	lusdInBAMMSPVault =
        _firstChickenIn(bond.startTime, bammLUSDValue, lusdInBAMMSPVault);
   }

function shiftLUSDFromSPToCurve(uint256 _maxLUSDToShift) external {
  …
  (uint256 bammLUSDValue, uint256 lusdInBAMMSPVault) = _updateBAMMDebt();
  uint256 lusdOwnedInBAMMSPVault = bammLUSDValue - pendingLUSD;

  // Make sure pending bucket is not moved to Curve, so it can be
  // withdrawn on chicken out
  uint256 clampedLUSDToShift = Math.min(_maxLUSDToShift,
                                        lusdOwnedInBAMMSPVault);

  // Make sure there's enough LUSD available in B.Protocol
  clampedLUSDToShift = Math.min(clampedLUSDToShift, lusdInBAMMSPVault);
  // Dedaub: the above is unnecessary. _updateBAMMDebt has its first
  //  return value always be <= the second. So, clampedLUSTToShift
  // (which is <= _bammLUSDValue) will always be <= lusdInBAMMSPVault

CENTRALIZATION ASPECTS​

The design of the protocol is highly decentralized. The creation of bonds, chickening in/out and redemption of bLUSD tokens is all carried out without any intervention from governance. The shifter functions, ChickenBondManager::shiftLUSDFromSPToCurve and ChickenBondManager::shiftLUSDFromCurveToSP, which move LUSD between the Liquity stability pool and the curve pool are also public and permissionless.

The Yearn Governance address holds control of the protocol’s migration mode which prevents the creation of new bonds, among other changes. There is no way to deactivate migration mode. Although new users will not be able to join the protocol, all current users will still be able to retrieve their funds, either through ChickenBondManager::chickenOut or ChickenBondManager::redeem. Yearn governance decisions are voted on by all YFI token holders and are executed by a 6-of-9 Multisig address.

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.