YOUR WALLET.
YOUR PRIVACY.
YOUR CONTROL.
Receive cryptocurrency through unique stealth addresses. Keep your reusable wallet identity out of the public payment trail.
- Addresses per receiver
- Unlimited
- Keys shared with sender
- Public only
- Fund custody
- Self-held
Sender
Bob
0xE41b…C72a
Holds only Alice's public stealth meta-address.
One-time derivation
Fresh ephemeral key per payment
Computed entirely in the sender's browser. No private key is ever shared.
Independent one-time addresses
- 0x7Ae4…41Be10 AVAX
- 0x3F19…a9E72.5 AVAX
- 0xB62f…6F230.75 AVAX
Alice detects all three
Only the holder of the private viewing key can tell which announcements belong to them, and only the spending key can move the funds.
Public observers
See the addresses and amounts, but not the link back to Alice's reusable wallet identity.
The problem
EVERY PAYMENT LEAVES A TRAIL.
Blockchains are public ledgers. The moment you share one wallet address to get paid, you hand every observer a permanent window into your finances — even if you never reveal your name.
Address reuse — the default today
- Client A10 AVAX
- Client B2.5 AVAX
- Marketplace0.75 AVAX
- Client A again4 AVAX
One reused wallet
0x6B2e…7E42
Four payments, one address. An observer now has your balance, your counterparties, your cadence — and can correlate all of it to a single identity.
Every incoming payment
Anyone can watch what lands in your address, from whom, and when.
Your running balance
Your holdings and full history are permanently public.
Your payment relationships
Repeated counterparties reveal who you work with and get paid by.
Not revealing your identity is not the same as privacy.
Reusing a single address does the de-anonymising work for an observer. Over time, the pattern itself becomes the identifier.
Our solution
ONE IDENTITY.
UNLIMITED STEALTH ADDRESSES.
Share a reusable Stealth Meta-Address once. Every sender derives a brand-new, one-time destination from it — and only you can find or spend what arrives there.
Traditional payment
Identity exposedSender
0xE41b…C72a
Alice's primary wallet
0x6B2e…7E42
The receiving address is reusable and publicly tied to Alice. Every future payment to it is linkable to the same person.
StealthPay
Identity unlinkableSender
0xE41b…C72a
One-time stealth address
0x7Ae4…41Be
Alice detects it privately
private viewing key
The address funds land on is used once and is derived from public key material. Alice's reusable wallet never appears in the transaction.
No sender friction
Senders don't need a new wallet, token, or mental model. They pay an address.
Keys stay yours
Viewing and spending keys are generated and used client-side. Never uploaded.
Standards-based
Built on ERC-5564 rather than a bespoke scheme, so it interoperates.
How it works
FOUR STEPS, ONE PRIVATE PAYMENT.
Select a step to see what happens on each side of the payment, and the cryptography behind it.
Create Your Stealth Identity
Alice generates two independent key pairs on their own device and publishes only their public halves.
- A viewing key pair (a, A) that detects incoming payments.
- A spending key pair (b, B) that recovers control of one-time addresses.
- The Stealth Meta-Address (B, A) is safe to share as a QR code, link or string.
- Both private keys stay on the device — they are never sent to a sender or a backend.
Cryptography
A = a·G B = b·G Meta-Address = (B, A)
Two key pairs on the SECP256k1 curve.
Core features
BUILT FOR ONE JOB: UNLINKABLE RECEIVING.
StealthPay deliberately solves a single problem well rather than bundling unrelated privacy machinery. Scope labels below separate the MVP target from planned work.
One-time stealth addresses
Every payment lands on a freshly derived address that has never been used before and never will be again.
Private payment detection
Your private viewing key identifies which on-chain announcements are yours. Nobody else can tell.
Reusable stealth identity
Publish one Stealth Meta-Address forever. It produces unlimited unlinkable destinations.
Direct spending
Derive the one-time key locally and send funds straight onward. No sweeping through your main wallet.
Native AVAX payments
The MVP target: send and receive native AVAX on the Avalanche C-Chain.
ERC-20 payments
Token support requires solving gas funding for token-only stealth accounts. Designed, not yet built.
ERC-5564 compatibility
Standard announcement interface and SECP256k1 derivation, so other compliant tooling interoperates.
Avalanche integration
Contracts and payments run on the Avalanche C-Chain, demonstrated end to end on Fuji.
Scope: StealthPay targets native AVAX first. ERC-20 payments are supported by the payment router but need native AVAX at the destination before the tokens can be moved, which is why they are listed separately above.
Security & privacy
PUBLIC KEYS TRAVEL. PRIVATE KEYS DO NOT.
StealthPay separates the ability to see payments from the ability to spend them, and keeps every secret on your own device.
Viewing key
(a, A)
Detects incoming payments. The private half scans announcements; the public half is published in your meta-address.
Scanning needs only this key — never your spending key.
Spending key
(b, B)
Recovers control of one-time addresses. The private half derives the key for each detected payment.
Used only at the moment you spend, always client-side.
Ephemeral key
(r, R)
Generated fresh by the sender for every single payment. Only the public half R is published on-chain.
Reusing r across payments would break unlinkability.
One-time address derivation
- Sender computes
- S = r·A then P = B + H(S)·G
- Receiver recomputes
- S' = a·R then P' = B + H(S')·G
- Receiver spends with
- x = (b + H(S')) mod n
Both sides reach the same secret by elliptic-curve Diffie–Hellman, without ever exchanging a private key.
Custody rules
- Private keys are generated with a cryptographically secure random source.
- Receiver keys are never shared with senders.
- No private key is submitted to a backend API or written to the database.
- Spending-key derivation happens in a protected client-side context.
- Detected payments are verified against real on-chain transfers.
What StealthPay does and does not hide
Read before assuming moreUnlinkable
- The link between a stealth address and your reusable wallet
- Which announcements belong to you (without your viewing key)
- Your primary wallet as a named counterparty
Still fully public
- The sender's address
- The destination stealth address
- The transaction amount
- Transaction timing
- Any onward transfer you make
StealthPay provides recipient identity unlinkability, not complete transaction anonymity. It is not a mixer, it does not provide confidential balances or amounts, and it does not use zero-knowledge proofs. It also does not provide sender anonymity or protection against sophisticated timing and amount correlation.
Avalanche
WHY THE AVALANCHE C-CHAIN.
StealthPay needs an EVM chain where derived addresses are first-class accounts and standard contracts just work. The C-Chain provides exactly that — and the project uses it as infrastructure, not as a label.
EVM compatibility
The C-Chain runs EVM bytecode, so stealth addresses derived on SECP256k1 are ordinary, valid Avalanche addresses. No bridging, wrapping or custom account model.
Solidity contracts
The announcer and payment router are plain Solidity, deployed with Hardhat. The on-chain layer stays deliberately thin — it moves funds and emits events, nothing more.
ERC-5564 integration
The standard announcement interface is used as-is, so StealthPay interoperates with other compliant stealth-address tooling rather than inventing a private scheme.
Fuji testing environment
Fuji is the default network for all development and the demo. Real assets are never used during testing.
Network support
| Network | Chain ID | Currency | Role |
|---|---|---|---|
Avalanche Fuji C-Chain https://api.avax-test.network/ext/bc/C/rpc | 43113 | AVAX | Default — dev & demo |
Avalanche C-Chain https://api.avax.network/ext/bc/C/rpc | 43114 | AVAX | Future production |
Scope note: Avalanche-specific primitives such as eERC, ICM and ICTT are optional for this build and are intentionally not used — they do not serve the stealth-address privacy problem, and adding them would inflate the stack without improving the product.
Get started
MAKE EVERY PAYMENT
ADDRESS A FRESH START.
Publish one stealth meta-address. Receive on a new address every time. Keep your wallet identity out of the public payment trail.
Runs on Avalanche Fuji. Your keys are generated and encrypted in your own browser.