Add upgrade-safe storage layout versioning with assert_storage_layout_compatible called at module entry

[Jagadeeshftw]

Summary

Add upgrade-safe storage layout versioning with assert_storage_layout_compatible called at module entry

Why this matters

DataKey and DataKey2 enums have grown across migrations without a top-level layout version stamp, and AlreadyAtTargetVersion/MigrationDowngradeNotAllowed are defined but never wired into a layout guard. Introduce a StorageLayoutVersion persistent key set during initialize, read on every state-changing entry, and rejected when the on-chain value is newer than the deployed binary expects.

Scope

Implement the requested behavior across src/lib.rs. The solution must preserve existing compatibility, authorization, and production safeguards.

Priority

High

Acceptance criteria

• The requested behavior is implemented across src/lib.rs with a clear, reviewable contract.
• Security, authorization, validation, and data-integrity requirements in the repository context are enforced and covered by tests.
• Failure, retry, timeout, concurrency, and boundary behavior is explicit and produces safe, diagnosable outcomes where applicable.
• Regression coverage includes empty, invalid, duplicate, and boundary inputs relevant to this flow.
• Existing API, storage, and deployment compatibility is preserved unless a migration is explicitly documented.

Validation

Include focused tests for:

• happy paths;
• invalid input and authorization boundaries;
• concurrency, retries, or failure recovery;
• backward compatibility;
• relevant integration or contract behavior.

The implementation must pass the repository’s existing build, lint, test, and formatting checks (use cargo test --all where applicable).

Non-goals

• Typo-only, formatting-only, or documentation-only changes.
• Unrelated refactors or dependency upgrades.
• Weakening security, authorization, CI, or production safeguards.
• Changing public behavior outside this issue’s scope.

Contributor application

Before implementation, comment with:

1. relevant experience;
2. a concise implementation approach;
3. expected files or modules affected;
4. an estimate for opening the first PR.

Wait for maintainer assignment before coding.

PR requirements

Use a feature branch and include Closes #.

The PR must:

• address every acceptance criterion;
• link each criterion to code and tests;
• explain security and failure-mode handling;
• include meaningful regression coverage;
• document compatibility or migration considerations;
• pass the repository checks.

Reward-readiness

This is a substantive quality issue. Merge status does not guarantee reward eligibility; final evaluation is determined separately.

Implementation context

Description

DataKey and DataKey2 enums have grown across migrations without a top-level layout version stamp, and AlreadyAtTargetVersion/MigrationDowngradeNotAllowed are defined but never wired into a layout guard. Introduce a StorageLayoutVersion persistent key set during initialize, read on every state-changing entry, and rejected when the on-chain value is newer than the deployed binary expects.

Requirements and context

• Must be secure, tested, and documented
• Should be efficient and easy to review
• Relevant code: src/lib.rs (DataKey, DataKey2, initialize, AlreadyAtTargetVersion, MigrationDowngradeNotAllowed)
• Layout version must be bumped in PRs that add or rename DataKey variants

Suggested execution

• Fork the repo and create a branch
• git checkout -b feat/storage-layout-versioning
• Implement changes
  • Add STORAGE_LAYOUT_VERSION: u32 constant and persistent key
  • Add assert_storage_layout_compatible called at top of state-changing methods
  • Emit layout_v on initialize and on migrations
• Validate security and correctness assumptions

Test and commit

• Run tests
  • cargo test --all
• Cover edge cases
  • Initialize at vN, downgrade attempt, upgrade through migration
• Include test output and security notes

Example commit message

feat: enforce storage layout version on entry to state-changing methods

Guidelines

• Minimum 95 percent test coverage
• Clear documentation
• Timeframe: 96 hours

[whitezaddy]

@whitezaddy has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I have experience and have reviewed the code; I can submit a PR within 2 days.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @whitezaddy to this issue.

[drips-wave]

Congratulations, @whitezaddy! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @whitezaddy: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@whitezaddy's PR #862 was approved and merged by @thlpkee20-wq.

🏆 @whitezaddy: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (707 total points). Track your full progress on GrantFox.

👏 Great work, @whitezaddy! Keep contributing to RevoraOrg.