Restore the upgrade timelock (H6) before the first funded mainnet campaign

[0xdevcollins]

UPGRADE_TIMELOCK_LEDGERS was set to 0 on both events and profile on 2026-08-18 (commit cd0054c) so the 1.7.0 rollout could iterate without a day's wait per attempt. This must be reversed before the first funded mainnet campaign.

Why it was safe to remove, and why that expires

Mainnet holds no escrow today — both events are Completed with remaining_escrow: 0 — so the control currently protects nothing. That stops being true the moment a campaign funds.

With no window, a compromised 2-of-3 admin can call propose_upgrade and apply_upgrade in a single sequence and swap the wasm outright. cancel_pending_upgrade never gets a chance to fire, which is the entire point of audited control H6 (closed 2026-06-04).

Scope

• contracts/events/src/admin.rs — UPGRADE_TIMELOCK_LEDGERS back to 17_280
• contracts/profile/src/admin.rs — same
• contracts/events/src/tests/admin.rs — apply_upgrade_is_immediate_while_the_timelock_is_zero back to asserting UpgradeTimelockNotElapsed
• contracts/profile/src/tests/admin.rs — same for the _profile mirror
• Local UPGRADE_TIMELOCK_LEDGERS consts in both test files back to 17_280

The #[cfg(feature = "testnet")] split was deliberately kept rather than collapsed, so each contract is a single-value edit. Both tests assert UPGRADE_TIMELOCK_LEDGERS == 0 with a "restore me" message, so flipping the constant fails them loudly rather than passing silently.

Trigger

Whichever comes first:

• the first mainnet campaign funds escrow
• the third-party audit starts — it will flag a removed H6 control as a finding

Tracked in BACKLOG.md under P1.

[coderabbitai]

🔗 Related PRs

#60 - Revise README and CI workflows for 1.1.0 deployment update [merged]
#81 - chore: strip explanatory comments from contract source [merged]
#90 - feat(events): pull-model prize claims for Single-release events [merged]
#99 - feat(events): stop enforcing the submission deadline on-chain [merged]
#102 - fix: gate sdk 27 storage compatibility [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[soma-enyi]

Soma-enyi
Hi team, I'd like to work on this issue. I'm a full-stack developer experienced in TypeScript, Rust, and smart contract development across EVM and Soroban/Stellar ecosystems. I've built and shipped production systems covering backend APIs, frontend interfaces (Next.js, React), CI/CD pipelines, and onchain protocols — so I'm comfortable working across whatever layer this issue touches. My approach I'll start by reproducing the issue locally and reading the surrounding code to understand context and constraints. I'll scope the fix tightly to avoid unnecessary churn, write or update tests to cover the change, and make sure linting, formatting, and existing CI checks all pass before opening a PR. If anything in the issue is ambiguous, I'll flag it early rather than guess. What you can expect A single clean PR with a clear description linking back to this issue. Minimal, well-tested changes that follow the project's existing conventions. Fast turnaround — I'm available to start immediately and responsive to review feedback. Happy to discuss the approach further if needed. Looking forward to contributing.

[Oluwaseyi89]

Hi @0xdevcollins I understand the urgency of restoring the 17,280-ledger upgrade timelock before mainnet funding, and I can immediately revert the constants, update the test assertions, and ensure the H6 control is properly reinstated across both contracts.