[Admin] Add emergency pause circuit breaker for geev-core

[3m1n3nc3]

Description

geev-core has no circuit breaker. AdminContract::admin_withdraw (admin.rs:60) can rescue funds after an incident, but nothing can stop new value from entering or moving while that incident is being handled: create_giveaway, create_giveaway_with_selection, enter_giveaway, donate, claim_prize, and claim_help_request_funds all remain callable. DataKey has no paused flag, and check_admin is the only gate in access.rs.

The result is that the only tool available during an active exploit is draining the contract, which is disruptive to every unaffected giveaway and help request.

User Story

As an Admin,
I want to pause state-changing contract entrypoints during an incident,
so that I can stop an exploit without draining funds from unaffected campaigns.

Requirements and Context

• Files / refs: contracts/geev-core/src/admin.rs, contracts/geev-core/src/access.rs, contracts/geev-core/src/types.rs, contracts/geev-core/src/giveaway.rs, contracts/geev-core/src/mutual_aid.rs, contracts/geev-core/src/test.rs
• Add a DataKey::Paused flag in instance storage, defaulting to false
• Add admin-gated pause(env) / unpause(env) using the existing check_admin helper
• Add a require_not_paused(&env) guard in access.rs and apply it to value-moving entrypoints
• Emit ContractPaused / ContractUnpaused events, matching the existing #[contractevent] style
• Escape hatches must stay callable while paused: admin_withdraw, unpause, and all read-only getters

Suggested Implementation

1. Add DataKey::Paused and a new Error::ContractPaused variant
2. Add pause/unpause to AdminContract, both behind check_admin
3. Add require_not_paused to access.rs
4. Guard create_giveaway, create_giveaway_with_selection, enter_giveaway,
   donate, claim_prize, and claim_help_request_funds
5. Test that guarded calls panic while paused, that admin_withdraw and
   unpause still work, and that unpausing restores normal operation

Acceptance Criteria

• Admin can pause and unpause the contract; non-admins cannot
• Value-moving entrypoints panic with a clear error while paused
• admin_withdraw, unpause, and read-only calls still work while paused
• Pause state survives across calls and emits events on each transition

Submission Guidelines

• Branch: feat/contract-emergency-pause
• Depends on: None
• PR: feat(admin): add emergency pause circuit breaker

---

Gap verified against origin/main at 87de441 on 2026-08-27; line references above are from that commit.

[Devadakene]

I am experienced enough to implement this issue having worked on similar issues in the past. Please assign

[JuliobaCR]

Hi @3m1n3nc3 👋 I'd like to work on this issue.

Problem

geev-core has no circuit breaker. AdminContract::admin_withdraw can rescue funds after an incident, but nothing stops new value from entering or moving while that incident is being handled — create_giveaway, create_giveaway_with_selection, enter_giveaway, donate, claim_prize, and claim_help_request_funds all stay callable. The only incident-response tool today is draining the entire contract, which disrupts every unaffected giveaway and help request.

Proposed Solution

• Add a DataKey::Paused flag in instance storage, defaulting to false, and a new Error::ContractPaused variant.
• Add admin-gated pause(env) / unpause(env) to AdminContract, both behind the existing check_admin helper.
• Add a require_not_paused(&env) guard in access.rs and apply it to the six value-moving entrypoints: create_giveaway, create_giveaway_with_selection, enter_giveaway, donate, claim_prize, claim_help_request_funds.
• Keep escape hatches callable while paused: admin_withdraw, unpause, and all read-only getters.
• Emit ContractPaused / ContractUnpaused events matching the existing #[contractevent] style.
• Tests: guarded calls panic while paused; admin_withdraw and unpause still work while paused; unpausing restores normal operation; non-admins cannot pause/unpause.

I'll work off feat/contract-emergency-pause as suggested.

Estimated time: 1 day, given the scope is tightly specified.

Happy to coordinate here if useful, let me know if I should proceed.

[OWK50GA]

Hey, maintainer
I would like to fix this issue. Do assign

[grantfox-oss]

🦊 GrantFox — @OWK50GA has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

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

Good luck! Track your progress on GrantFox.