Function: depositIntoFund(bytes32 salt, uint96 amount)

Deposit a particular amount into an STF for the manager to open a position. The fundraisingPeriod has to end, and the totalRaised should not be more than maxInvestmentPerStf. The amount has to be more than minInvestmentAmount. Approve has to be called before this method for the investor to transfer USDC to this contract.

Inputs

• salt

  • Control: User has full control over this input.

  • Constraints: The STF corresponding to this salt must exist.

  • Impact: Salt corresponding to legitimate STF must be provided.

• amount

  • Control: User has full control over this input.

  • Constraints: The user must have at least this deposit amount in their wallet, and it must be scaled to 18 decimals.

  • Impact: User must provide an 18-decimal--scaled amount of the deposit token they wish to deposit.

Branches and code coverage (including function calls)

Intended branches

Negative behavior

Function call analysis

• depositIntoFund -> getStfInfo(salt)

  • What is controllable? Salt.

  • If return value controllable, how is it used and how can it go wrong? Return value is controllable and is used to get the corresponding STF. It could go wrong if two STFs have the same salt; however, that appears in an improbable scenario.

  • What happens if it reverts, reenters, or does other unusual control flow? Function cannot revert, reenter, or do other unusual control flow.

• depositIntoFund -> IERC20(_stf.depositToken).decimals()

• What is controllable? Nothing, _stf.depositToken is unchangeable after STF creation.

  • If return value controllable, how is it used and how can it go wrong? Return value is not controllable and is used to get the number of decimals of the deposit token. It could go wrong if the deposit token has more than 18 decimals; however, it is an improbable scenario.

  • What happens if it reverts, reenters, or does other unusual control flow? The control flow is dependent on the deposit token, and as such, we suggest the protocol to exercise caution when whitelisting tokens.

• depositIntoFund -> IERC20(_stf.depositToken).balanceOf(msg.sender)

• What is controllable? msg.sender is somewhat controllable, as it is the address of the investor.

  • If return value controllable, how is it used and how can it go wrong? Return value is not controllable and is used to get the balance of the deposit token of the investor. It could go wrong if the protocol has whitelisted a malicious token.

  • What happens if it reverts, reenters, or does other unusual control flow? The control flow is dependent on the deposit token, and as such, we suggest the protocol to exercise caution when whitelisting tokens.

  • depositIntoFund -> IERC20(_stf.depositToken).transferFrom(msg.sender, address(this), depositAmount)

  • What is controllable? The deposit amount is controllable, as it is the amount the investor wants to deposit, and the msg.sender is controllable, as it is the address of the investor.

  • If return value controllable, how is it used and how can it go wrong? No return value in this function call. It could go wrong if the protocol has whitelisted a malicious token. Though by EIP20 standards, the return value should be true if the transfer is successful, and thus the protocol should be checking for that.

  • What happens if it reverts, reenters, or does other unusual control flow? The control flow is dependent on the deposit token, and as such, we suggest the protocol to exercise caution when whitelisting tokens.