Harden freeze flag with timestamped grace window for un-freeze

[ibrahimmosouf-png]

Harden freeze flag with timestamped grace window for un-freeze

Labels: security, enhancement, priority/medium
Difficulty: Medium · Effort: S
Backlog slot: 8

Problem Statement

set_frozen(true/false) are immediate toggles. If an admin key is compromised, an attacker can flip unfreeze() instantly after the legitimate admin freeze, defeating emergency response.

Why it Matters

• A delay window (e.g. 1 hour between successive freeze/unfreeze) protects against key-compromise response races.

Expected Outcome

1. Persist set_frozen_at: u64 whenever freeze state changes.
2. unfreeze() requires current-time >= set_frozen_at + MIN_UNFREEZE_DELAY.
3. Make MIN_UNFREEZE_DELAY configurable.

Acceptance Criteria

• Test shows unfreeze() panics with Error::UnfreezeTooEarly if invoked within delay window.
• Existing freeze tests still pass.

Files Likely Affected

• campaign/src/lib.rs, campaign/src/storage.rs, campaign/src/types.rs

Dependencies

Issue #5 (multi-sig admin) — needs separate signing on freeze/unfreeze.

---

[neromtoobad]

Hi, I'd like to work on this issue. I just delivered the timelock + multi-sig admin governance flow for #92 (PR #203), which reworks this exact freeze/unfreeze surface, and our merged PRs (#171, #173, #180) cover the campaign contract end to end. I can deliver in 12 hrs. Looking forward to contributing.

[grantfox-oss]

🦊 GrantFox — @neromtoobad has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #95)
2. Your PR will be reviewed by the OrbitChainLabs maintainers

Good luck! Track your progress on GrantFox.