Your subscribers shouldn’t be a public list
Subscribers pay in USDC. Nobody can list who they are.
How subscribers get identified
- vpn network
- traffic: encrypted ✓
- exit nodes: hidden ✓
- payments: public
01 The network is private. Billing isn’t.
- block explorer
- → vpn deposit address
- 0x3a9e… 9 USDC
- 0xb71d… 72 USDC
02 Anyone exports the payer list.
- lookup
- 0x3a9e… → exchange account
- name, email, country
03 Payers become people.
What a payment address leaks
All of it is readable from one public address, by anyone, for as long as the chain exists.
- 01 Subscriber list Every wallet that ever paid you.
- 02 Real identities Wallets lead to exchanges and names.
- 03 Renewals and churn Who stays, who leaves, and when.
- 04 Revenue Your sales figure, readable by rivals.
How it works
- Payment request Created
- ref
- account 7f3e
- amount
- 9.00 USDC
01
Create a request
Your server, one per order
- Payment request Paid
- ref
- account 7f3e
- amount
- 9.00 USDC
- from
- customer wallet
02
Customer pays
From the wallet they have
- Payment request Shielded
- ref
- account 7f3e
- amount
- 9.00 USDC
- from
- customer wallet
- to
- hidden
03
Shielded on arrival
Fresh address, every time
- Payment request Confirmed
- ref
- account 7f3e
- amount
- 9.00 USDC
- from
- customer wallet
- to
- hidden
04
Order confirmed
Matched by reference
- No customer account
- Hosted checkout
- USDC + USDT on Arbitrum
- From $0.50
The line carried the call. The board saw who was calling whom.
Long-distance operators, Bell Telephone Magazine, 1937
Internet Archive Book Images, no known copyright restrictions
Who sees what
The payer’s own transfer is always public.
| who | The payment | That they use you | Subscriber count |
|---|---|---|---|
| The public | Can see | Hidden | Hidden |
| You | Can see | Can see | Can see |
| Your accountant | Can see | Only if you share your viewing key | Only if you share your viewing key |
But what about…
- Refunds
- A new payment back to the customer, from your own process.
- Tax and accounting
- Your accountant reads every payment with the viewing key.
- Compliance
- Incoming funds are screened before they’re shielded.
- Custody
- You hold the keys. Curvy can’t move your funds.
- Chargebacks
- None. Onchain payments are final.
- Customers without USDC
- Keep your other methods. This is one more option.
Is it right for you?
Good fit if
- Your customers pay, or ask to pay, in USDC or USDT
- Your revenue or customer list is sensitive
- You’re happy to receive stablecoins, not fiat
- You can add a server-side call to checkout
Not yet if
- You need fiat paid into your bank automatically
- You need chains other than Arbitrum
- Your customers pay in Bitcoin or other coins
- You need a no-code store plugin today
Built to be checked
- Audited by Ethernal Full report public on GitHub
- Open-source contracts github.com/0xCurvy
- Published research Stealth address protocols
- 10+ years together Two PhDs in ZK and cryptography
Questions
Do subscribers need a Curvy account?
No. They pay from the wallet they already use. Nothing changes on their side.
Can anyone see that a wallet paid for a VPN?
They can see the wallet sent a payment, not where it went. The address is fresh and isn’t linked to your service.
Do you support recurring subscriptions?
Each renewal is its own payment request, created by your billing system and paid on the hosted checkout.
Which stablecoins are supported?
USDC and USDT, settled on Arbitrum. The minimum payment is $0.50, and fees are taken from the payment.
Protect the payment the way you protect the traffic.
Tell us how you take payments today, and we’ll show you where Curvy fits.
Watch the demo- Your payment flow, step by step
- What stays visible, and to whom
- How the SDK fits your stack
- Your compliance questions