Add admin-rotation expiry test asserting accept_admin_rotation rejects past a documented staleness window

[thlpkee20-wq]

Description

propose_admin_rotation and accept_admin_rotation form a two-step flow but no expiry analogous to ISSUER_TRANSFER_EXPIRY_SECS constrains how long a pending admin rotation can sit. A long-pending rotation is a latent compromise risk. Add a configurable expiry and a test asserting acceptance past the window returns a typed error.

Requirements and context

• Must be secure, tested, and documented
• Should be efficient and easy to review
• Relevant code: src/lib.rs (propose_admin_rotation, accept_admin_rotation, cancel_admin_rotation, NoAdminRotationPending)
• Reuse the per-offering-expiry pattern with an ADMIN_ROTATION_EXPIRY_SECS default

Suggested execution

• Fork the repo and create a branch
• git checkout -b feat/admin-rotation-expiry
• Implement changes
  • Store proposal timestamp alongside the pending admin
  • Reject accept_admin_rotation past expiry
  • Add boundary test at exact expiry and one-past
• Validate security and correctness assumptions

Test and commit

• Run tests
  • cargo test --all
• Cover edge cases
  • Cancel before expiry, accept at expiry, accept one-past expiry, re-propose after expiry
• Include test output and security notes

Example commit message

feat: enforce admin-rotation expiry window

Guidelines

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

[divysam]

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

I would like to work on this issue please

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

[mofejo1]

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

Hello, I would like to apply for issue #423 (Add admin-rotation expiry test asserting accept_admin_rotation rejects past a documented staleness window).

Here is my plan:

• Add ADMIN_ROTATION_EXPIRY_SECS as a configurable constant reusing the per-offering-expiry pattern
• Store a proposal timestamp alongside the pending admin in propose_admin_rotation
• Update accept_admin_rotation to reject calls past the expiry window with a typed error
• Write tests covering: accept at exact expiry passes, accept one-past expiry returns the typed error, cancel before expiry succeeds, and re-propose after expiry works correctly
• Run cargo test --all and confirm coverage meets the 95% threshold
• Document the expiry constant and behavior in code comments

No one has applied yet and I can start immediately within the 96-hour window. Can I get this assigned?

Thanks

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

[drips-wave]

Congratulations, @divysam! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 2, 2026.

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