One-time recipient addresses for private asset payments on Stacks.

Privara lets someone send sBTC, USDCx, or native STX to a recipient's normal Stacks identity while settling the payment to a fresh one-time address controlled by that recipient. The recipient's long-term wallet is therefore not exposed as the onchain settlement destination.

Open the app · Read the user guide · Install the SDK · Read the protocol specification · Read the Stacks Forum post

A sender only needs the recipient's normal Stacks address or BNS name. Privara resolves the recipient, checks whether that address has registered public privacy keys, derives a fresh settlement address in the sender's browser, and prepares an exact payment for wallet approval. Each supported asset uses an independently pinned router policy.

For recipients, Privara provides:

• a separate privacy identity generated locally in the browser;
• an encrypted recovery file that must be exported and restore-verified before use;
• local scanning for payments sent to derived one-time addresses;
• sponsored spending when a one-time address holds sBTC or USDCx but no STX;
• direct spending from a one-time STX address using its own displayed network fee;
• the option to pay another address directly or withdraw to a chosen wallet.

For senders and treasury operators, Privara provides:

• immediate validation that every recipient has registered Privara keys;
• a choice to add the settlement fee on top or include it in the entered amount;
• automatic calculation of any router-funding shortfall;
• SIP-018 signatures binding the exact recipient, amount, fee, nonce, expiry, and router;
• individual private settlements for SIP-010 DAO and contributor payouts.

The asset selector enables only policies advertised by the live relayer and pinned by the application. Sending, scanning, activity, balances, decimals, and fee rules always follow the currently selected asset.

This example uses sBTC. Native STX and enabled USDCx payments follow the same fresh-address settlement model, with different spending-fee behavior described below. Alice wants Bob to receive 0.0001 sBTC without using Bob's everyday wallet as the settlement destination.

1. Bob creates a Privara privacy identity, downloads its encrypted JSON backup, successfully restores it, and registers only the public P/V keys.
2. Alice enters Bob's normal Stacks address and 0.0001 sBTC in Privara.
3. Privara verifies Bob's registration and derives a new one-time address locally.
4. Alice chooses Add fee on top. At the current 1% settlement rate, Bob receives exactly 0.0001 sBTC, the settlement fee is 0.000001 sBTC, and Alice authorizes 0.000101 sBTC in total.
5. If Alice's Privara router balance is short, the app asks for one wallet approval to fund only the difference. There is no separate deposit workflow to manage.
6. Alice reviews the final numbers and signs the exact SIP-018 intent. The relayer submits it, and the router settles Bob's amount to the fresh address.
7. Bob unlocks his verified privacy identity and scans. His browser recognizes the public announcement and derives the one-time spending key locally.
8. Bob can later pay someone directly from that one-time balance or withdraw it. For a sponsored spend, Privara shows and freezes the exact sBTC service fee before Bob signs; the sponsor pays the Stacks network fee in STX.

flowchart LR
    A["Alice enters Bob's normal address"] --> B["Privara reads Bob's public P/V keys"]
    B --> C["Alice's browser derives a fresh one-time address"]
    C --> D["Alice reviews amount, fee, and funding shortfall"]
    D --> E["Alice signs the exact SIP-018 intent"]
    E --> F["Relayer submits settlement to the router"]
    F --> G["Fresh address receives Bob's sBTC"]
    F --> H["Encrypted announcement is emitted onchain"]
    H --> I["Bob scans locally with his privacy identity"]
    I --> G
    G --> J["Bob pays another address or withdraws"]

The diagram illustrates address flow, not hidden transaction activity. The asset, amount, timing, payer interaction, relayer activity, one-time address, and later spends remain public or observable.

Privara creates an independent 32-byte privacy seed in the recipient's browser. It derives separate spending and viewing keys, p and v, and their public keys, P and V. Only P and V are registered onchain.

Registration remains disabled until the encrypted backup has been downloaded and the same backup has been successfully restored. Importing a different identity cannot silently overwrite an existing one.

For each payment, the sender's browser generates a fresh ephemeral key and combines it with the recipient's registered public keys to derive a one-time Stacks principal. The sender signs a router-bound SIP-018 intent with a random unordered nonce and expiry.

The relayer submits the intent. The selected asset router recovers the signer, enforces the asset, amount, fee, expiry, and replay rules, transfers the asset, and emits the encrypted announcement used for recipient discovery. Router funding is handled as part of the payment flow: the application requests only the exact shortfall and waits for it to confirm rather than exposing a separate deposit workflow.

The recipient selects an asset and scans that router's public announcements. Invalid records are skipped individually, so one malformed announcement cannot stop the remaining scan. Matching and one-time-key derivation happen locally from the privacy identity. The recipient switches assets and scans again to discover balances from a different router; detected Activity is rebuilt for the selected asset and browser session rather than stored as a private server-side history.

For an sBTC or USDCx spend, the browser first fetches the exact sponsor quote. The displayed destination, payment amount, fee recipient, token fee, asset, and expected sponsor are frozen into the origin-signed transaction. The relayer rejects any mismatch instead of silently refreshing the quote. A native STX one-time address needs no sponsor: it signs locally and pays its own exact network fee. Full-balance STX moves subtract that fee automatically.

The sender can choose:

• Add fee on top: the recipient gets exactly the entered amount.
• Include fee in amount: the settlement fee is deducted from the entered total.

For SIP-010 assets, the sponsored-spend fee is fetched before confirmation, displayed exactly, and signed with the spend. A full withdrawal sends the available token balance minus that approved fee. The destination is always entered by the user; Privara does not default it to the connected long-term wallet. The recommended current path is to pay the intended person or merchant directly from the one-time address. Users can instead move the balance to a fresh self-custody Stacks address for conventional wallet access or operational separation, but that transfer remains publicly traceable and may simply add another observable hop.

Privara does not currently convert sBTC to BTC or accept a Bitcoin bc1 destination. A planned integration will let the one-time key authorize the official sBTC peg-out locally and deliver BTC to a user-selected Bitcoin address, including a compatible exchange deposit address. Privara will facilitate that protocol request rather than take custody of the user's funds.

Privara's guarantee is specific: the recipient's long-term wallet is not the onchain settlement destination.

Privara does not claim to hide payment amounts, payer activity, transaction timing, relayer or network metadata, or links created by later spending and withdrawal.

Stealth balances are controlled by the independent Privara privacy seed—not by Leather, Xverse, or a connected hardware wallet. Those wallets cannot recover the privacy seed or its one-time balances.

Recommended wallet hygiene:

• keep the encrypted Privara backup and its password in separate secure locations;
• never share the privacy seed, p, v, a one-time private key, or backup password;
• use a new one-time destination for every incoming private payment;
• avoid immediately consolidating every one-time balance into the same known wallet;
• pay a merchant or recipient directly from a one-time balance when appropriate;
• treat distinctive amounts and immediate withdrawals as potentially linkable.

No. Alice enters Bob's normal Stacks address or mainnet BNS name. Privara resolves it, reads Bob's registered public privacy keys, and derives a fresh one-time destination automatically.

There is no separate deposit workflow in the current interface. The router can only settle tokens transferred to it by the sender, so Privara checks the existing router balance and requests one wallet approval only for the exact shortfall.

No. The amount, token, timing, settlement address, and transaction activity remain visible onchain. Privara protects the recipient's long-term wallet from appearing as the settlement destination.

The recipient's independent Privara privacy seed derives its spending key. The connected Leather, Xverse, or hardware wallet does not control or recover those funds.

Once public P/V keys are registered, payments can be sent to addresses controlled by that privacy identity. Restore verification proves that the recipient can recover the same identity before it is used to receive funds.

Not silently. Privara compares the imported public identity with any existing identity and stops on a mismatch. An unrelated backup cannot appear to recover registered funds.

No. The scanner reads public announcements, while ownership checks and spending-key derivation happen locally. Private key material is not sent to the relayer or indexer.

It remains a valid address, but Privara derives a fresh destination for every payment. Deliberate reuse weakens privacy and is not the intended workflow.

Yes. The recipient can send an amount supported by the selected one-time balance to another valid address. Privara never combines separate one-time balances automatically.

The sender pays the network fee for any router-funding transaction. The relayer pays the network fee for router settlement. When spending sBTC or USDCx from a one-time address, Privara's sponsor pays the Stacks fee in STX and the recipient approves a displayed fee in the token being moved. A one-time STX address instead pays its own network fee and incurs no sponsorship fee. The original private payment's settlement fee is paid by the sender, either on top of or inside the entered amount.

No. The approved quote is pinned. If the destination, amount, asset, fee recipient, sponsor, or fee changes, submission fails and the user must review a new quote.

No. Privara shows an indicative BTC/USD estimate from CoinGecko to make small sBTC amounts easier to understand. USDCx uses a nominal dollar display. The $5, $10, $25, $50, $100, and $250 shortcuts convert the latest estimate into an exact number of sats, and that exact sBTC amount is what appears in the review and signed transaction. Market-price changes never alter an approved transaction, and private payments remain available if pricing is temporarily unavailable.

Not yet. Automated regression coverage, mainnet infrastructure, small-value real-sBTC acceptance, and informal technical feedback from Werner are confirmed. This feedback was not conducted on behalf of Leather or Stacks, and was not a security audit or mainnet signoff. Independent reproduction and all stated Milestone 2 adoption targets are complete. An independent audit is recommended before larger-value use but is not a Milestone 2 completion gate. Use only small amounts while validation continues.

Deployment transaction IDs and acceptance gates are in the mainnet deployment record.

Native STX and supported SIP-010 payments share the same registered privacy identity and local scanner. Senders may enter a mainnet Stacks address or a BNS name. Privara shows and pins the resolved address; if the name changes owners before signing, submission stops for a fresh review. STX one-time addresses pay their own network fees, so no sponsor is required. For a full-balance move, the app estimates and subtracts that fee.

Each router is custodial for its deposited asset until settlement or withdrawal. Funds at a derived one-time address are self-custodial under the recipient's privacy seed. See the architecture guide and security threat model for full trust boundaries.

The reusable TypeScript SDK is published as @privara-stacks/sdk. The current stable release is 0.1.0.

npm install @privara-stacks/sdk

This release includes the SIP-018 intent core, stealth-address identity and recovery, local announcement scanning, BNSv2 recipient resolution, native-STX intent helpers, generic SIP-010 routing for sBTC and USDCx, and sponsored-spend preparation and validation. See the developer guide for integration details.

Requirements: Node.js 22 or later, npm, and Clarinet.

npm install
npm test
clarinet check
npm run app:dev

The React app starts at http://localhost:5173. Configure its relayer through app/.env; start from app/.env.example for development or app/.env.mainnet.example for mainnet.

Run the relayer locally with:

npm run relayer:serve

Never commit private keys, mnemonics, privacy seeds, backup passwords, sponsor keys, or production environment files.

The current repository passes 166 automated tests across 25 test files. Coverage includes SIP-018 digest parity, replay handling, sponsor-quote binding, backup-before-registration, safe import, malformed-announcement resilience, fresh-session recovery, router funding, relayer validation, durable duplicate handling, native STX routing and spending, multi-asset configuration, and sponsored spending.

Browser-wallet approval and real-sBTC mainnet acceptance have separate live evidence. The repository records informal technical feedback from Werner. This feedback was not conducted on behalf of Leather or Stacks, and was not a security audit or mainnet signoff. A separate non-team tester independently reproduced fresh-browser recovery, local scanning, and sponsored withdrawal. A future independent audit remains recommended for higher-value use; it is not part of the milestone acceptance criteria.

app/         Standalone Vite + React application
contracts/   Clarity contracts and SIP-010 trait
docs/        Protocol, security, deployment, operations, and reproduction guides
relayer/     Reference HTTP relayer and sponsor service
scripts/     Deployment, acceptance, scanning, and operational scripts
sdk/         Published TypeScript SDK
tests/       Contract, SDK, application-library, and relayer regression tests

Start with the documentation index. Important references:

• M2 stealth settlement specification
• Privacy model
• Sponsorship and fee model
• Security threat model
• Relayer API
• Mainnet deployment record
• Independent reproduction guide
• Usage and adoption evidence
• Demo guide and video

Privara is authored by Samuel Dahunsi under the Privara organization.