# Existing buyer who has been regularly renewing protection will be denied renewal even when she is well within the renewal grace period

Carapace renewal flow reuses new-protection check that rejects LateWithinGracePeriod loans, denying existing buyers a legitimate renewal within grace period.

- Payout: Contest reward
- Severity: high
- Program: Carapace
- Credited: 0Kage
- Disclosed: 2023-02-01
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-carapace-judging/issues/174
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-carapace%3AH-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** ProtectionPool.sol renewProtection / _verifyAndCreateProtection
**Root cause:** renewProtection calls _verifyAndCreateProtection, which invokes _verifyLendingPoolIsActive and reverts on LateWithinGracePeriod/Late status, even though the buyer already passed verifyBuyerCanRenewProtection and is within the renewal grace window.
**Steps:**
1. Buyer holds protection NFT on a lending pool and renews regularly.
2. Protection expires; loan transitions Active -> LateWithinGracePeriod one second later.
3. Buyer calls `renewProtection` within the renewal grace period.
4. verifyBuyerCanRenewProtection passes, but _verifyAndCreateProtection -> _verifyLendingPoolIsActive reverts with `LendingPoolHasLatePayment`.
5. Renewal denied; buyer loses prior premiums and cannot re-enter until pool returns to Active.
**How found:** Code reading of renewProtection flow: noticed it reuses the new-protection verification path, so the late-payment guard intended for new buyers also blocks renewals that should be allowed within the grace period.
**Insight:** When a renewal path reuses the creation-path validation, check each guard for whether it should apply to existing holders—status gates meant to prevent new risk-taking often wrongly block legitimate renewals.