Pay with
anything.Settled in private.
A non-custodial payment gateway for shielded Zcash. Buyers pay in ZEC, or in USDC, SOL, ETH or BTC through NEAR Intents. (mainnet only on this testnet site). Every merchant is paid straight to its own shielded wallet.
Pay with
via NEAR Intents
Lunaz gateway
viewing keys only
Shielded
Each seller's wallet
spend key: theirs
Powered by
- Zcash
- NEAR Intents
- Zebra
- lightwalletd
The problem
Cash is private.
Crypto checkout is not.
Pay from a transparent wallet and the shop can read your whole balance and history. The shop leaks too: anyone with a block explorer can read its revenue, its suppliers and its regular customers.
0x7a3f…c91e · the buyer at checkout
- −4.50Kedai Kopitoday
- −312.00Apotekyesterday
- +2,000.00Exchange3 days ago
- −45.90Online store5 days ago
Kedai Kopi revenue today: 1,284.00 USDC and every customer behind it.
u1x9ph4w0k… · a Lunaz merchant
Searching…
No public records.
Shielded. Sender, amount and store stay encrypted. The receipt exists; only the merchant can read it.
- Merchants
- Take crypto without opening your books. A competitor cannot read your sales from a block explorer.
- Buyers
- Pay with USDC, USDT, SOL, ETH or BTC. It lands as shielded ZEC, and you never have to buy ZEC first.
- Accountants
- Get a CSV of every invoice and payment, built from the viewing key, for bookkeeping and tax. Private to the world, open to the books.
How it works
One payment, start to finish.Five stages, nothing public.
01 / 05
Invoice
A buyer places an order and the shop's backend creates an invoice with its API key. Lunaz derives a fresh shielded address for it from that merchant's viewing key. No two invoices share an address, so nothing on chain links them to each other or to the shop.
Invoice #00430.2500 ZECViewing key
uivk1qp8… hidden
↓ derive new address
Pay to
u1x9ph4w0kq7e3lzd52uv8cmt6rjy0ns4fa9gk2hw7pe3vq5m8c
- #0042 u1m3tz8vr…k0q2 · used once
- #0041 u1c7wa4lp…9xhd · used once
02 / 05
Pay
A ZEC buyer scans the ZIP-321 QR with their wallet. A buyer holding USDC, USDT, SOL, ETH or BTC gets a one-time deposit address from NEAR Intents, which swaps the funds and delivers shielded ZEC straight to the invoice address.
Cross-chain needs an invoice of at least 0.001 ZEC. The deposit on the origin chain is public; nothing links it to the shop.
ZIP-321
zcash:u1x9ph4w0k…?amount=0.25
Or from another chain · NEAR Intents
USDCZECUSDC · SOLswapshielded ZEC03 / 05
Detected
The watcher trial-decrypts Orchard and Ironwood actions in the mempool with the merchant's viewing key and matches the payment to its invoice. Checkout moves from Waiting to Detected in seconds, before the block lands.
Invoice #0043WaitingDetected0.2500 ZEC
Mempool
- watcher › scanning mempool
- watcher › shielded tx matches invoice #0043
- watcher › waiting for 1 block confirmation
04 / 05
LUNAS
After one block confirmation, about 75 seconds, the invoice turns LUNAS: paid in full. The shop's backend gets a signed webhook. A short payment is marked underpaid, never paid.
Confirmations0 / 11 / 1LUNAS
Invoice #0043 · 0.2500 ZEC · paid in full
05 / 05
Settled
The funds sit in the merchant's own shielded wallet. The server only holds a viewing key: it can see payments, but it can never move them.
Lunaz server
- Viewing key: can see payments
- Spending key
Merchant wallet · your keys
Spending key stays here+0.2500 ZEC shielded
If the server is breached, funds cannot move.
Viewing key
uivk1qp8… hidden
↓ derive new address
Pay to
u1x9ph4w0kq7e3lzd52uv8cmt6rjy0ns4fa9gk2hw7pe3vq5m8c
- #0042 u1m3tz8vr…k0q2 · used once
- #0041 u1c7wa4lp…9xhd · used once
Built for marketplaces
One gateway,
many merchants.
A marketplace or platform can onboard every seller as its own non-custodial merchant. A single online store calls the same API from its own checkout page. In a physical store, a point-of-sale app calls the same API.
- Paid straight to the seller
- Each order is invoiced with that seller's key, so the ZEC lands in the seller's own shielded wallet. Buyers check out per shop.
- Keys per seller
- Every seller is its own merchant with its own viewing key, API keys and webhook. One seller's key cannot invoice for another.
- No custody, no payouts
- The platform never holds funds or spending keys. There is no pooled balance to guard and no payout run to reconcile.
- Books per seller
- Each seller exports its own accountant CSV from its viewing key: invoices, payments, USD rate at payment time.
SUNDAY MARKET · DEMO
- Dusk Coffeeown wallet
- House of Batikown wallet
- The Little Bookshopown wallet
- Tiny Gadgetsown wallet
- Grandma's Kitchenown wallet
Security model
A hacked server can look.It cannot spend.
Lunaz splits seeing from spending. The gateway holds viewing keys only, and checkout pages hold no keys at all. Spending keys stay in each merchant's wallet. We run and monitor the gateway, so there is nothing for you to deploy.
KEY CUSTODY
- Server holds
- viewing key
- Server never holds
- spending key
- Funds land in
- the merchant's own wallet
- Custody
- none
- Operated by
- Lunaz, fully managed
Why now
Private by default. Transparent by choice.
- 01
The stablecoin wave
Stablecoin payments are going mainstream, almost all of them on transparent chains. Every one leaks a little more merchant data.
- 02
The rails just arrived
NEAR Intents now swaps from other chains straight into shielded ZEC. Until recently the destination had to be a transparent address.
- 03
New people in the shielded pool
Every USDC or SOL payment becomes a fresh shielded transaction, from someone who may never have held ZEC.
Developers
Create an invoice. Get a webhook when it is paid.
- Invoices and live status
- One call per order returns a fresh shielded address and a ZIP-321 URI. A WebSocket pushes pending, detected and paid.
- Signed webhooks
- invoice.paid and invoice.underpaid, plus swap refunds and failures. Failed deliveries retry, and every attempt is in the delivery log.
- Honest amounts
- Payments to one address add up. Overpayments are recorded; a short payment ends as underpaid instead of paid.
- Developer dashboard
- Register the viewing key, create API keys, test webhooks, search invoices and export the accountant CSV.
POST /v1/invoices
Authorization: Bearer lz_...
{ "amount_zat": 25000000 }
201 Created
{
"id": "inv_...",
"address": "u1...",
"zip321_uri": "zcash:u1...?amount=0.25",
"status": "pending"
}
# invoice.paid, retried after 10 s and 60 s
X-Lunaz-Event-Id: <event id>
X-Lunaz-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256 of "{t}.{body}">Honest answers
What Lunaz does not hide.
Is the buyer fully anonymous?
Not entirely. A buyer who pays from another chain still makes a public deposit on that chain. Nothing public links that deposit to the shop or to what was bought.
Does Lunaz hold my money?
No. The server holds viewing keys only, never spending keys. Funds go to each merchant's own shielded wallet.
Is cross-chain payment live?
Yes, through NEAR Intents: USDC, USDT, SOL, ETH and BTC on their main chains. The invoice must be at least 0.001 ZEC, and a failed swap is refunded to the buyer's address.
What if a buyer pays too much or too little?
Payments to the same address add up, so a buyer can top up before the invoice expires. Any excess is recorded as overpaid; a short payment ends as underpaid. Lunaz cannot refund either, since it cannot spend. The merchant does.
Which shielded pools does it watch?
Orchard and Ironwood, in both the mempool and mined blocks. A payment shows as detected in seconds and turns LUNAS after one confirmation, about 75 seconds.
Do I need to run any infrastructure?
No. Lunaz is a managed service: we run the gateway, the chain watcher and the cross-chain swaps. You sign up, connect your wallet's viewing key and call the API.