Add Contract Upgrade Mechanism

[Just-Bamford]

��# Issue 19: Add Contract Upgrade Mechanism

Problem

Once deployed, contract can't be upgraded. Bug fixes require redeployment and data migration.

Solution

• Implement schedule_upgrade(new_contract_id) (admin only)
• Add approval period (e.g., 48 hours) before execution
• Store pending upgrades in contract state
• Enable future improvements without data loss

Implementation Tasks

• Implement schedule_upgrade() function
• Store pending upgrade with scheduled time
• Implement cancel_upgrade() function (admin only)
• Add time-lock verification logic
• Emit upgrade event with old/new contract IDs
• Unit tests: upgrades can be scheduled and canceled
• Unit tests: time-lock enforced

Note for Contributors

This is a critical governance feature for production safety. The upgrade mechanism must include a time-lock (e.g., 48 hours) to give users opportunity to verify the new contract before execution. Only admin can schedule upgrades and cancel pending upgrades. Store the pending upgrade with its scheduled execution time. Emit events when upgrades are scheduled, canceled, or executed. Use env.ledger().timestamp() for time checks. The time-lock prevents immediate upgrades from compromising user funds. Consider requiring multi-sig approval (Issue #22) for enhanced security. Note: This requires Soroban SDK support for contract state transitions; may need to coordinate with protocol layer. The current contract can't directly upgrade itself; this may require external orchestration.