Security audit of `stealth-sender` Soroban contract

[truthixify]

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

Context

contracts/stellar/stealth-sender/ performs the atomic "transfer asset + emit announcement" operation. It is the contract that handles user funds in flight during a stealth payment, and it interoperates with arbitrary Stellar Asset Contracts (SAC). The blast radius of an issue here is direct loss of funds.

Scope

Independent security review with the standard severity matrix. Specific concerns:

• Token contract trust — send() calls token::Client::new(env, &token).transfer(...). Confirm we cannot be re-entered by a malicious SAC during the call, and that we never accept a token contract address that hasn't been validated by the caller.
• Native asset vs. issued asset divergence — verify XLM and arbitrary issued assets behave identically across success and failure paths.
• Batch send atomicity — batch_send() should be all-or-nothing. Verify by injecting a failing transfer mid-batch.
• Announcer call coupling — the sender invokes the announcer atomically. What happens if the announcer panics? Funds should not be moved without an announcement.
• Fee/refund flows — Soroban allows partial-failure semantics in some paths. Confirm there's no asymmetry where the caller pays fees but funds don't reach the stealth address.
• Auth caching / require_auth_for_args — verify that auth contexts cover both the source account and the asset's spender contract correctly.
• Reentrancy via CPI / nested contract calls — stealth-sender calls into the announcer; the announcer could in turn call back via a malicious extension. Confirm reentrancy is impossible or guarded.
• Init / upgrade story — review init() for one-shot semantics. Can it be re-initialized?

Acceptance criteria

• Audit report at contracts/stellar/stealth-sender/audits/2026-XX-author.md.
• Adversarial test suite at tests/audit.rs including:
  • A malicious-token mock that attempts reentry into send().
  • A failing-transfer middle-of-batch test for batch_send.
  • An announcer-panic test verifying funds are not lost.
• Findings disclosed privately for anything Critical/High.

Suggested approach

Build a small mock-token Soroban contract under tests/mocks/ that mimics SAC behavior but also implements re-entrancy callbacks. Use it as the harness for all adversarial cases.

Files to start with

• contracts/stellar/stealth-sender/src/lib.rs
• contracts/stellar/stealth-announcer/src/lib.rs (called atomically)
• EVM reference: contracts/evm/contracts/WraithSender.sol

[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.

[Olowodarey]

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

Hello, I’m Darey Olowo, a frontend and smart contract developer with experience building and shipping reliable features. I’d like to take on this issue and deliver a solid solution within 24 hours.

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

[drips-wave]

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

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