Function: openSpot(uint96 amount, bytes calldata commands, bytes[] calldata inputs, uint256 deadline)

Opens a spot position using the universal router (swaps from depositToken to baseToken) and can only be called by the manager of the STF.

Inputs

• amount

  • Control: User has full control over this input, given they are manager of the STF.

  • Constraints: The contract must hold the amount of depositToken specified by the user.

  • Impact: User can only trade as much as the contract holds.

• commands

  • Control: User has full control over this input, given they are manager of the STF.

  • Constraints: Acceptable by Uniswap V3 as this param is passed directly to the router.

  • Impact: User has full control over the swap as long as it is acceptable by Uniswap V3 and they are a a manager of the STF.

• inputs

  • Control: User has full control over this input, given they are manager of the STF.

  • Constraints: Acceptable by Uniswap V3 as this param is passed directly to the router.

  • Impact: User has full control over the swap as long as it is acceptable by Uniswap V3 and they are a manager of the STF.

• deadline

  • Control: User has full control over this input, given they are manager of the STF.

  • Constraints: Acceptable by Uniswap V3 as this param is passed directly to the router.

  • Impact: User has full control over the swap as long as it is acceptable by Uniswap V3 and they are a manager of the STF.

Branches and code coverage (including function calls)

Intended branches

Negative behavior

Function call analysis

• openSpot -> spot.getManagerCurrentStfInfo(msg.sender)

• What is controllable? msg.sender to the extent that it is the manager of the STF.

  • If return value controllable, how is it used and how can it go wrong? Return value is the corresponding STF and could go wrong if the wrong STF is returned; however, that does not appear the case.

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

• openSpot -> _openSpotCheck(_stf, amount)

• What is controllable? The STF to the extent that it is the manager of the STF.

  • If return value controllable, how is it used and how can it go wrong? Return value is the swap amount scaled to the correct decimal units and could go wrong if the wrong amount is returned; however, that does not appear the case.

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

• openSpot -> _openSpotUpdate(_stf, amount, swapAmount, commands, inputs, deadline)

  • What is controllable? The STF to the extent that it is the manager of the STF.

  • If return value controllable, how is it used and how can it go wrong? Return value is the amount received after the swap and could go wrong if the wrong amount is returned. One thing that is interesting is that this number is not scaled to 1e18 before saving it for the stf.totalReceived variable. This is unlike stf.totalAmount, which is scaled to 1e18 before saving it. This is unlike depositIntoFund, where the stf.totalAmount is scaled to 1e18 first. Having a consistent measure of scaling for the STF state variables would be good; however, there appears to be nothing problematic about the current setup.

  • What happens if it reverts, reenters, or does other unusual control flow? Cannot revert or do any unusual control flow. Reentrancy may be possible if the swap is a flash swap; however, this is not the case for the current implementation or an ERC777 token is traded.