Labels: Stellar Wave, stellar, audit, interop, drips, help-wanted
Tier: L (1–2 weeks)
Type: audit
Context
Stellar Asset Contracts are the bridge between Classic Stellar assets (XLM, USDC, issued tokens) and Soroban. They expose a Token interface, but not every asset behaves identically: native XLM has different reserve semantics from issued assets; auth-required assets reject transfers without authorization; clawback-enabled assets can be reversed; some custom SACs have non-standard fee logic.
stealth-sender calls token::Client::new(env, &token).transfer(...) and trusts the asset. If any of these quirks break our assumptions, we have an unaudited security gap.
Scope
Produce a compatibility audit documenting how each SAC variant interacts with Wraith's stealth flows:
- Asset matrix — test transfers via
stealth-sender against:
- Native XLM
- Standard issued asset (no flags)
- Auth-required asset (
AUTH_REQUIRED)
- Auth-revocable asset (
AUTH_REVOCABLE)
- Clawback-enabled asset (
AUTH_CLAWBACK_ENABLED)
- Immutable asset (
AUTH_IMMUTABLE)
- A custom Soroban-native token (non-SAC, implementing the Token interface directly)
- For each: document the behavior, failure mode, and whether the stealth flow remains correct.
- Identify any combination that:
- Causes funds to land at the stealth address but the announcement to fail (or vice versa)
- Allows the issuer to clawback funds after they reach a stealth address (this defeats unlinkability — argue what we recommend)
- Requires the stealth address to be pre-authorized by the issuer before it can receive (UX killer)
- Recommend: a documented list of "Wraith-supported" asset configurations, and explicit refusal behavior in
stealth-sender for incompatible asset types.
Test harness
Build adversarial mock SACs for each variant under contracts/stellar/stealth-sender/tests/mocks/. Each mock should mimic real Stellar SAC behavior for the specific flag combination.
Acceptance criteria
Why this matters
The first time someone tries to send a clawback-enabled token through Wraith and the issuer reverses it after the recipient withdraws, the unlinkability promise collapses on social media. We need to know the boundary conditions before users hit them.
Resources
Labels:
Stellar Wave,stellar,audit,interop,drips,help-wantedTier: L (1–2 weeks)
Type: audit
Context
Stellar Asset Contracts are the bridge between Classic Stellar assets (XLM, USDC, issued tokens) and Soroban. They expose a
Tokeninterface, but not every asset behaves identically: native XLM has different reserve semantics from issued assets; auth-required assets reject transfers without authorization; clawback-enabled assets can be reversed; some custom SACs have non-standard fee logic.stealth-sendercallstoken::Client::new(env, &token).transfer(...)and trusts the asset. If any of these quirks break our assumptions, we have an unaudited security gap.Scope
Produce a compatibility audit documenting how each SAC variant interacts with Wraith's stealth flows:
stealth-senderagainst:AUTH_REQUIRED)AUTH_REVOCABLE)AUTH_CLAWBACK_ENABLED)AUTH_IMMUTABLE)stealth-senderfor incompatible asset types.Test harness
Build adversarial mock SACs for each variant under
contracts/stellar/stealth-sender/tests/mocks/. Each mock should mimic real Stellar SAC behavior for the specific flag combination.Acceptance criteria
contracts/stellar/audits/2026-XX-sac-compatibility.md.stealth-sender/tests/sac_compat.rs.stealth-senderto reject incompatible assets safely.docs/contracts/stellar.mdx.Why this matters
The first time someone tries to send a clawback-enabled token through Wraith and the issuer reverses it after the recipient withdraws, the unlinkability promise collapses on social media. We need to know the boundary conditions before users hit them.
Resources