QA Report

[code423n4]

Missing events for critical actions

In order to ensure proper traceability it is recommended to emit events when critical variables are updated. The following functions do not emit any events to signal value changes:

• MarketPlace.sol: setPool, setPrincipal, setAdmin
• Lender.sol: setMarketPlace, setFee, setAdmin, setSwivel, pause
• Redeemer.sol: setAdmin, setMarketPlace, setLender, setSwivel

Low liquidity could result in bad prices when selling a principal token

MarketPlace's sellPrincipalToken seems to use market value without the possibility of specifying a minimum expected amount out.

Lender does not allow resetting previous approvals

Note to reviewer: I think this one could maybe represent a MEDIUM level risk.

Lender.sol contains approve methods for single and bulk approvals. However, no way to reset these approvals is available. This means that in the case of a buggy approved redeemer or a wrong address being approved, there would be no way to revoke the approval, potentially putting funds in danger until the lender can be redeployed and funds moved to a new contract.

Multiple reentrancy vectors

Note to reviewer: I think this one could maybe represent a MEDIUM level risk.

Several functions in Lender.sol and Redeemer.sol perform external calls to user-provided contracts, therefore allowing reentrancy. While I did not manage to find a clear exploitation path, restricting reentrancy to lend() and redeem() methods would be recommended to err on the safe side.

• ISense(d).redeem(o, m, amount); where d is user-supplied
• purchased = IElement(e).swap(swap, fund, r, d); where e is user-supplied
• } else if (ISense(s).pt() != address(token)) { where s is user-supplied
• } else if (ISense(x).maturity() > m) where x is user-supplied
• uint256 returned = IAPWineRouter(pool).swapExactAmountIn(i, 1, lent, 0, r, address(this)); where pool is user-supplied
• IAave(aave).deposit(u, lent, address(this), 0); where aave is user-supplied
• uint128 returned = IYield(y).sellBasePreview(Cast.u128(a)); where y is user-supplied (see here and here for non-internal function usage)

Could use more descriptive names

Single letter variable names are used throughout the contracts. While these are in general not hard to figure out, using a more descriptive naming convention could help code readability.