Partial fill can result in leverage below MIN_LEVERAGE_BPS
finalizeOpen enforces leverage at or above 1x but does not enforce MIN_LEVERAGE_BPS (1.5x) on partial fills, so a 60% fill of a 2x position resolves at 1.2x. All downstream functions handle sub-1.5x leverage correctly; this is an accepted relaxation.
Description
When finalizeOpen processes a partial fill, leverage is recomputed from actualNotionalUsdcUnits:
position.leverageBps = uint32((actualNotionalUsdcUnits * Types.BPS_BASE) / position.collateralUsdcUnits);
The guard at line 643 enforces actualNotionalUsdcUnits >= collateralUsdcUnits (at or above 1x leverage) but does not enforce MIN_LEVERAGE_BPS (1.5x). A position created at 2x leverage with a 60% partial fill would resolve at 1.2x, below the protocol's stated minimum.
All downstream functions (close, settle, liquidate, force unwind) handle sub-1.5x leverage correctly. The alternative, rejecting partial fills below MIN_LEVERAGE_BPS, would force revertOpen, returning the user to the start of the lifecycle for what is otherwise a valid position. The cost-benefit favors accepting the sub-minimum leverage.
Recommendation
Document the partial-fill leverage relaxation in finalizeOpen's NatSpec so the inconsistency between the MIN_LEVERAGE_BPS constant (applied at createPosition) and the post-fill realized leverage is visible to future maintainers.
Resolution
Acknowledged as documented behavior. No code change.
