Report for issue #371 updated by sorrynotsorry

data/Dup1337-Q.md

@@ -4,7 +4,7 @@
 | [L-02]  |`assertPriceWithinBounds` doesn´t validate bounds  |
 | [L-03]  | No possibility to liquidate big positions of esoteric tokens |
 | [L-04]  |  Validated bounds are not exlusive at `_validateAndForwardToAMM` |
-| [L-05]  |  |
+| [L-05]  | `deployNewPool` function can suffer users in re-orgs at some conditions  |
 | [L-06]  |  |
 | [L-07]  |  |
 | [NC-01]  | Deposit and mint sizes can be circumvented |
@@ -197,7 +197,26 @@ We recommend the implementation below:
 + if ((currentTick > tickLimitHigh) || (currentTick < tickLimitLow)) 
 ```
 
-## [L-05] 
+## [L-05] `deployNewPool` function can suffer users in re-orgs at some conditions
+The CollateralTracker deployment is based on `create` rather than `create2` as in PanoptiFactory deployment:
+```solidity
+Contract: PanopticFactory.sol
+
+240:         // Deploy collateral token proxies
+241:         CollateralTracker collateralTracker0 = CollateralTracker( 
+242:             Clones.clone(COLLATERAL_REFERENCE)
+243:         );
+244:         CollateralTracker collateralTracker1 = CollateralTracker(
+245:             Clones.clone(COLLATERAL_REFERENCE)
+246:         );
+247: 
+```
+
+So if Alice transacts her TX for `ColleteralTracker.deposit()` and if the chain is re-orged before her transfer, due to lagged confirmation, her funds will get lost irrecoverably.
+While the pool address can be derived again, the collateralTracker address can not. 
+
+
+We recommend exercising `COLLATERAL_REFERENCE.cloneDeterministic(salt)` for the collateral tracker deployment too rather than cloning the reference.
 
 ## [L-06]