initialize accepts admin == operator with no validation or warning: the two-party consent at deployment can be a single address

[usmanimamu17-create]

Problem

initialize (src/lib.rs) requires both addresses to authorize but never requires them to be distinct:

pub fn initialize(env: Env, admin: Address, operator: Address) -> Result<(), SLAError> {
    ...
    admin.require_auth();
    operator.require_auth();   // two signatures required...
    env.storage().instance().set(&ADMIN_KEY, &admin);
    env.storage().instance().set(&OPERATOR_KEY, &operator);   // ...but they may be the same address
    ...
}

The two-party requirement is real (both must sign), yet the same address can fill both roles — one signature satisfies require_auth twice.

Consequences:

• The separation-of-duties the design implies is optional at deployment: the role model (fix: cross_contract_safety hardcodes error symbol and drops context #28) exists so config/roles (admin) and calculations (operator) are distinct; initialize lets a single address hold both, and the runtime setters can recreate that state (companion issue), so the invariant is never established.
• The two-party consent is illusory in the single-address case: require_auth() on the same address twice is one signature; a deployer reading the code as "two parties must agree" is misled.
• No signal marks the merged deployment: get_full_audit_state returns admin == operator with no flag, so downstream tooling cannot distinguish "deliberate single-key deployment" from "misconfiguration".

Root cause

initialize was written to require auth from both arguments without considering that the arguments may be equal; no role-distinctness invariant was defined (the setters companion issue shows the same gap).

Why this is architecturally hard

1. Enforcing distinct roles at initialize is a behavior change for any existing deployment that merged them; the error choice (reuse InvalidInput vs. new variant) is an ABI decision (companion error-catalog issue).
2. The policy question — must admin and operator always differ? — affects set_operator/propose_operator (companion issue) and the renounce flow; the invariant should be defined once and enforced at every mutation point.
3. The two-party semantics (both must authorize) and the distinctness rule are separate contracts; the docs should state both, and tests should cover the single-address case.

Acceptance criteria

• initialize with admin == operator is either rejected or explicitly documented as a supported mode.
• The role-distinctness invariant is documented and enforced consistently across initialize and the role setters.
• Tests cover the equal-address deployment case.

Out of scope

The role-setter equal-role gap (companion issue in batch 08) and the two-party initialize descriptor mislabel (companion issue in batch 03).

Getting started

just test

Good first files to read: apexchainx_calculator/src/lib.rs (initialize, require_admin, require_operator).

[Noubata]

I can submit a PR within an hour

[DrSa7ag3]

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

Hello, I’ve read through the issue description and understand the expected outcome. I’d be glad to work on it.

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

[Fatimasanusi]

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

Hello, I’ve read through the issue description and understand the expected outcome. I’d be glad to work on it.

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

[drips-wave]

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

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