The product
How nullpay. works.
Pay with a card. Receive a voucher code. The blind signature severs the link between the two.
Where nullpay. fits
Privacy tools protect content. But your bank statement names each service. nullpay. replaces those merchant names with a single entry: “NullPay SAS.”
| Layer | Tool | What it protects | What it leaves exposed |
|---|---|---|---|
| Browsing | VPN service | Which websites you visit | Your bank names the VPN provider |
| Encrypted email | What you write | Your bank names the email provider | |
| Messaging | Encrypted messenger | Message content | (Free — no payment trail) |
| Storage | Encrypted cloud storage | File contents | Your bank names the storage provider |
| Payment | NullPay | Which service you chose | Your bank sees "NullPay SAS" |
Without nullpay.
2025-01-15 VPN Provider AB EUR 5.00
2025-01-15 Email Provider AG EUR 9.99
2025-01-16 Storage Provider GmbH EUR 3.00
With nullpay.
2025-01-15 NullPay SAS EUR 25.00
Step by step
Step 01
Choose a denomination
EUR 5, 10, or 25. Fixed amounts reduce correlation by price.
Step 02
Pay with your card
Standard card payment. NullPay records the amount paid and the denomination.
Step 03
Your browser blinds a token
A random token is generated in your browser and blinded before leaving your device. NullPay never sees the original.
Step 04
NullPay signs the blinded token
NullPay signs it without seeing the content — the sealed envelope from the previous article.
Step 05
Redeem later
You unblind the token and present it for a voucher code. NullPay can verify the signature is valid but cannot link this token to any payment.
Structural data separation
The privacy guarantee is structural. It’s enforced by how the system is built, not by a policy.
Payment records
Who paid, when, how much.
Customer identity and payment amount. No service field.
Redemption records
Which token, which service.
Token hash and service redeemed. No customer field, no payment reference.
These records are kept on physically separate servers with separate credentials. There is no shared key, no join path, no field connecting the two. Even with full access to both, you’d see who paid and what was redeemed — but the blind signature prevents linking one to the other at the cryptographic layer.
Side channels exist outside the cryptographic layer.
IP correlation, timing patterns, browser fingerprinting, and shared infrastructure can narrow the anonymity set independently of the blind signature. Batch processing and infrastructure separation mitigate these, but user precautions (VPN/Tor for redemption, temporal separation) further strengthen unlinkability. The guarantee is layered, not absolute from a single mechanism.
Batch processing
Redemptions are queued in a threshold pool mix. Batches fire only when enough real redemptions are waiting to form a meaningful anonymity set. Items may be randomly carried over between rounds, making it uncertain whether a request was processed in this batch or the next. Without batching, timing correlation is trivial: a payment at 14:03 and a redemption at 14:04 are easy to link regardless of the blind signature.
Dummy padding
Each batch includes dummy redemptions alongside real ones. Even the batch size reveals nothing about individual activity.
Anonymity set
Every redemption hides among all others in the same batch. The larger the batch, the stronger the unlinkability.
Current limitations
Honesty about what the system can and cannot do today.
Limited service catalog
4 services at launch (v1). Expansion depends on securing reseller agreements with each provider. The catalog will grow, but slowly and deliberately.
Anonymity set depends on volume
Batch sizes at current adoption levels may be small. A batch of 3 real redemptions offers weaker unlinkability than a batch of 300. Dummy padding helps, but it is not a substitute for real traffic. This improves with adoption.
Token storage: no backup, no recovery
Tokens are stored locally in your browser (IndexedDB). If you clear your browser data or lose your device, unredeemed tokens are gone. This is the trade-off for not storing tokens server-side. A .nullpay backup file is available before payment.
Single-operator risk
nullpay. controls both the payment and redemption servers. Open source and planned audits are the current mitigations. Long-term, a split-operator model (independent entities for each side) would eliminate this trust requirement.
Implementation not yet audited
RFC 9474 is a proven protocol. Our implementation of it has not been independently audited. The code is open source so you can verify it yourself. A professional audit is planned.
Full system diagram
All parties in both flows. The simplified three-party model on the homepage is useful, but the real system is more complex.
Payment flow
Redemption flow
What each party sees
The two flows share no CDN, no hosting provider, and no logging service. A single subpoena to any one party yields only their fragment. The blind signature prevents correlating fragments across flows at the cryptographic layer. Remaining side channels (IP, timing, shared infrastructure) are addressed by batching, infrastructure separation, and user precautions.