# Liveness is erroneously reset for all owners when livenessguard is upgraded or replaced

LivenessGuard constructor resets lastLive for all Safe owners on upgrade, reviving inactive owners and indefinitely delaying liveness-based shutdown.

- Payout: Contest reward
- Severity: medium
- Program: Optimism
- Credited: ethan
- Disclosed: 2024-06-06
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_optimism_may2024.pdf#3.1.5
- Library page: https://bugbountylibrary.com/r/cantina%3Aoptimism_may2024%3A3.1.5
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:solidity technique:incomplete-fix technique:source-review vuln:business-logic

**Target:** LivenessGuard smart contract constructor
**Root cause:** Constructor unconditionally sets lastLive[owner]=block.timestamp for every Safe owner, with no awareness of prior guard state, so redeployment refreshes liveness of already-inactive owners.
**Steps:**
1. Deploy Safe with N owners and LivenessGuard; lastLive initialized to block.timestamp.
2. Owners go inactive approaching LIVENESS_INTERVAL.
3. Replace/upgrade LivenessGuard (e.g. bug fix).
4. New constructor iterates `_safe.getOwners()` and sets `lastLive[owner] = block.timestamp` for all.
5. Inactive owners' liveness refreshed; LivenessModule removal/shutdown delayed by another full interval.
**How found:** Code review of constructor initialization logic; recognized that first-deploy initialization semantics are wrong when contract is replaced, undermining LivenessModule's purpose.
**Escalation:** Repeated guard replacements can multiply effective LIVENESS_INTERVAL arbitrarily, indefinitely preventing removal of inactive owners and Safe shutdown/recovery.
**Insight:** When auditing upgradeable/replaceable contracts, check constructor initialization that assumes first deployment—state like timestamps or counters reset on replacement can silently defeat time-based invariants in dependent modules.