Read the findings of the 2022 Web3 Security Report

The main function of the `Lambda DAO` protocol is providing a reserve currency protocol with two functionalities: staking and bonding. Bonding is used to acquire the reserve assets by selling `LMDA`. And staking is used to lock `LMDA` and receive an equal amount of `sLMDA` and vice versa. 

And then, there are some questions:

1. The bond price for selling the `LMDA` by bonding is `terms.controlVariable.mul( debtRatio() ).add( 1000000000 ).div( 1e7 )`. `controlVariable` is a centrally set variable. `debtRatio()` is `currentDebt / IERC20(LMDA).totalSupply()` where `currentDebt` can be increased by depositing and decreased by time passing. As a result, the bond price is a little complex and not predictable. The only thing is certain is that the bond price is larger than 1.
2. The bond price does not consider the outside `_token` and `LMDA` prices. Thus, the bond price may be decoupled from market prices. Malicious users can leverage this for arbitrage.
3. The staking reward is the `sLMDA` token and the minted rewards do not have reserve token backed. Also, in the contract `Treasury`, the debtor role can borrow the reserved `_token` token holding `sLMDA` without paying any token assets and the borrowing time does not have a limitation. As a result, the reserved `_token` token maybe not be sufficient for stabilizing the `LMDA` price.
4. The staking mechanism is based on the `rebase()` functionality. The rebase can be triggered by the `stake()` and the `unstake()`. The rebase amount is also has a positive relationship with the staking amount. This means that the `_totalSupply` of `sLMDA` will increase an amount in proportion to the users' staking amount. This will affect the price of `sLMDA` if it can be traded outside the protocol. 
    
We would like to confirm with the client if the current implementation aligns with the original project design.

Financial models

In BondDepository.sol contract:
```solidity
function deposit( 
  uint _amount, 
  uint _maxPrice,
  address _depositor
) external returns ( uint ) {
  require( _depositor != address(0), "Invalid address" );

  decayDebt();
  ......
  
  uint value = ITreasury( treasury ).valueOf( principle, _amount );
  uint payout = payoutFor( value );
  
  ......
  adjust(); //**COMMENT from CertiK: This function is used to modify the value of variable terms.controlVariable according to the value of adjustment.add. When adjustment.add is TRUE, terms.controlVariable increases each time, otherwise terms.controlVariable decreases each time.**
```
```solidity
function decayDebt() internal {
  totalDebt = totalDebt.sub( debtDecay() );
  lastDecay = block.number;
}
    
function payoutFor( uint _value ) public view returns ( uint ) {
  return FixedPoint.fraction( _value, bondPrice() ).decode112with18().div( 1e16 );
}

function bondPrice() public view returns ( uint price_ ) {        
  price_ = terms.controlVariable.mul(debtRatio()).add(1000000000).div( 1e7 );
  if ( price_ < terms.minimumPrice ) {
    price_ = terms.minimumPrice;
  }
}

function debtRatio() public view returns ( uint debtRatio_ ) {   
  uint supply = IERC20(LMDA).totalSupply();
  debtRatio_ = FixedPoint.fraction( 
    currentDebt().mul(1e9), 
    supply
  ).decode112with18().div(1e18);
}

function currentDebt() public view returns (uint) {
  return totalDebt.sub(debtDecay());
}

function debtDecay() public view returns (uint decay_) {
  uint blocksSinceLast = block.number.sub(lastDecay);
  decay_ = totalDebt.mul(blocksSinceLast).div(terms.vestingTerm);
  if (decay_ > totalDebt) {
    decay_ = totalDebt;
  }
}
```

In the Treasury.sol contract:
```solidity
function valueOf(address _token, unit _amount) public view returns (uint value_) {
  if (isReserveToken[_token]) {
    // convert amount to match LMDA decimals
    value_ = _amount.mul(10**IERC20(LMDA).decimals()).div(10**IERC20(_token).decimals());
  } else if (isLiquidityToken[_token]) {
    value_ = IBondCalculator(bondCalculator[_token]).valuation(_token, _amount);
  }
}
```

Referring to the above code and taking `ReserveToken` as an example, the bond price can be expressed as the following formulas:

$$
\begin{align}

bondAmount &= \frac{Value}{bondPrice \times 10^{16}} && \tag 1\\ 

bondPrice &= controlVariable \times \frac{totalDebt'}{totalSupply \times 10^9} + 100 && \tag 2\\ 

totalDebt' &= totalDebt \times \left( 1 - \frac{\Delta block}{vestingTerm} \right) && \tag 3\\ 

where \ \  & \Delta block \leq vestingTerm && \notag\

\end{align}
$$

- $Value :$ the amount of reserve tokens paid by users
- $controlVariable :$ `terms.controlVariable` whose rise and fall is controlled by function `adjust()`
- $\Delta block :$ the current `block.number` minus the `block.number` at the last call
- $vestingTerm :$ the total number of blocks for bond issuance set by the `owner`
- $totalDebt :$ record the total issuance of bonds
- $totalDebt' :$ record the latest total issuance of bonds
- $totalSupple :$ record the total issuance of `LMDA` token

At the same time, referring to the following function `adjust()`, we can see that the change direction of the coefficient `controlVariable` in the bond price is determined by the variable `adjustment.add`:

- `controlVariable` keeps increasing when `adjustment.add` is `TRUE`
- `controlVariable` keeps decreasing when `adjustment.add` is `FALSE`

```solidity
function adjust() internal {
  uint blockCanAdjust = adjustment.lastBlock.add( adjustment.buffer );
  if(adjustment.rate != 0 && block.number >= blockCanAdjust) {
    uint initial = terms.controlVariable;
    if (adjustment.add) {
      terms.controlVariable = terms.controlVariable.add( adjustment.rate );
      if (terms.controlVariable >= adjustment.target) {
        adjustment.rate = 0;
      }
    } else {
      terms.controlVariable = terms.controlVariable.sub(adjustment.rate);
      if (terms.controlVariable <= adjustment.target) {
        adjustment.rate = 0;
      }
    }
    adjustment.lastBlock = block.number;
    emit ControlVariableAdjustment(initial, terms.controlVariable, adjustment.rate, adjustment.add);
  }
}
```

Potential Bond Price Rigging

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing emit events

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing error messages

In the function `deposit()` in contract `TGTBond`, the require statement in L220 checks `totalDebt <= terms.maxDebt` to ensure that the depositing does not exceed `terms.maxDebt`. After the depositing, the new deposit value will be added to `totalDebt` in L242. Thus, the current depositing may still result that `totalDebt` exceeds `terms.maxDebt` and only the next depositing will be blocked.

Logic issue in function `deposit()`

The function `_bondPrice()` update the bond price with the `terms.controlVariable` set by the contract owner. It will check whether the `price_` is less than `terms.minimumPrice` and make sure the new price is greater than `terms.minimumPrice`. However, when the `price_` is greater than or equal to `terms.minimumPrice` at the beginning, the value of `terms.minimumPrice` is set to 0 making the latter min price checking invalid.

```solidity=1005
    function _bondPrice() internal returns ( uint price_ ) {
        price_ = terms.controlVariable.mul( debtRatio() ).div( 1e5 );
        if ( price_ < terms.minimumPrice ) {
            price_ = terms.minimumPrice;        
        } else if ( terms.minimumPrice != 0 ) {
            terms.minimumPrice = 0;
        }
    }
```

Logic issue in function `_bondPrice()`

In the contract, `Distributor`, the role, `policy`, has authority over the functions.

- `addRecipient`: add a new recipient to accept the rewards.
- `removeRecipient`: remove the recipient who can accept the rewards.
- `setAdjustment`: set the `adjustment` to adjust the rewards.
- 
Any compromise to the `policy` account may allow the hacker to take advantage of this authority and add some recipients to accept rewards.


Centralization Risk in StakingDistributor.sol

In the contract, `LambdaStaking`, the role, `locker`, has authority over the functions shown in the diagram below.

Any compromise to the `locker` account may allow the hacker to take advantage of this authority and take out all the tokens.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaStaking-locker.svg)

the role, `_owner`, has authority over the functions below.

- `setContract`: set the address of `distributor`, `warmupContract`, and `locker`.
- `setWarmup`: set `warmupPeriod`.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and paralyze the contract.

Centralization Risk in Staking.sol

To claim the `sLMDA` from the `warmupContract`, the current `epoch.number` should more than `info.expiry`. The only way to increase the `epoch.number` is the function `rebase()`. So the last user stakes token into this contract. If he/she wants to claim, he/she needs to increase the `epoch.number` by calling the `rebase()`.

Last staking issue


In the contract, `LambdaTreasury`, the role, `Debtor`, has authority over the functions shown in the diagram below.

Any compromise to the `Debtor` account may allow the hacker to take advantage of this authority and borrow tokens from the contract.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaTreasury-isDebtor.svg)

In the contract, `LambdaTreasury`, the role, `LiquidityDepositor`, has authority over the functions shown in the diagram below.

Any compromise to the `LiquidityDepositor` account may allow the hacker to take advantage of this.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaTreasury-isLiquidityDepositor.svg)

In the contract, `LambdaTreasury`, the role, `LiquidityManager`, has authority over the functions shown in the diagram below.

Any compromise to the `LiquidityManager` account may allow the hacker to take advantage of this authority and take out tokens in the contract.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaTreasury-isLiquidityManager.svg)

In the contract, `LambdaTreasury`, the role, `ReserveDepositor`, has authority over the functions shown in the diagram below.

Any compromise to the `ReserveDepositor` account may allow the hacker to take advantage of this.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaTreasury-isReserveDepositor.svg)

In the contract, `LambdaTreasury`, the role, `ReserveManager`, has authority over the functions shown in the diagram below.

Any compromise to the `ReserveManager` account may allow the hacker to take advantage of this authority and take out tokens in the contract.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaTreasury-isReserveManager.svg)

In the contract, `LambdaTreasury`, the role, `RewardManager`, has authority over the functions shown in the diagram below.

Any compromise to the `RewardManager` account may allow the hacker to take advantage of this authority and take out tokens in the contract.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/LambdaTreasury-isRewardManager.svg)

In the contract, `Ownable`, the role, `_newOwner`, has authority over the functions shown in the diagram below.

Any compromise to the `_newOwner` account may allow the hacker to take advantage of this authority and transfer the ownership to the other user.

![](https://accelerator-tasks-prod.s3.amazonaws.com/39d6f6fdc8264fb0b459e07ceee91424/Ownable-_newOwner.svg)

In the contract, `LambdaTreasury`, the role, `ReserveSpender`, has authority over the functions.

  - `withdraw()`: withdraw the specified amount token.

Any compromise to the `ReserveSpender` account may allow the hacker to take advantage of this authority and transfer the ownership to the other user.


Centralization Risk in Treasury.sol

By calling the function `incurDebt()` of contract `Treasury`, the users can borrow the `_token` token when they own `sLMDA`. The maximum borrow amount is equivalent to the users' `sLMDA` balances. This may cause problems because the `sLMDA` can still be transferred to anybody else. For example, user A has 100 `sLMDA`, so he borrows 100 `_token`. Then A transfers these `sLMDA` to B, then B can also borrow 100 `_token` and so on and so forth. The assets in `Treasury` may suffer a loss. 

We would like to confirm with the client if the current implementation aligns with the original project design.

Logic issue in function `incurDebt()`

In the function `mintRewards()` in contract `Treasury`, the addresses contained in the `rewardManagers` list can mint arbitrary amount of the reward `LMDA` token to any arbitrary addresses, which will cause many problem like sharp drop of the `LMDA` price.

Also, since only the address which has the `vault` role in the `LMDA` contract can mint `LMDA`, the `vault` needs to be set to the contract `Treasury`, otherwise the function `mintRewards()` will fail.

Reward manager

```solidity=294
function deposit( uint _amount, address _token, uint _profit ) external returns ( uint send_ ) {
  require( isReserveToken[ _token ] || isLiquidityToken[ _token ], "Not accepted" );
  IERC20( _token ).safeTransferFrom( msg.sender, address(this), _amount );

  if ( isReserveToken[ _token ] ) {
    require( isReserveDepositor[ msg.sender ], "Not approved" );
  } else {
    require( isLiquidityDepositor[ msg.sender ], "Not approved" );
  }

  uint value = valueOf(_token, _amount);
  // mint LMDA needed and store amount of rewards for distribution
  send_ = value.sub( _profit );
  IERC20Mintable( LMDA ).mint( msg.sender, send_ );
```

```solidity=467
function valueOf( address _token, uint _amount ) public view returns ( uint value_ ) {
  if ( isReserveToken[ _token ] ) {
    // convert amount to match LMDA decimals
    value_ = _amount.mul( 10 ** IERC20( LMDA ).decimals() ).div( 10 ** IERC20( _token ).decimals() );
  } else if ( isLiquidityToken[ _token ] ) {
    value_ = IBondCalculator( bondCalculator[ _token ] ).valuation( _token, _amount );
  }
}
```

The `Treasury.deposit()` function is merely called by the `ReserveDepositor` and `LiquidityDepositor` listing users, and the number of bonds transferred to the caller is determined by the input parameter ( $\_amount - \_profit$ ). And referring to the `BondDepository.deposit()` function, this bond price is much lower than the other users. This may hit the market price of `LMDA` token.

Privileged Bond Price

```solidity=320
function withdraw( uint _amount, address _token ) external {
  require( isReserveToken[ _token ], "Not accepted" ); // Only reserves can be used for redemptions
  require( isReserveSpender[ msg.sender ] == true, "Not approved" );

  uint value = valueOf( _token, _amount );
  ILMDAERC20( LMDA ).burnFrom( msg.sender, value );

  totalReserves = totalReserves.sub( value );
  emit ReservesUpdated( totalReserves );

  IERC20( _token ).safeTransfer( msg.sender, _amount );

  emit Withdrawal( _token, _amount, value );
}
```

The users in the list `isReserveSpender` can redeem the reserve assets by the function `Treasury.withdraw`, and the list `ReserveSpender` is set by the `owner`. The value of burned `LMDA` token does not take the market price from a Price Oracle. This means the caller may get more value of the Reserve asset than he burned.

Privileged Users Withdraw Reserve Asset

LambdaDAO

LambdaERC20.sol

sLambdaERC20.sol

LambdaDAO

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

14

0

13

0

1