ZEROSHADEA privacy product earns trust by naming its own data. This is the complete list for the hosted ZeroShade API, followed by what each item can reveal.
Handle associations
When a handle is registered with a signature, the API keeps the handle and its owner. The server retains this handle-owner association. The handle lookup endpoint reveals only that a handle exists, not its owner. But a payer has to reach somewhere to send funds, so claiming a handle without signing in dispenses fresh public recipient addresses, and recipients and public link holders can obtain the destination data that applies to them.
One-time recipient addresses
The API can hand out recipient addresses meant to be used once, and it records usage so the same address is not handed out as fresh twice. The usage record tells the API, and anyone with API access, whether an address has been used.
Payment links
A payment link stores an amount, a destination, a status and a reference. These are the working parts of a request: what is asked, where it goes, whether it is still open and the label you attached. Do not put sensitive text in a reference.
Shared reports
When you share a signed report, the signed payload is stored so a recipient can open it from a link. Anyone who has the link can read the payload. The signature lets a reader check the report was not altered; it does not make the report secret.
Waitlist email hashes
The waitlist keeps a hash of the email, not the address itself. A hash is not anonymization. If someone already knows or can guess an address, they can hash it and compare. Treat the hash as personal data.
What is not here
Wallet private keys and seed phrases are not in the hosted database, and the hosted process is API-only. That removes one class of risk. It does not remove the exposure of the data above.
- Keys and seed phrases: not stored.
- Handle-owner association, address usage, link details, shared reports: stored by the server; some is visible to recipients and link holders.
- Waitlist email: stored as a hash only.