Privacy & evidence
Understand the private proof statement, public metadata, and the claims selected evidence can support.
The proof hides the input note
Groth16 proves a valid spend from the shared tree without naming the input commitment. A global nullifier prevents reuse, and the action context binds the destination.
Principal remains in independent vaults and one funded vault pays the bound recipient directly. Funds do not hop through an A → B → C sequence. Adding vaults alone does not measure or guarantee a larger effective anonymity set.
What remains visible
Small groups, address reuse, funding provenance and matching timing can correlate deposits and payouts. Published candidate, timing and funding observations do not establish an effective anonymity set or network-layer anonymity.
| Observer | Information available |
|---|---|
| Public chain observer | Commitments, vault funding/balances, signers, assets, amounts, payout vault, recipient, timing, nullifiers, and disclosure references. |
| Invoice link holder | Signed terms and derivation inputs for all payment references. |
| API / RPC | Public preparation/status requests, addresses, and invoice-reference associations. |
| Evidence recipient | Selected fields and transaction records you explicitly disclose. |
Selective disclosure commitments
Salted Merkle commitments support selected receipt fields and openings against a root. Unrelated fields can remain undisclosed.
An opening proves integrity against that commitment. Proving a payout additionally requires matching finalized evidence. Keep legal names, payroll documents, and statutory forms in separately encrypted off-chain storage.
Match each claim to its evidence
These claims do not establish complete company history, identity by wallet signature, or tax filing acceptance. Development setup and local verification do not replace a production security review.
| Evidence | Supported claim |
|---|---|
| Merchant signature | The signing wallet authorized these invoice terms. |
| Finalized records | Selected bound payout observations at the reported checkpoint. |
| Selected field openings | Disclosed values match a receipt commitment. |
| Provider attestation | Requires a real KYB provider/issuer integration; the current intake issues none. |
Encrypted terms stay client-held
The invoice library encrypts saved signed requests with AES-256-GCM and a passphrase-derived key. It uses its own authenticated storage format and merchant/network namespace, separate from the operation journal. Saving, opening, searching and backing up library entries sends no terms to the service.
This archive verifies signed-term integrity locally. It does not certify legal identity, current merchant key permissions, payment completion or statutory retention. Shared payment links and individual signed JSON exports still reveal their terms to holders.
Private receipts and selected disclosure
Receipt integrity verified means the selected values and proof match the root you supplied. The browser makes no chain request. Truthful declarations, root anchoring, payment completion, identity and tax acceptance require separate checks. Use the existing CLI verify-bundle with your independently configured evidence source for selected finalized transaction anchoring.
Full backups use a separate encrypted receipt format. Locking, page-hide and cached return clear private workspace state; pending cryptographic or file work cannot reopen it. Keep the downloaded file and passphrase separately.
Invoice unit references and arbitrary receipt roots are distinct bindings. A generic action may commit to a receipt root; invoice checkout requires the signed-derived unit reference. Receipt integrity does not establish invoice payment, and substituting its root breaks checkout binding.
- Create a receipt on Evidence with the declarations you want to commit. Choose and confirm a passphrase, then download the encrypted full receipt. Nothing is uploaded to the API.
- Reopen the saved backup to verify it. Select only the fields you intend to share; no fields are selected by default. Review the readable values before downloading a selected disclosure.
- On Private notes, import the disclosure file to check its local integrity and use only its root for a deposit plan. Keep receipt openings, note backups and operation journals separately. Create a fresh root per operation; reused roots link activity.
- To review someone else’s disclosure, obtain the expected root independently, load the selected file and run Verify receipt integrity. The root is never filled from the file automatically.
Separate artificial activity from participation
The bounded native cover experiment finalized four operator-owned transactions and returned its principal. Its synthetic withdrawal had six all-history output candidates, three after excluding labelled artificial outputs. Independent participants added: zero. These mechanical candidate counts are not a measured customer privacy benefit.