Platform
Operate the pool without becoming the prover.
The workspace is the application layer on top of the privacy protocol. Finance teams create payment requests, watch settlement, hold shielded balances, and export records to an auditor — without deploying contracts or managing proving keys. Every payment still lands in the same Merkle tree described in the protocol docs.
Control plane
One workspace, five surfaces.
Authentication is a Freighter-signed challenge against the core backend. The session cookie authorizes dashboard routes. It is not a spend key and cannot move notes.
| Tab | Job |
|---|---|
| Overview | Workspace status: open requests, recent settlement, shielded vs liquid balance. |
| Payments | Create links, send privately from owned notes, track hosted checkout. |
| Treasury | Shielded notes, unshield to a public address, denomination top-up. |
| Developers | API keys and webhook endpoints for the Payments API (same workspace). |
| Settings | Profile, receive address, viewing-key export for an auditor. |
Accept
Payment links and hosted checkout.
A link is an internal checkout object. The customer-facing URL is /pay/{id}. Privacy-on checkout spends owned notes via transfer or transfer_n. Privacy-off is a classic Stellar payment with an hpl_ memo.
- Note selection is
{1, 2, 4}to match live VK ids 3, 4, and 5. Three-note covers need a fourth owned note or a top-up. - If owned notes do not cover the amount, checkout still has a transparent deposit fallback. That path puts amount on the explorer. Treat confidential checkout as incomplete until that fallback is gone.
- Note secrets for a private deposit live in browser
localStoragekeyed by the link. They are never sent to Nest.
Treasury
Shielded balance is a note set, not an account.
The workspace lists confirmed unspent notes with leaf indices. Unshield is still the 1-in circuit (VK 2): one note out to a public recipient, change retained by the wallet. TransferN consolidation exists in the pool; the withdraw UI is not yet wired to it.
Selective disclosure
Export a viewing secret. Never a spend key.
An auditor with the viewing secret can decrypt blobs encrypted to that key, recompute commitments, and match on-chain leaves. They cannot derive nullifiers or spend. This is read-only disclosure, not invoice-bound ZK receipts.
Current export is auditor-grade viewing material, not bookkeeper-grade reconciliation and not a proof that invoice X settled for amount Y without revealing the pool. Those proofs are not in the protocol yet.
Boundary
The workspace is not the trusted core.
Dashboard, payment-link APIs, and viewing-key export can fail or lie without minting a note. Validity is Groth16 verification plus the commitment and nullifier contracts.
| In the platform | Not in the platform |
|---|---|
| Payment links, checkout, treasury UI, webhook config | Circuit definitions, VK administration, Merkle insert authority |
| Freighter session cookie (ht_dashboard) | spend_sk, proving keys, ceremony transcripts |
| Viewing-key auditor export | Invoice-bound ZK receipts, SEP-6 / SEP-24 fiat ramps |