Recipient Payout Ordering Guarantee

[Kingsman-99]

Description

The release_funds() loop currently iterates recipients in the order returned by soroban_sdk::Map, which is key-hash ordered and opaque to callers, making event logs non-deterministic and complicating any future partial-failure rollback logic. A canonical, reproducible payout ordering — sorted by recipient Address byte representation — must be enforced and reflected in event emissions.

Technical Context

contracts/split/src/lib.rs — release_funds() loop body that calls token::Client::transfer() per recipient; contracts/split/src/storage.rs — load_recipients() returns Vec<RecipientShare> iterated from a soroban_sdk::Map; add sort_recipients(recipients: &mut Vec<RecipientShare>) in contracts/split/src/math.rs using sort_by on the Address byte slice via recipient.to_string().as_bytes(); contracts/split/src/events.rs — payout_initiated(invoice_id, index, recipient, amount) event should include the 0-based position index.

Acceptance Criteria

• load_recipients() returns a Vec<RecipientShare> sorted by Address byte representation in ascending lexicographic order before the payout loop begins
• Each payout_initiated event includes the recipient's 0-based position index in the sorted order
• Sorting is applied in memory after the initial Map read and introduces no additional storage reads
• A test in contracts/split/src/tests/ordering_tests.rs inserts 5 recipients in reverse-alphabetical order and asserts that events are emitted in alphabetical order
• A property-based or exhaustive test confirms sort stability across at least 10 distinct random orderings of a 4-recipient list
• All CI checks (cargo build --target wasm32-unknown-unknown, cargo test, cargo clippy) pass and the branch has no merge conflicts

---

[khanavi272-spec]

@khanavi272-spec has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

I would like to work on this issue

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

[Anadudev]

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

Hello maintainer, I'd love to work on this issue!

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

[adeniran19-maker]

@adeniran19-maker has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

I'm a full-stack developer and I'd like to take this issue.
I understand the requirements and will follow the existing project structure, keep the implementation clean, and include proper tests where applicable.

ETA: 1–3 days (depending on scope)

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

[attyolu]

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

Hello maintainer. I can resolve this issue quickly. Please assign to me. Thank you

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

[drips-wave]

Congratulations, @adeniran19-maker! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on July 30, 2026.

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