1-to-N stealth payment splitter on Stellar

[truthixify]

Labels: Stellar Wave, stellar, feature, drips, help-wanted
Tier: L (1–2 weeks)
Type: feature

Context

stealth-batch-sender (issue #09) takes N pre-computed transfers and executes them. A different and complementary primitive is the splitter: one deposit, automatically divided into N stealth payouts according to a fixed schema (weights, fixed amounts, or both).

This is the building block for: revenue-share among contributors, tip distribution, royalty splits, and DAO payouts where the list of recipients is part of the public commitment but the individual stealth addresses must remain unlinkable to recipient identities.

Scope

Build contracts/stellar/stealth-splitter/:

1. create_split(beneficiaries: Vec<(meta_address, weight)>, asset, salt) -> SplitId:
   • Beneficiaries: at most 25 (justify based on resource budget — coordinate with #06).
   • Weights are arbitrary positive integers; payouts will be proportional.
   • The SplitId is the deterministic hash of (beneficiaries, asset, salt); it can be advertised publicly without revealing recipients (because meta-addresses are committed to but the stealth addresses generated from them aren't yet known).
2. fund_split(split_id, amount):
   • Sender deposits amount. The deposit is split immediately into stealth payouts to each beneficiary, with a generated ephemeral key per payout.
   • Each payout emits a standard announcement so beneficiaries scan normally.
   • Atomic: any failure rolls back all transfers and announcements.
3. get_split(split_id) -> SplitDetails:
   • Returns the public beneficiary list + total amount funded to date (no per-recipient stealth address data).

Design constraints

• The split definition must be immutable after creation (no add/remove beneficiaries) — argue in the PR.
• The contract must not retain any view of individual stealth addresses after a payout completes; it should be ephemeral pass-through.
• Rounding error from weights must go somewhere deterministic — propose "first beneficiary absorbs dust" with a documented rationale.

Acceptance criteria

• New crate with full unit, property, and adversarial tests.
• Atomicity test: middle-of-distribution failure rolls back all transfers.
• Resource-budget comparison vs. N separate stealth-sender calls.
• SDK follow-up issue filed for buildSplitDeposit builder.
• Demo follow-up: "Split a payment among N recipients" flow.

Why this matters

DAOs, contributor payouts, and revenue-share are the most-requested use cases for "private but auditable" payments. The split commits to who gets what publicly without ever revealing the resulting stealth addresses to anyone but the recipients.

[SHEROSE0]

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

I’m a software developer with 3 years of hands-on experience building scalable and maintainable applications. I can quickly understand the project requirements, implement efficient solutions, and deliver high-quality results within tight timelines. I’m confident in my ability to complete this task fast without compromising performance, code quality, or reliability.

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

[hashmart138-creator]

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

Hi team, I’d like to be assigned to this issue. I can implement the stealth-splitter contract within contracts/stellar/stealth-splitter/. I will ensure that the split definitions are fully immutable, map proportional weights securely while assigning rounding dust deterministically to the first beneficiary, and emit uniform announcement logs for recipient scanning. I will design the execution flow to operate as a pass-through layer that retains zero stealth-address state, provide full adversarial and middle-of-distribution atomicity test suites, and deliver a comprehensive resource-budget comparison analysis.

ETA: 3–4 hours

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

[drips-wave]

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

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