audit: SAC compatibility audit for stealth-sender

[Faromzy]

audit: SAC compatibility audit for Stellar stealth-sender

Closes the unaudited security gap identified in the issue: stealth-sender calls
token::Client::transfer() with no checks on asset type or issuer flags.

What's in this PR

• stellar/audits/2026-06-sac-compatibility.md — full audit report with 6
  findings and the asset compatibility matrix
• stellar/stealth-sender/tests/mocks/ — adversarial mock SACs for 7 asset
  variants (standard, auth-required, auth-revocable, clawback-enabled,
  immutable-safe, immutable+auth-required, custom fee token)
• stellar/stealth-sender/tests/sac_compat.rs — 9 tests covering every
  combination
• stellar/stealth-sender/Cargo.toml — adds rlib crate-type for integration test
  imports

Key findings

┌──────────┬─────────┐
│ Severity │ Finding │
├──────────┼────────────────────────────────────────────────────────────────┤
│ Critical │ AUTH_CLAWBACK_ENABLED — issuer can reverse a stealth payment │
│ │ post-receipt, breaking unlinkability │
├──────────┼────────────────────────────────────────────────────────────────┤
│ High │ AUTH_REVOCABLE — issuer can freeze the stealth address balance │
│ │ after receipt │
├──────────┼────────────────────────────────────────────────────────────────┤
│ Medium │ AUTH_REQUIRED — stealth address must be pre-authorized by │
│ │ issuer; incompatible with stealth flows │
├──────────┼────────────────────────────────────────────────────────────────┤
│ Medium │ AUTH_IMMUTABLE + AUTH_REQUIRED — permanently broken, no │
│ │ remediation path │
├──────────┼────────────────────────────────────────────────────────────────┤
│ Low │ Custom fee tokens — announced amount ≠ received amount │
├──────────┼────────────────────────────────────────────────────────────────┤
│ Low │ No atomic rollback if announcer fails after transfer completes │
└──────────┴────────────────────────────────────────────────────────────────┘

Supported assets: native XLM, standard issued (no flags), AUTH_IMMUTABLE with
no clawback/auth-required.

Recommended follow-up (not in this PR): implement an asset allowlist in
stealth-sender with a TokenNotAllowed error — the only approach that covers
clawback, which has no pre-flight query in the SAC interface.

Testing

cd stellar && cargo test --package stealth-sender
closes #16

[drips-wave]

@Faromzy Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[truthixify]

This is the rigor I want for SAC compatibility. Seven mock token variants is exhaustive coverage of the realistic Stellar issuance flag combinations, and the verdict matrix gives us a clean go/no-go per asset type.

The Clawback finding is the most important here. AUTH_CLAWBACK_ENABLED specifically defeats unlinkability because the issuer correlates announcement timing with the clawback target. That has to be on the "refuse at send time" list before mainnet.

Next concrete step on the contract side is the allowlist enforcement in stealth-sender::send and batch_send. Could you open a follow-up issue with Stellar Wave label for that work? Reference this PR and tag the verdict matrix.

Also, please open the docs follow-up issue to surface this matrix in docs/contracts/stellar.mdx so integrators see it before they pick an asset.

Thanks @Faromzy, real audit quality.