OptionBlitz security record

Throughout the codebase there is commented out code and TODO comments. The lines are given for `StakingContract`, however, they exist throughout many of the other files in the codebase as well. The commented out code was not audited and any TODO comments were not considered during the audit.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=525 barrier = leverage.sub(Abdk._1).div(leverage).mul(assetPrice); ``` --- ```solidity=527 barrier = leverage.add(Abdk._1).div(leverage).mul(assetPrice); ```

In the whitepaper (see [https://www.optionblitz.co/static/media/optionblitz_whitepaper.ce295a0d387dd3ce94b9.pdf](https://www.optionblitz.co/static/media/optionblitz_whitepaper.ce295a0d387dd3ce94b9.pdf)) it states: "In the case of Optionblitz, 5% of any tokens which are un-staked will be collected as fees and dedicated towards buyback & LP. Since the fees are already collected in LP tokens, those tokens would just directly be burned." However, when `withdraw()` is called and tokens are un-staked only `BLX` is subjected to a 5% fee and the fee is taken in BLX, which is not an LP token, and then burned.

A local variable is shadowing another component defined elsewhere. This means that when the contract accesses the variable by its name, it will use the one defined locally, not the one defined in the other place. The use of the variable may lead to unexpected results and unintended behavior. ```solidity=88 constructor(address _trustedForwarder, address _usdToken, address _blxToken) ERC2771Context(_trustedForwarder) ``` - Local variable `_trustedForwarder` in `StakingContract.constructor` shadows the variable `_trustedForwarder` in `ERC2771Context`. --- ```solidity=95 constructor(address _trustedForwarder, address _usdToken, address _blx, address _treasury) ERC2771Context(_trustedForwarder) { ``` - Local variable `_trustedForwarder` in `Affiliate.constructor` shadows the variable `_trustedForwarder` in `ERC2771Context`.

The functions `setDisallowDerivative()` take a boolean value named `allowed` as a parameter to allow or disallow a specific derivative: - if `allowed` is true then the derivative is disallowed; - if `allowed` is false then the derivative is allowed; This is counterintuitive and could potentially lead to unexpected mistakes when allowing or disallowing a derivative.

In `OptionBase` is defined `minBet` and declared `_checkMinInvestment()`, this function is defined in the options contracts allowing to set `minBet` to any value, however `_checkMinInvestment()` and `minBet` are never used for check purposes meaning that no minimum amount is required to bet.

In `OptionAmerican`, the following numbers declarations are expected to correspond to specific percentages: ```solidity=59 int128 public commissionRate = int128(18446744073709552); // 1/1000 = 0.1 percent int128 public commissionRateBLX = int128(138350580552821637) / 10; //0.075 percent int128 public constant DEFAULT_PROFIT_FACTOR = int128(22136092888451461120); // 1.2 ``` For `commissionRate`, `int128(18446744073709552)` seems to be the exact number rounded up: `18446744073709551.616`. \ For `commissionRateBLX`, `int128(138350580552821637)` seems to be the exact number rounded down: `138350580552821637.12`. \ For `DEFAULT_PROFIT_FACTOR`, `int128(22136092888451461120)` seems incorrect as the exact number would be `22136092888451461939.2`.

Performing division by zero would raise an error and revert the transaction. The `Formula` contract is made to be used by other contracts to do specific computations, currently, the entry points on these functions prevent having a division by zero, however for future development, this could cause unexpected mistakes as the new contracts using the formulas might create new entry points, moreover, the error message returned when dividing by zero might be too generic and be less helpful when trying to trace the failure of a transaction. --- ```solidity=75 int128 result = S.div(K); ``` The expression `S.div(K)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=77 result = result.div(hv); ``` The expression `result.div(hv)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=92 int128 result = S.div(K); ``` The expression `S.div(K)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=94 result = result.div(hv); ``` The expression `result.div(hv)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=116 d1.neg().CND() .mul(S).div(K) ``` The expression `d1.neg().CND().mul(S).div(K)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105726]. --- ```solidity=525 barrier = leverage.sub(Abdk._1).div(leverage).mul(assetPrice); ``` The expression `leverage.sub(Abdk._1).div(leverage)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=527 barrier = leverage.add(Abdk._1).div(leverage).mul(assetPrice); ``` The expression `leverage.add(Abdk._1).div(leverage)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=539 notional = investment.div(divider); ``` The expression `investment.div(divider)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=542 notional = investment.div(divider); ``` The expression `investment.div(divider)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=133 _res = _res.div(optionPrice); ``` The expression `_res.div(optionPrice)` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727]. --- ```solidity=112 int128 K = _1.div(x.abs().mul(_b1).add(_1)); ``` The expression `_1.div(x.abs().mul(_b1).add(_1))` may divide by zero. Its divisor has an estimated interval [-170141183460469231731687303715884105728, 170141183460469231731687303715884105727].

One or more statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality. ```solidity=655 account; ``` --- ```solidity=656 amount; ``` --- ```solidity=661 account; ``` --- ```solidity=662 amount; ``` --- ```solidity=667 account; ``` --- ```solidity=463 N_lot; ``` --- ```solidity=51 _dataVersion; ``` --- ```solidity=61 _data; ``` In addition, the state variable `volatilityFactor` and the function `setFactorF())` do not affect the functionality of the codebase and appear to be either remnants of test code or older functionality.

In `DoubleNoTouch.bet_close()`, in the following snippet: ```sol=92 historyVolatility.parsePythPrice{value: msg.value}( b.derivativeId, minPriceUpdateData, // price at time open b.timeOpen, maxPriceUpdateData, // price at time close b.timeClose); ``` The values returned by `historyVolatility.parsePythPrice()` are never checked.