`stealth-batch-sender` Soroban contract

[truthixify]

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

Context

The EVM WraithSender already supports batchSendETH and batchSendERC20. Stellar's stealth-sender only handles single transfers. For high-volume scenarios (payroll, recurring drops, Spectre's scheduled-payment executor) we want a Stellar contract that sends to many stealth addresses in one transaction, with one fee envelope.

Scope

Implement a new crate contracts/stellar/stealth-batch-sender/ that:

1. Exposes batch_send(from: Address, transfers: Vec<Transfer>, token: Address) where Transfer { recipient_meta: BytesN<64>, amount: i128, metadata: Bytes }.
2. For each entry:
   • Generates a stealth address using the recipient's meta-address (this happens off-chain; the contract receives the already-derived stealth address and ephemeral pub key in metadata or as part of Transfer).
   • Transfers amount of token from from to the stealth address.
   • Invokes the announcer with (scheme_id, stealth_address, ephemeral_pub_key, metadata).
3. Is all-or-nothing: any failure inside the loop must revert the whole batch.
4. Limits batch size (suggestion: 25 — but justify the choice based on Soroban resource budgets).
5. Charges nothing beyond Soroban's native resource pricing.

Design considerations to address in the PR description

• Should the batch sender accept both XLM and SAC tokens with the same entrypoint, or have separate batch_send_xlm / batch_send_token?
• How does the gas-fee envelope compare to N individual stealth-sender::send calls? Include a benchmark.
• Is this a new contract or a new function on the existing sender? (We lean toward new contract so existing audits don't need re-doing; argue either way in the PR.)

Acceptance criteria

• New crate with full unit tests.
• Property-based test verifying atomicity (any failure → no transfers, no announcements).
• Resource-budget comparison vs. N individual sends in the PR description.
• Deploy script support added (see #07).
• SDK follow-up issue filed describing the consumer-side wiring needed.

Why this matters

The current Stellar Spectre connector scheduled-payment executor sends one tx per recipient. Batching is the difference between "Wraith does payroll" and "Wraith can theoretically do payroll."

Files to start with

• contracts/stellar/stealth-sender/src/lib.rs (existing single-send reference)
• contracts/evm/contracts/WraithSender.sol (batchSendETH reference)

[Hallab7]

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

I would like to work on this issue

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

[clintjeff2]

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

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

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

[Zeemnew]

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

Hi maintainer, I'd love to take care of this task because I have handled similar issues like this before, I can build the new stealth-batch-sender crate for Soroban, implementing the batch_send entrypoint with the all-or-nothing atomic loop for transfers. I'll make sure it properly processes the transfers, invokes the announcer, handles the resource-budget limits, and addresses the design considerations regarding XLM/SAC entrypoints and gas comparisons in the PR description. I will also add full unit and property-based tests. Ready deliver at the shortest time possible.

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

[drips-wave]

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

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