# High/Medium severity issues

## High severity
## Issue #297
- Try the PoC
- Prove the PoC false
- @Cv8TLV-0Q_avuQ_dvJNXJg

## Issue #283
- Unlikely to be true
- Test it out if time permits
- Go trhough the logic
- @Cv8TLV-0Q_avuQ_dvJNXJg
- status: disputed
- process.updateProcess() is called in the V2Option::burn() which takes into account the tokens being burnt
## Issue #270
- Economically not feasible
- Prove it mathematically impossible
- @ricsson
- status: disputed
- When the sqrt interest rate is set as uint160.max. This means that adding 1 wei of liquidity requires 1 wei of long and uint160.max * duration / (2^128) wei of short. This means it require at least that amount of token0 or token1 to be added into the pool. For example if the duration of the pool is 86400 seconds (1 day). The amount of short required is 371,085,174,374,400 wei.Suppose token0 is the base, this means we require 371,085,174,374,400 wei of token0 to be deposited for 1 wei of liquidity. Also when the interest rate is at uint160.max, an arbitrageur (or the LP) can push the interest rate down by making a deleverage transaction with small amount of token0 or token1. This behavior is very similar to how in Uniswap, even if an LP initialized with a bad sqrt price, anyone can arbitrage it and push the price towards the real market spot price. Suppose we want to push the sqrt interest rate to less than 93,228,045,731,763,962,592,705,371,899,114,578 (which is roughly 10% APR). Will only require 1 wei of long to easily push the sqrt interest rate down.
## Issue #269
- Already fixed
- Explain the Fix
- @Cv8TLV-0Q_avuQ_dvJNXJg
- status: resolved
- This issue was also identified internally and fixed to

## Issue #251
- Issue in enumerability
- Counter should beincrement
- @ricsson
## Issue #194
- Economic incentive for arbitrage
- Increaseing (x+y) doesnt affect the sqrtInterestRate, thus excess incentivizes rebalancing
- @ricsson
- status: disputed
- The arbitrageur adding more input than necessary will hurt the arbitrageur himself. But doing rebalancing does not change the sqrt interest rate variable. The protocol will treat the required number of longs as the only amount withdrawable. Any excess long due to a rebalancer adding more than necessary will be ignored. But it still provides other arbitrageurs the opportunity to rebalance those excess long amount, but those excess long amount, whether it is long0 or long1 can never be withdrawn ever again, which is the loss of the arbitrageur who added more than necessary. Therefore, the arbitrageur is simply burning his own tokens.

## Issue #192
- Issue with the periphery
- @Cv8TLV-0Q_avuQ_dvJNXJg 
- status: disputed
- The long tokens required is the maximal bound and hence the code is structured accordingly. The long that is dispersed depends on the calculation based on the short given

## Issue #191
- Similar to #192
- @Cv8TLV-0Q_avuQ_dvJNXJg 
- status: disputed
- The long tokens required is the maximal bound and hence the code is structured accordingly. The short that is dispersed depends on the calculation based on the Long given

## Issue #187
- Similar to #192
- @Cv8TLV-0Q_avuQ_dvJNXJg 
- status: disputed
- This is by design to offer users the flexibility in using the protocol. 
- The protocol is ideally interfaced via a periphery where sane defaults are chosen



## Issue #121
- Already fixed, double check by @ricsson


## Issue #94
- Prove the poc wrong
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Medium Severity

## Issue #291
- Implement the fix
- Prove the poc
- @ricsson


## Issue #261
- Not relavent
- Based on ERC721
- status: disputed
- Maybe change the name from `totalSupply()`

## Issue #250
- Check the PoC
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #246
- Similar to #192
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #236
- Not relevant, by design
- @ricsson
- status: disputed
- Some short amount is always withdrawn from the pool and moved to the short fee growth of liquidity providers. Thus total short in the pool decreases every second following a linear decay. This functionaly happens in Duration.update(...) function. For LP to withdraw the short withdrawn to their fee growth. They have to call collect transaction fees.
## Issue #228
- Review the issue
- @ricsson @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #227
- Review the math and fix it
- @varun to test it
- @ricsson

## Issue #221
- Review and add an explaination
- @Cv8TLV-0Q_avuQ_dvJNXJg 
- status: disputed
- The collect function utilises the process.updateProcess() which takes into account the reentrancy

## Issue #197
- Possible revert
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #182
- Overflow checks missing
- Apply the provided mitigation steps
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #158
- Review it
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #85
- Strike not zero, revert
- @Cv8TLV-0Q_avuQ_dvJNXJg 

## Issue #73
- Liquidity position transfer to oneself
- @ricsson
- status: disputed
- The fee growth gets updated once in Duration.update(...) function. When a user transfer liquidity to oneself. Their fee state for “from” address which is the user, gets updated once. It does not update again when the fee state for “to” address which is also the user, does not get updated anymore.

## Issue #52
- Not supported
- status: disputed
- This is currently not supported by design