Security audit of `stealth-registry` Soroban contract

[truthixify]

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

Context

contracts/stellar/stealth-registry/ stores the (registrant, scheme_id) → 64-byte meta-address mapping. It is Wraith's analogue to ERC-6538 on EVM. Unlike the announcer, it has persistent storage and arbitrary user input flowing into DataKey::MetaAddress, so the attack surface is substantially larger.

We need an independent security review.

Scope

Same severity framework and report format as the announcer audit. Focus areas specific to the registry:

• Storage key collisions — can two distinct registrants produce the same DataKey? Inspect the Symbol / Address / u32 packing.
• Meta-address length validation — the 64-byte constraint is checked in register_keys(); verify there's no path that bypasses it (overloads, raw set() calls).
• Authorization — Soroban's require_auth() must cover both first-time and replacement writes. Confirm an attacker can't squat a victim's registry slot before the victim registers.
• Scheme ID forward compatibility — what happens if a client passes an unknown scheme_id? Document the intended behavior; flag if the contract silently writes garbage.
• State exposure — does stealth_meta_address_of return data for unauthorized callers? (It should — registry is public — but confirm there's no privileged-only side channel.)
• Storage rent / TTL — Soroban entries have TTL; verify extend_ttl semantics align with "permanent registration" UX expectations. A user shouldn't lose their registry entry to expiry.
• Replacement & nonce semantics — if the contract allows overwriting an existing registration, is there replay-protection across the write boundary?

Acceptance criteria

• Audit report at contracts/stellar/stealth-registry/audits/2026-XX-author.md.
• Repro tests in tests/audit.rs.
• Special section "Storage rent strategy" with concrete recommendations for the protocol team (we will turn this into a follow-up issue).
• Findings shared privately with security@usewraith.xyz for any Critical/High before publication.

Files to start with

• contracts/stellar/stealth-registry/src/lib.rs
• Companion EVM contract: contracts/evm/contracts/ERC6538Registry.sol (for behavioral parity check)
• ERC-6538 spec: https://eips.ethereum.org/EIPS/eip-6538

[thebabalola]

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

Hello! I'm a smart contract auditor with extensive experience reviewing Soroban Rust contracts. I understand that stealth-registry handles crucial persistent storage mapping for registrant addresses and accepts arbitrary inputs flowing into DataKey::MetaAddress. I've audited multiple Stellar DeFi and privacy contracts, checking for potential storage bloat, flash-loan vulnerabilities, and access control bypasses. I will perform a rigorous analysis of state serialization, boundary conditions, and resource usage. Ready to audit!

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

[Lynndabel]

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

Hello maintainer, I have reviewed the task description and will like to work on this please. ETA: 6hours

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

[drips-wave]

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

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

[truthixify]

Resolved by #35 (merged into develop).