`PendingAdmin`'s `accept_admin` — confirm there's no timeout on a pending admin-transfer proposal (an old, forgotten proposal could be accepted years later by a now-compromised or reassigned address)

[Christopherdominic]

The two-step admin transfer (propose+accept_admin, referenced by DataKey::PendingAdmin) is a good pattern for avoiding typo-lockout, but it's worth confirming whether a pending proposal ever expires. If an admin proposes a transfer to some address, that transfer is never accepted (the intended recipient never gets around to it, or circumstances change and the transfer is no longer wanted, but nobody explicitly cancels it — is there even a cancel_admin_transfer entrypoint?), and years later the original proposing admin's own key becomes compromised or the address it was meant for changes hands/gets compromised in the interim, an attacker who gains control of that stale pending-admin address could call accept_admin and take over the contract at a time completely disconnected from when the transfer was actually intended.

Task: Confirm whether a pending admin proposal has any expiry, and whether a cancel_admin_transfer-style entrypoint exists for the current admin to explicitly retract a proposal they no longer want pending. If neither exists, add both — this is the same class of "unbounded-lifetime pending state" risk the upgrade timelock and payout-address-change delay both explicitly account for elsewhere in this same contract, so admin transfer shouldn't be the one exception.

[Hollujay]

Kindly assign the issues to me, I will surely get them done @Christopherdominic

[k-deejah]

I’d like to work on this security issue because stale administrative state can create a significant long-term takeover risk, especially when a pending privileged action has no expiration or cancellation mechanism.

I have experience working with Rust and Soroban smart contracts, including reviewing contract logic, access-control flows, and security-sensitive state transitions. I’ll trace the PendingAdmin lifecycle and accept_admin implementation to confirm whether proposals currently expire and whether the current admin has a way to explicitly revoke a pending transfer.

If neither safeguard exists, I’ll implement an appropriate expiry mechanism and a cancel_admin_transfer entrypoint, ensuring authorization, storage cleanup, and edge cases are properly handled. I’ll also add focused tests covering normal transfers, expired proposals, cancellation, unauthorized acceptance/cancellation, and attempts to accept stale proposals.

The goal is to prevent an old administrative proposal from remaining actionable indefinitely while preserving the intended two-step admin-transfer flow.

[grantfox-oss]

🦊 GrantFox — @k-deejah has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #413)
2. Your PR will be reviewed by the Bonizozo maintainers

Good luck! Track your progress on GrantFox.