Add revocation index for multi-period attestation ranges keyed by merkle_root

[thlpkee20-wq]

Summary

Add revocation index for multi-period attestation ranges keyed by merkle_root

Why this matters

revoke_multi_period_attestation performs a full linear scan of every range to find the matching merkle_root. With many ranges per business this becomes O(n) on every revocation. A secondary index from merkle_root to range index would make revocation O(1) and prevent storage rewrites of unchanged ranges.

Scope

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

Priority

High

Acceptance criteria

• The requested behavior is implemented across contracts/attestation/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

revoke_multi_period_attestation performs a full linear scan of every range to find the matching merkle_root. With many ranges per business this becomes O(n) on every revocation. A secondary index from merkle_root to range index would make revocation O(1) and prevent storage rewrites of unchanged ranges.

Requirements and context

• Must be secure, tested, and documented
• Should be efficient and easy to review
• Relevant code: contracts/attestation/src/lib.rs (revoke_multi_period_attestation)
• Add a new storage variant MultiPeriodKey::RootIndex(business, root) containing the range position.

Suggested execution

• Fork the repo and create a branch
• git checkout -b feat/multi-period-revocation-index
• Implement changes
  • Populate the index on submit_multi_period_attestation.
  • Update revoke_multi_period_attestation to look up via the index and mutate a single range.
  • Add tests covering missing root, duplicate root (legacy data), and post-revocation lookups.
• Validate security and correctness assumptions

Test and commit

• Run tests
  • cargo test --all
• Cover edge cases
  • Revocation of the last, first, and middle ranges; re-revocation idempotency.
• Include test output and security notes

Example commit message

feat: add merkle_root index for multi-period revocation

Guidelines

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

[humblezdan]

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

hello would love to work on this issue please

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

[Vivianndev]

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

Hi, I'd love to work on this issue thanks

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

[drips-wave]

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

🧑‍💻 @Vivianndev: 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 🌊