Keep your MRR off the public chain
Customers pay invoices in USDC. Competitors can’t chart your growth.
What your billing address leaks
All of it is readable from one public address, by anyone, for as long as the chain exists.
- 01 MRR Your revenue chart, updated every block.
- 02 Growth and churn Who starts paying, and who stops.
- 03 Pricing What each enterprise deal is really worth.
- 04 Customer list Known company wallets name your customers.
What a competitor can chart today
USDC, thousands per month
Nothing to chart
The payments aren’t linkable to you.
Your growth curve, drawn from public transfers. Values are illustrative.
How it works
- Payment request Created
- ref
- invoice INV-2207
- amount
- 299.00 USDC
01
Invoice due
Billing creates a request
- Payment request Paid
- ref
- invoice INV-2207
- amount
- 299.00 USDC
- from
- customer wallet
02
Customer pays
From the wallet they have
- Payment request Shielded
- ref
- invoice INV-2207
- amount
- 299.00 USDC
- from
- customer wallet
- to
- hidden
03
Shielded on arrival
Fresh address, every time
- Payment request Confirmed
- ref
- invoice INV-2207
- amount
- 299.00 USDC
- from
- customer wallet
- to
- hidden
04
Invoice closed
Matched by reference
- No customer account
- Hosted checkout
- USDC + USDT on Arbitrum
- From $0.50
What your customer sees
Three screens. No account and no browser extension. The private part happens on your side.
-
your site
Team plan, monthly
299.00 USDC
Pay by card Pay with USDC or USDT01 One more button at checkout
-
hosted checkout
Amount due
299.00 USDC
Pay from walletNetworkArbitrumPay withUSDC02 Pay from the wallet they have
-
confirmation
Payment received
invoice INV-2207
03 Done. No account, no extension
An example of what your customer sees. Not a live checkout.
Who sees what
The payer’s own transfer is always public.
| who | The payment | Who got paid | Your MRR |
|---|---|---|---|
| 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 |
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
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.
Built to be checked
Private, not unaccountable. How the compliance model works
Questions
Does it handle recurring billing?
Each renewal is its own payment request. Your billing system creates it when an invoice is due. There are no pull payments.
Do we need to change our billing system?
No. It stays the source of truth. It calls the Payments SDK when payment is due, and your backend closes the invoice by reference.
Can our accountant see revenue?
Yes. A viewing key gives read-only access to every payment. It can’t move funds.
Which stablecoins are supported?
USDC and USDT, settled on Arbitrum. The minimum payment is $0.50, and fees are taken from the payment.