Privara: Exploring payment-scoped selective disclosure for privacy on Stacks

Apps
1

Hi everyone,

I’m Samuel, building Privara, a privacy-focused payment protocol on Stacks. We’ve completed our initial grant milestones and deployed a working mainnet payment flow. I’m now exploring how to extend its privacy model, particularly around selective disclosure.

What’s implemented

Privara currently uses secp256k1-based stealth-address derivation to generate one-time recipient addresses, reducing the ability to link payments through a persistent recipient address.

The implementation also includes SIP-018-based payment authorization, sponsored transaction flows, and payment discovery mechanisms.

These provide recipient-address privacy, not full transaction confidentiality. Amounts, transaction activity, and other on-chain metadata remain observable.

What I’m exploring

The next step is payment-scoped selective disclosure: allowing a recipient to share verifiable information about a specific payment with an auditor or counterparty without exposing unrelated payments or granting access to their entire wallet history.

I’m considering a design where a recipient can generate a narrowly scoped disclosure package containing payment-specific evidence, potentially supported by encrypted payment metadata and cryptographic proofs.

This is still research, not an implemented viewing-key system.

Questions I’d appreciate feedback on:

  1. Verification: What would be the most appropriate way to bind a disclosure package to an actual Stacks transaction and recipient without exposing a reusable identity or derivation secret?

  2. Key separation: Would per-payment disclosure keys derived from a dedicated viewing secret be preferable to sharing encrypted payment metadata directly? How should this avoid leaking unrelated payment relationships?

  3. Clarity constraints: Which parts of disclosure verification should reasonably happen on-chain versus in an off-chain verifier, given Clarity’s cryptographic capabilities and execution constraints?

  4. Protocol direction: Are there ongoing Satoshi Upgrades or privacy research discussions that this should align with, particularly around viewing keys, shielded payments, or sBTC?

I’m not proposing a SIP at this stage. I’d first like to validate the threat model, understand the relevant protocol constraints, and determine whether this belongs entirely at the application layer.

I’d appreciate feedback from anyone working on Stacks Core, Clarity, wallet infrastructure, or privacy research.

Privara: GitHub - Psalmuel01/privara: Privacy-preserving SIP-010 intents payment protocol on Stacks · GitHub
Website: https://useprivara.xyz

Thanks,
Samuel