The BaseSAP preprint asks how stealth addresses can be supported through reusable application-layer infrastructure on programmable blockchains. It describes a modular protocol and a dual-key secp256k1 prototype, with test-network deployments, cost analysis and discussion of denial-of-service and privacy threats. View tags help recipients filter announcements before performing more expensive checks.

The arXiv version reports a prototype, not evidence that every production wallet implements the same design. Read its security discussion beside its performance measurements. Faster scanning is useful, but it does not imply hidden transaction amounts, hidden senders or protection against all external observations. The paper's modularity also means that changing the cryptographic scheme creates a new set of assumptions to inspect rather than automatically inheriting the prototype's analysis.

ERC-5564 standardizes generation and discovery around stealth addresses. A recipient publishes a stealth meta-address containing public key material. The sender uses an ephemeral key and the recipient's information to derive a payment address. An announcement contains information that lets the recipient recognize the payment and derive the corresponding spending key. The initial scheme uses separate viewing and spending concepts, allowing those responsibilities to be distinguished.

The ordinary payment remains visible at its generated address. The protection concerns linking that address to the recipient's published identity through the protocol alone. Consequently, reading the announcement interface is as important as reading the key derivation. Consider what a scanning service learns if it receives viewing material, and what information the sender already knows. These are different observers with different capabilities.

Suppose a fictional employer pays an employee at a fresh derived address each month. This can reduce the obvious public connection between the employee's published receiving identity and each new payment. It does not hide the employer's sending account or automatically disguise a distinctive salary amount. The employer still knows whom it paid. A later public transfer from the fresh address into the employee's familiar wallet can create a new connection.

Now give the employee a token without any native asset for transaction fees. How will the first outgoing transaction be funded? If a familiar public wallet sends the fee money, it may expose the link the receiving design tried to conceal. Treat fee funding, scanning, recovery and later spending as parts of the system. The example is an analysis exercise, not a procedure that guarantees anonymity.

ERC-6538 specifies a registry for stealth meta-addresses. This addresses a practical discovery problem: senders need an authenticated way to find the recipient's current public receiving information. The standard includes registration paths and signature-based authorization. It does not remove the need to verify the chain, registry and identity mapping used by a particular application.

A complete review should test rotation and restoration conceptually. If receiving information changes, can the wallet still discover older payments? Which historical keys and announcements must be retained? Can an attacker replace a displayed meta-address before a sender derives the destination? Distinguish a legitimate registry update from a compromised website presenting a different identity. Stealth addressing protects a particular relationship in the payment graph; it remains dependent on authentic discovery and sound handling of the keys that control received funds.