Skip to content

[SC-49] Document and test the contract upgrade path #1213

Description

@yusuftomilola

Overview

There is no documented upgrade story for the workspace. Once contracts hold real asset registry data, changing a storage layout without a tested migration means data loss — and asset ownership records are precisely the data you cannot afford to lose.

Tasks

  • Document the upgrade model per contract: upgradeable via update_current_contract_wasm, or immutable-and-redeploy?
  • For upgradeable contracts, restrict the upgrade entrypoint to admin (ideally the two-step admin from [SC-48]) and emit an event.
  • Add a storage-version key and an idempotent migration function that runs once.
  • Test: deploy v1, write state, upgrade to v2, assert state survives and reads correctly under the new layout.
  • Write an upgrade runbook in contract documentation.

Acceptance Criteria

  • Every contract's upgrade posture is documented.
  • Upgrade entrypoints are admin-gated and emit events.
  • An upgrade test proves state is preserved across a version bump.

Dependencies

Builds on [SC-48].

Notes for Contributors

Requires Rust + Soroban. Workspace: contracts/ (soroban-sdk 22, members: assetsup, contrib, multisig-wallet, multisig_transfer, asset-maintenance). Run cargo test --all, cargo fmt --all -- --check, and cargo clippy --all-targets --all-features -- -D warnings before opening a PR — CI enforces all three. Comment below to be assigned.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions