propose_admin allows proposing the current admin as the new admin: a self-proposal emits adm_prop and adm_acc with no state change, polluting the governance trail

[usmanimamu17-create]

Problem

propose_admin (src/governance.rs) performs no check that new_admin != caller (the current admin):

pub fn propose_admin(env: &Env, caller: &Address, new_admin: &Address) -> Result<(), SLAError> {
    ...
    env.storage().instance().set(&PENDING_ADMIN_KEY, new_admin);
    env.events().publish((EVENT_ADMIN_PROP, EVENT_VERSION, caller.clone()), (new_admin.clone(),));
    Ok(())
}

Proposing the current admin (or yourself) creates a pending slot equal to the current admin; the admin then calls accept_admin (passes the equality check against pending) and nothing changes — but two governance events were emitted for a no-op.

Consequences:

• The audit trail records phantom transitions: adm_prop + adm_acc for a role that never changed; a compliance review counting role changes over-counts.
• The two-step protocol is reducible to a no-op ceremony: an admin can "confirm" their own role via the full propose/accept flow, which is indistinguishable in events from a real handoff followed by a rename back.
• The pending slot becomes a trap: after a self-proposal, a later legitimate proposal silently overwrites it (companion issue), and any code reading get_pending_admin sees the admin themselves.

Root cause

The proposal path validates only that the caller is admin; it never validates that the proposal is a change.

Why this is architecturally hard

1. Rejecting self-proposals (a new InvalidInput-style error or reuse of an existing code) is a small guard, but it must be paired with the decision on whether accept_admin should also reject accepting when pending == current admin (defense in depth).
2. The same no-op possibility exists on the operator side (propose_operator with new_operator == current operator); the fix should cover both roles for consistency.
3. Error-code choice is an ABI decision (companion error-catalog issue); alternatively the guard can be a silent no-op, but then the events must not be emitted — which is also a behavior change.

Acceptance criteria

• Proposing the current role holder as their own successor is rejected (or performs no event-emitting state change).
• accept_admin/accept_operator cannot complete a no-op transition.
• Tests cover self-proposal for both roles.

Out of scope

The overwrite-supersession behavior (companion issue) and proposal expiry.

Getting started

just test

Good first files to read: apexchainx_calculator/src/governance.rs (propose_admin, accept_admin).

[SamixYasuke]

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

Hello Maintainer,

I can prevent no-op admin and operator transitions by rejecting self-proposals and adding defense-in-depth checks

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

[Abulbayty]

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

I’ve carefully reviewed the requirements and I’m confident in my ability to address this issue effectively and submit a quality PR within 24 hours.

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

[kimmoris12345]

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

Hello Maintainer, I can fix this issue.
Please assign me.

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

[ykargeee-bit]

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

Hi Maintainer,

I’m a full-stack developer, and I’d like to contribute to the task. I’ll implement it carefully and efficiently thoroughly understand requirements and edge cases
Communicate promptly about suggestions or improvements. And I will provide regular progress updates and address blockers
Align with project goals through feedback and clarification.

Thank you,

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

[drips-wave]

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

🧑‍💻 @ykargeee-bit: 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!

@ykargeee-bit's PR #542 was approved and merged by @usmanimamu17-create.

🏆 @ykargeee-bit: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,465 total points). Track your full progress on GrantFox.

👏 Great work, @ykargeee-bit! Keep contributing to ApexChainx.