Skip to content

Comprehensive security audit of wraith-names Soroban contract #4

@truthixify

Description

@truthixify

Labels: Stellar Wave, stellar, audit, security, drips, help-wanted
Tier: XL (2+ weeks)
Type: audit

Context

contracts/stellar/wraith-names/ is the largest and most logic-heavy Stellar contract in Wraith (~363 LOC). It is the on-chain registry that maps human-readable .wraith names to stealth meta-addresses, and it implements registration, update, release, resolve, and reverse-lookup. It is also where most of Wraith's user-facing identity model lives, which makes name-squatting, theft, and griefing first-order risks.

This issue is the most critical Stellar audit in this batch. We strongly recommend tackling it as a team or after warm-up via the announcer/registry/sender audits.

Scope

Standard severity matrix and report format. The audit must cover both safety (does the contract preserve user invariants?) and correctness (does it behave per spec?).

Safety concerns

  • Name squatting — can an attacker register a victim's intended name in a front-run window? Discuss block ordering, mempool visibility on Soroban (or lack thereof), and any commit-reveal possibilities.
  • Ownership transfer — does update() correctly verify the existing owner before overwriting? Is the transition atomic across name → meta_address and meta_address → name reverse maps?
  • Release flow — once released, can a third party immediately re-register the freed name? Document whether there's a cooldown and whether one is needed.
  • Reverse-lookup poisoning — if Alice registers alice then transfers her stealth meta-address to Bob's keys, what does name_of(bob_address) return? Are reverse-lookups properly garbage-collected?
  • Hash collisions — names are SHA-256 hashed before storage. Probability is negligible by design, but verify there's no implementation bug (e.g., truncation) that increases collision risk.

Correctness concerns

  • Name validation — 3–32 characters, lowercase alphanumeric. Verify the regex/match logic against the spec exhaustively (Unicode lookalikes, length edge cases, ASCII control bytes, etc.).
  • 66-byte meta-address validation — must be exactly spending_pubkey(33) || viewing_pubkey(33). Confirm length is enforced everywhere.
  • Authorization — every state-mutating function should require auth from the current owner only, not the original registrant. Verify update/release paths.

Cross-chain consistency

wraith-names exists on EVM, Stellar, Solana, and CKB. Names are scoped per chain (no global namespace). Audit should flag any semantic divergence between Stellar's implementation and the EVM reference (contracts/evm/contracts/WraithNames.sol).

Acceptance criteria

  • Audit report at contracts/stellar/wraith-names/audits/2026-XX-author.md.
  • Adversarial test suite at tests/audit.rs with at least 20 tests covering ownership, validation, release-then-reregister flows, and reverse-lookup integrity.
  • Documented divergence table comparing Stellar wraith-names behavior to EVM WraithNames for each public function.
  • Section on "Mainnet readiness" with go/no-go recommendation and any required fixes.

Files to start with

  • contracts/stellar/wraith-names/src/lib.rs
  • contracts/evm/contracts/WraithNames.sol (reference behavior)
  • Test fixtures already in contracts/stellar/wraith-names/src/test.rs (extend, don't replace)

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programauditProduces a written report as primary deliverabledripsFunded via Drips Networkhelp wantedExtra attention is neededsecuritySecurity-sensitive workstellarTouches Stellar / Soroban code

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions