#037: Smart Contract Upgrade Rollback Guard & Timelock Enforcement

[bakarezainab]

#37: Smart Contract Upgrade Rollback Guard & Timelock Enforcement

Overview

Enforce mandatory timelock delay before executing contract WASM upgrades to allow user inspection.

Objectives

• Require proposed contract upgrades to sit in a pending state for a configurable timelock period e.g. 48 hours.
• Allow emergency guardians to veto malicious or buggy upgrades during the timelock window.
• Store historical WASM hashes to support emergency rollback if needed.

Acceptance Criteria

• Upgrade proposal state machine with timelock delay check.
• veto_upgrade method for emergency guardian key.
• Unit tests for premature upgrade rejection and successful timelock execution.

[Glam26]

Hi! I'd like to work on this.

My approach will be to first understand the existing implementation and how it fits into the surrounding codebase. Then I'll implement the requested changes, add or update tests where appropriate, and verify everything by running the project's linting, test suite, and build before opening a PR.

I'll keep the scope focused on the issue and document any important implementation decisions in the PR. Looking forward to contributing!

[Phantomcall]

I'd like to take this on.

I have experience developing Rust/Soroban smart contracts with a focus on governance, upgrade safety, and secure state-machine design. This feature strengthens upgrade security while preserving a clear and auditable governance flow.

My implementation plan is to:

• Design and implement an upgrade proposal state machine that places every contract upgrade into a pending state before execution.

• Enforce a configurable timelock (e.g. 48 hours by default or as defined by protocol configuration) before any proposed WASM upgrade can be executed.

• Add a veto_upgrade entrypoint that allows the designated emergency guardian to cancel a pending upgrade during the timelock window.

• Store historical WASM hashes to provide an auditable upgrade history and enable controlled emergency rollback support where applicable.

• Ensure upgrade execution validates both the proposal state and timelock expiration before allowing any state transition.

• Emit appropriate contract events for proposal creation, veto, execution, and rollback-related actions to support indexing and governance monitoring.

• Write comprehensive unit tests covering:

  • Premature upgrade execution rejection.
  • Successful execution after the timelock expires.
  • Emergency guardian veto behavior.
  • Upgrade state transitions.
  • Historical WASM hash persistence.

• Run cargo fmt, cargo clippy, and the complete test suite before submitting the PR.

I'll keep the implementation focused on secure upgrade governance, minimizing changes outside the upgrade workflow while maintaining clear documentation and test coverage.

GitHub: @PHANTOM_CALL

[davidmaronio]

I'd like to take this one. I build Soroban contracts in Rust including governance and admin-gated flows, so an upgrade timelock with veto and rollback support is squarely in my lane. The shape I'd implement: a propose_upgrade entrypoint that stores the new WASM hash with execute_after = current ledger time plus the configurable timelock, an execute_upgrade that reverts with a typed error if called before execute_after and otherwise applies update_current_contract_wasm, and veto_upgrade gated to the guardian key that cancels the pending proposal and emits a veto event. Two details I'd be careful with: the state machine should only allow one pending proposal at a time (or key proposals explicitly), since a second proposal silently replacing the first is how a malicious upgrade slips past a 48-hour watch, and before executing, the current WASM hash gets appended to a stored history so an emergency rollback is just proposing a known-good prior hash through the same timelocked path rather than a separate backdoor that bypasses the guard. Events on propose, execute, veto and rollback so indexers and users can actually watch the window, and the timelock duration itself admin-configurable with a validated floor so it can't be set to zero. Tests would cover premature execution rejected, execution after the window succeeds, guardian veto cancels, a non-guardian veto attempt fails, and the rollback path restores a prior hash. Please assign it to me and I'll get started.

[grantfox-oss]

🦊 GrantFox — @davidmaronio 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 #37)
2. Your PR will be reviewed by the LatterFixxx maintainers

Good luck! Track your progress on GrantFox.