SPECTER
Private receiving without a public recipient trail
SPECTER lets you publish one public meta-address and receive each payment at a different one-time stealth address.
The discovery path uses ML-KEM-768, so the announcement data that helps you recover payments is designed to remain private even under future quantum attacks.
Use the docs by goal
These docs are organized around reader intent. Start with the path that matches your job.
- Evaluating SPECTER
- Builder
- Contributor
- Deep technical review
Read The Problem for the privacy and quantum context, then How SPECTER Works for the plain-language model.
Use SPECTER vs Others and Security Boundaries to evaluate tradeoffs honestly.
Working in TypeScript? Start with the SDK Quickstart to run the whole protocol locally, then read the SDK API Reference and Integration Patterns.
Prefer calling a service? Use the API Quickstart, the Integration Guide, and the API Overview.
To run the stack locally, go to Installation and Development Setup.
Review Contribution Opportunities first. It maps the current GitHub backlog to repo areas and contributor skill sets.
Then use Contributing for the workflow and Verification Matrix to keep changes source-backed.
Go straight to Protocol Flow, Architecture, and Post-Quantum Cryptography.
For source-backed validation, use Verification Matrix and the product repo on GitHub.
Protocol in 30 seconds
One public address in. A different stealth address for every payment out. Step through the three phases:
You generate two ML-KEM-768 keypairs and publish one meta-address. That is the only address you ever share.
- Spending key controls funds
- Viewing key detects payments
- Meta-address is public and reusable
The same flow as a single diagram:
- The recipient creates a
meta-addressfrom public spending and viewing keys. - The sender derives a one-time stealth address from that
meta-address. - The sender transfers funds and publishes an announcement using the server-bound
payment_id. - The recipient scans announcements, recovers the matching stealth key, and spends normally.
Observers can see the transfer and the announcement. They should not be able to link the stealth address back to the recipient without the private keys.
Current implementation status
The docs describe the current shipped behavior, not the end-state vision.
| Area | Current status |
|---|---|
| Key generation | The @specterpq/sdk generates ML-KEM-768 keys locally in WebAssembly, so secrets stay on the device. The hosted API also exposes POST /api/v1/keys/generate, where the backend generates the keys. |
| Scanning | The SDK scans announcements locally with the viewing key. The hosted API offers server-side scanning for backends that own the full flow. |
| Announcement recovery | Discovery currently depends on the backend-managed registry. Backend-independent recovery from on-chain announcements is tracked in issue #16. |
What makes SPECTER different today
| SPECTER | Classical stealth (Umbra/Fluidkey) | |
|---|---|---|
| Discovery crypto | ML-KEM-768 (post-quantum) | ECDH (broken by quantum) |
| Harvest-now-decrypt-later safe | Yes | No |
| View tag scanning | ~1-2s for 100k announcements | 10-15s |
| Multi-chain | Ethereum + Sui | Ethereum only |
| Name service integration | ENS + SuiNS | ENS |
| NIST standard | FIPS 203 | N/A |
If you only read three pages, start with How SPECTER Works, Protocol Flow, and Security Boundaries.
