Cairo 1.x storage schema change and unresolved rollback safety

Direct Answer

No. Rolling back a contract to a previous class hash after a storage schema change does not revert the persistent storage map. Sierra's safety guarantees are per-transaction (gas bounds, array bounds, panic-free execution, type-safe memory access) and do not extend to cross-transaction storage schema compatibility. There is no automatic migration, versioning, or rollback mechanism in the Cairo 1.x / StarkNet storage model.

Why Rollback Corrupts State

Cairo 1.x contract storage is a flat key-value map felt252 → felt252. Each storage variable is assigned a deterministic slot derived from its name via Pedersen hash at compile time. The layout is fixed in the Sierra artifact (.sierra.json storage section). When you deploy a new class hash with a different layout (added, removed, or reordered variables), the slot assignments change. A subsequent replace_class or proxy upgrade to the old class hash swaps the executable bytecode but leaves every raw slot value untouched. The old layout will then interpret those slots as different variables, producing silent corruption.

What Sierra Assertions Actually Cover

• Gas consumption bounds per transaction
• Array bounds and memory safety within a single VM run
• Panic-free execution (no unexpected panic opcodes)
• Type-safe memory access for the current transaction's stack/heap

Sierra emits no schema version, layout hash, or migration metadata. The starknet::storage_access syscall reads/writes raw slots; the compiler inserts no layout guards.

Intended On-Chain Upgrade Pattern

1. Append-only additions — add new variables at the end of the #[storage] struct; never reorder or remove used variables.
2. Proxy upgrade — use an OpenZeppelin StarkNet proxy (or equivalent) that preserves the storage address. Reserve proxy metadata slots (implementation address, admin) in the base layout via a dedicated StoragePointer or fixed slots.
3. Breaking changes require explicit migration — write a one-time migration transaction that reads old slots and writes new slots, then upgrade. There is no automatic rollback.

Verification Steps for Your Case

1. Compile both old and new versions with scarb build and compare the storage section in each .sierra.json. Every variable present in the old layout must have an identical slot hash in the new layout.
2. Write a Starknet Foundry test: deploy old implementation via proxy → write known values to each variable → upgrade to new implementation → read back via both new and old ABIs (using starknet::call_contract_syscall with the old class hash) to confirm interpretation matches.
3. On a local devnet (katana), execute replace_class to the old class hash after the layout change, then query raw slots via starknet_getStorageAt to observe that values persist unchanged.

One Missing Diagnostic Detail

Does your new layout only append variables after all existing ones, or does it reorder, remove, or insert variables before existing ones? If the latter, rollback is unsafe regardless of proxy usage and a migration transaction is mandatory.