Privacy Policy

This Privacy Policy is a draft. It has not been reviewed by counsel, it has not been adopted by the legal entity that will operate Privé, and it is not yet in force. We publish it now for transparency, so that the way the software handles information can be checked against a written description before anyone relies on it.

Two things follow. First, this document will change: the operating entity, its registered address, and the jurisdiction whose data-protection law governs it are placeholders pending the entity's formation and legal review, and the version that takes effect will name them and carry an effective date. Until then, references in this policy to "we," "us," and "our" mean the project team building Privé, and the data controller is [Operating Entity], of [Jurisdiction]. Second, the Privé contracts are not deployed on any network. No PUSD exists, no vault holds any reserve, no shielded pool has ever accepted a note, and no Privé contract address exists to publish, so nothing described below has yet happened to anyone.

Read every on-chain description here as a description of design, not of a live system: it explains what will be public, and what will stay private, once contracts are deployed and someone transacts. The descriptions of what the Site stores, what it never receives, and what your browser holds describe software that exists today and that you can read, and they are the part of this document you can hold us to regardless of its legal status.

Every blank still open in this draft is listed here, so you can see what is unresolved without hunting for it. Each appears in the text below as a bracketed name, and none of them has been filled in with a guess.

• [Operating Entity] — the entity that will operate Privé, adopt this policy and act as the data controller. It does not exist yet and is not named anywhere in this document.
• [Registered Address] — its registered address, and the postal address for formal data-protection correspondence.
• [Jurisdiction] — the jurisdiction whose data-protection law governs that entity, which also determines which of the rights described here you actually have.
• [Data Controller] — confirmation of who the controller is for each activity described here, which data-protection regime applies to it, whether an Article 27 representative or a data-protection officer is required, and whether legitimate interests or performance at your request is the better characterisation for support correspondence.
• [Support Retention Period] — the definite period after which support correspondence is deleted. Until it is fixed, the retention section describes our practice rather than a committed limit.
• [Supervisory Authority] — the lead data-protection authority you could complain to, which follows from the entity and its jurisdiction.
• [Transfer Mechanism] — the basis on which information may be processed outside your country: standard contractual clauses, an adequacy decision, or another basis.

This Privacy Policy applies to the Privé website and interface (the "Site"), including the informational pages, the whitepaper, the support form, and the client-side application (the "dApp") used to mint, redeem, shield, and transfer tokens.

It is worth being concrete about what the Site actually is, because the architecture is the privacy policy. The Site is a static frontend plus two serverless routes. One relays a support message you choose to send to our support inbox by email. The other asks a guardian service to accept the shielded pool's current association root on-chain, which is what keeps withdrawals working; it carries no user data at all. There is no application database, no user table, no session store, no server-side wallet index, and no server-side copy of anything you do in the dApp. Nothing else on the Site talks to a server of ours.

Privé is non-custodial and its on-chain contracts are designed to be immutable — no proxies, no upgrade path, and, once the one-time ramp wiring described under “Screening at the ramps, and the guardian’s limited role” has locked, no administrative withdrawal. The privacy consequence is direct: there is no account to create, nothing to log into, and no server-side record of your balances, your activity, or your credentials. Your wallet and your browser are where your data lives.

This policy does not govern the practices of independent third parties — your wallet software, the blockchain network, RPC providers, block explorers, the hosting platform, the email delivery provider, or the issuer of the reserve asset — except to describe what information reaches them and why. Their own terms and privacy policies apply to what they do with it.

This policy is provided for transparency. It is not legal, financial, or tax advice.

The full document is below, and the details matter. But if you read only one section, read this one.

• We have no accounts, no database, no analytics, and no cookies. The only information you can hand us is a support message you choose to send.
• Everything private happens in your browser. Zero-knowledge proofs are generated locally on your own device; your keys and note secrets never leave it, and no prover, relayer, or service of ours ever sees them.
• Everything else happens on a public blockchain, where it is permanent and visible to everyone — to us, to you, and to people who have never touched the Site.
• Shielding hides which note is yours and, inside the pool, how much moved and between whom. It does not hide that you shielded, how much you shielded, or that a private transfer happened. A private transfer is still a public transaction, sent from a public address that pays gas in the clear.
• Two boundaries we cannot close for you: your wallet and your RPC provider. Both see more about your activity than we do.
• Nothing recorded on-chain can be deleted, corrected, or hidden afterwards — by us, by you, or by anyone. The only real control is exercised before you sign.
• If you lose your wallet, or clear your browser's site data without a backup, shielded notes you created yourself cannot be recovered by anyone, including us. Export a backup.

Privé is built for Robinhood Chain (chain id 4663), a public EVM network, with Robinhood Chain Testnet (46630) wired as its testnet. Public blockchains are permanent and open by design: anyone can read them, anyone can copy them, and no entry can be edited or removed. When you transact you publish data to that ledger — not to us. We do not control the network, we run no privileged view of it, and we cannot remove, alter, or conceal anything recorded on it. Naming the chain is a statement of where the software is designed to run and nothing more; it implies no affiliation with, endorsement by, or partnership with any company.

Blockchain records cannot be deleted, rectified, redacted, anonymised, or expired. They are replicated across every node on the network and copied by anyone who wants a copy. That is not a policy choice we could reverse; it is the property that makes the ledger work. Once you sign, the record is out of everyone's hands, including ours and yours.

Public data is also analysable. Anyone — a chain-analytics firm, an exchange, a researcher, a stranger — can study the ledger and combine it with data from elsewhere: deposits and withdrawals at a venue that knows your name, a name-service record, an address you posted publicly, a donation page, an NFT you bought. Address clustering, timing analysis and amount matching are ordinary techniques, and they require no cooperation from us. Nothing in this policy, and nothing in the software, can prevent that kind of analysis of public data.

The contracts are not deployed, so none of the following has happened to anyone yet. It describes what will be permanently public, to everyone, once they are:

• Your wallet address and its complete transaction history, balances, and counterparties — for $PUSD and for every other asset that address has ever touched.
• Every mint: the address that deposited USDG, the amount, the block, and the timestamp. Minting is an ordinary public transaction and confers no privacy.
• Every redeem: the amount burned and the payout address that received USDG.
• Every ordinary $PUSD transfer — sender, recipient, amount, time. $PUSD is a public ERC-20; holding it is not private.
• Every shield: the note commitment, the leaf index assigned to it, the amount entering the pool, and the address that sent that amount in. The value you shield is public, even though who owns the resulting note is not.
• Every unshield: the amount leaving the pool, the address it is paid to, the nullifier that retires the note, and the pool and association roots it was proved against — all of it visible in the transaction's calldata, whether or not an event records it.
• Every private in-pool transfer, as an event: the root it was proved against, the nullifiers it spends, the two output commitments and the leaf indices they take, and the fee and fee-recipient fields bound into the proof — and, unavoidably, the address that submitted the transaction and paid its gas. What that transfer moved, and between whom, is not public; that it happened is.
• Every encrypted note memo: its ciphertext and the output commitment it is filed under. The ciphertext is readable only by the recipient's viewing key, but its existence, size, and timing are public.
• Contract addresses, the association roots the guardian accepts, the current blocklist state, and every gas fee, paid by an identifiable address.

Shielding is opt-in and separate. Minting $PUSD leaves you holding an ordinary public token; privacy begins only when you take the additional, proof-gated step of shielding. This section states, without softening, what that step buys and what it does not.

What the shielded pool is designed to hide, behind zero-knowledge proofs generated in your own browser, is: which note in the pool is yours, because the pool holds commitments and ownership is proved rather than revealed; your shielded balance, which is the sum of notes only your device can identify and which appears nowhere on-chain; the amount moved in a private in-pool transfer; and the link between the sender and the recipient of that transfer. That is a real and substantial set of protections, and it is what the cryptography actually buys.

It is not everything, and the gaps matter more than the guarantees when you are deciding what to do. Privé does not make you anonymous, and nothing in the software or in this policy should be read as a claim that shielded activity is untraceable. The following are true by construction, and you should assume any observer knows them:

• Entering and leaving the pool are public, with amounts. A shield publishes the value going in; an unshield publishes the value coming out and the address that receives it.
• A private transfer is still a public transaction. It emits an event and it is paid for with gas from a public address — so an observer sees that an address performed a private transfer at a given moment, even without seeing what moved.
• The submitting address is in the clear. The dApp submits your shielded transactions from your own connected wallet: there is no relayer standing between you and the network, which is good for custody and bad for network-level unlinkability.
• Fee fields are public. The transfer and unshield circuits bind a fee and a fee-recipient address into the proof; the shipped client always sends zero, but whatever it sends is visible on-chain.
• Timing and amounts link themselves. An unusual amount in, and the same unusual amount out minutes later, is trivially linkable regardless of any proof. So is unshielding to the address you shielded from.
• The anonymity set is currently tiny. Privacy in a shielded pool comes from the crowd you hide in, and there is no crowd yet — nothing is deployed, and an early pool with few participants and few notes offers correspondingly weak protection. Expect that to be the practical limit for a long time.
• A single note cannot be sent privately. The transfer circuit needs two real inputs, so a user holding exactly one note must first split it (for example by shielding a second time) before a private send is possible. This is a property of the design, not a bug, and it means your first private send may require an extra, publicly visible step.
• The pool protects $PUSD only. Every other asset in your wallet, including gas, is fully public and can be used to identify the address.

Withdrawing from the shielded pool proves two things at once: that your note is in the pool's commitment tree, and that it is also in an association set the guardian has accepted. This is a Privacy-Pools style model — privacy for ordinary users, with a membership claim at the boundary rather than an identity check.

The proof reveals membership, not identity. It does not disclose which note is yours, which leaf you are spending, or your balance; it demonstrates that the note you are spending belongs to a set derived from public on-chain data. Be exact about what that set is today. The design derives it from the on-chain commitment stream minus a published exclusion ledger, restricted to entries old enough to have matured, with exclusion entries carrying a coded category only — entries about commitments, not dossiers about people. That exclusion ledger does not exist yet. In the first version the association set is simply the pool's own commitment set, so the association root equals the current commitment root and the proof establishes nothing beyond membership of the pool itself. The practical consequence is worth knowing before you shield: every shield and every private transfer moves the root, and the notes created under a new root cannot be withdrawn until the guardian has accepted that root.

The consequence for you is worth stating in the same breath: an unshield reverts unless a root covering your note has already been accepted, so exit liveness depends on the guardian continuing to accept roots. Root acceptance is append-only and irrevocable, and redeem and unshield have no pause path — but a blocklisted payout address is refused at the redeem ramp, and a note not yet covered by an accepted root cannot be withdrawn until it is. We describe this here, in a privacy policy, because it is a design property that affects you; it is not a data-collection practice, and it gives no one visibility into your notes.

The ramps screen addresses. A mint screens the address of the caller; a redeem screens the payout address the funds would be sent to. If an address is on the guardian-owned on-chain blocklist, it cannot mint and it cannot receive a redeem payout, and the transaction is refused by the contract itself.

Be precise about what an address check is and is not. It is a comparison of a public blockchain address against a list of addresses held on-chain. It involves no name, no document, no date of birth, no photograph, no device fingerprint, and no third-party identity provider. It produces no profile, no score, and no record on our side, because we operate no database in which such a record could exist. The Site performs no KYC and asks you for no identity information as a condition of using the interface.

Two honest consequences. First, because the blocklist lives on-chain, whether a given address is on it is itself public information that anyone can read. Second, screening is deliberately placed at the legible boundaries — entry at the mint, payout at the redeem — precisely so the private middle can stay private. That is the posture of the whole design: privacy for ordinary users, not a tool for evading controls.

The blocklist belongs to a limited on-chain guardian role, held by a Safe multisig at deployment, and its powers are worth stating exactly rather than in summary. The guardian can pause entries — minting, shielding, and shielded transfers. It can append roots to the association set that gates unshielding, an action that is append-only, irrevocable, and applied with no plausibility check. And it owns the screening blocklist described above — an ownership the blocklist contract allows to be transferred to another party, so who controls that list is a thing to check on-chain rather than to assume. One further power exists and it exists only once: the mint and redeem ramps must be wired to the token and to the vault, by a guardian-only setter that permanently locks itself the first time it is called. Until it is called, the guardian could name an arbitrary minter or an arbitrary redeem ramp. Both locks are public state anyone can read, and our Terms describe the window in full.

Once that wiring has locked, the guardian cannot move, spend, or access user funds and it cannot mint; it cannot upgrade or alter contract logic, and it cannot pause exits — redeem and unshield have no pause path. But the route out is not unconditional and we will not describe it as one: a blocklisted payout address is refused at the redeem ramp, and an unshield reverts until a root covering the note has been accepted.

For this policy, what matters is what the role does not confer. The guardian has no view into your balances, your notes, your browser storage, your viewing key, or the contents of any proof. It acts on public addresses and public roots, on-chain, and it sees exactly what any other observer of the ledger sees — nothing more. It is set out here so that "immutable, holds nothing" is not misread as "no administrative capability exists at all."

$PRIVE is a token separate from $PUSD: an ecosystem, access and utility token planned to launch on PONS, with no date set and no contract deployed. Said in the same breath as its name, because it must never be read as a second dollar — $PRIVE is volatile and unbacked, it is not a stablecoin, it is not pegged, it is not redeemable for one dollar or for anything else, it pays no yield and no APY, it offers no staking return, revenue share or buyback, it gives holders no claim on protocol fees, on any treasury, or on the reserves designed to back $PUSD, and it can go to zero. No $PRIVE mechanism may ever make $PUSD's 1:1 USDG backing or its solvency depend on $PRIVE; every $PRIVE mechanism lives outside the immutable core.

For this policy the point is narrower: $PRIVE carries no privacy features of its own. The shielded pool described here is built for $PUSD. A $PRIVE balance, and every transfer of it, would be as public and as permanent as any other token on a public blockchain, and nothing written here about shielded notes, in-browser proofs, encrypted note secrets, or private transfers applies to it.

The Site handles no additional information about you because $PRIVE exists. We hold no allocation list, no whitelist, no presale registration, and no waiting list for it, and we have never asked anyone for personal data or funds in connection with it. Anyone collecting personal information, wallet addresses, or money for a $PRIVE sale, allocation, or whitelist is not us.

Most privacy policies reserve rights their authors intend to use later. This list is the opposite: it describes software you can read, and each line is a thing the code does not do.

• No accounts. There are no logins, usernames, passwords, or profiles, and nothing to sign into.
• No KYC or identity verification by the interface. We do not ask for your legal name, government ID, date of birth, nationality, or physical address as a condition of using the Site.
• No keys, ever. We never receive or store your private keys, seed phrase, recovery phrase, viewing key, spending key, or shielded note secrets. They are the spending authority for your funds and they never leave your device.
• No user database. There is no server that ingests or stores your wallet address, your balances, your transactions, or your usage. We could not produce a record of your activity if asked, because none exists on our side.
• No analytics or telemetry. No page-view counter, no product analytics SDK, no session replay, no heatmaps, no A/B testing tool, no error-reporting service that ships your data to a vendor.
• No advertising, no ad pixels, no tag manager, no cross-site tracking, no behavioural profiling, no data brokers. We do not sell or rent personal information, and there is nothing to sell.
• No third-party scripts on the page at all, and no fonts fetched from a font CDN — typefaces are self-hosted from our own origin at build time, so loading a page makes no request to any third party.
• No mailing list, no newsletter sign-up, no chat widget, no support ticketing SaaS.
• No fingerprinting. We do not probe your device, canvas, fonts, or hardware to build an identifier.
• No linkage of a wallet address to an email address. The support form does not know your wallet, and the dApp does not know your email; the only way the two ever meet is if you type one into the other.

There are a small number of ways information is handled in connection with the Site. Each is described precisely rather than generically.

Support form (optional). If you submit our support form, we handle only the fields you provide: your name (free text, up to 100 characters), your email address (up to 200 characters), a topic chosen from a fixed list (General, App issue, Mint / Redeem, Shielded balance, or Partnerships), and your message (free text, up to 4,000 characters). The message box is free-form, and its placeholder invites you to include a transaction hash or your wallet address if that helps us resolve a transaction-specific issue — so those details may reach us, but only because you typed them. The form warns you never to include your seed phrase or note secrets, and you should not; we will never ask for them. The form also carries a hidden anti-bot field, labelled "Company," which real users never see and never fill; it is a spam decoy, not personal data in normal use. Each submission is given a short random ticket ID of the form PRV-XXXXXX, generated at the moment of sending and stored nowhere but in the resulting email.

What happens to a support message. It is not written to a database — there is no database. It is composed into a single email and handed to our email delivery provider, which sends it to our support inbox with your address in the reply-to header so we can answer you directly. After that, it exists as email in an inbox and nowhere else on our side.

Wallet address. When you connect a wallet, your public address is handled entirely client-side: read from your wallet, displayed in the interface, used to namespace your local storage, and included in the on-chain reads and transactions your wallet performs. No server of ours receives or stores it. It reaches us only if you paste it into a support message — and it reaches your RPC provider whenever the app reads your balances or history, which is described under network exposure below.

Technical and log data. Like any website, serving pages necessarily exposes basic request metadata — IP address, user-agent, requested URL, timestamp — to the hosting platform that serves them, and to the blockchain RPC endpoints the app and your wallet contact. Our application code neither adds this metadata to any payload nor stores it; it is infrastructure-level information those providers see as a normal part of delivering the service, and they keep their own logs of it under their own policies.

The operator status request, and why we mention it. While the dashboard is open, it polls a read-only status route to work out whether a withdrawal will currently go through — an unshield reverts until the guardian has accepted an association root covering your note, and we would rather show you that than hand you a button that fails. The request is a GET carrying one parameter, the numeric chain id. It sends no address, no amount, no note, no identifier of any kind, and nothing derived from your keys, and it asks only about the operator, never about you. It is still a request to our hosting provider, so it appears in that provider's ordinary connection log with your IP address and a timestamp. What that log can show is that some visitor had the dashboard open; it cannot show which wallet, which note, or which action. Note that it is deliberately NOT fired by shielding, sending or withdrawing — it runs on a timer while the page is visible — so unlike the arrangement it replaces, the timing of these requests is not correlated with anything you did.

The shielded features need keys, and those keys are derived from your wallet rather than issued by us. The interface asks for two separate, purpose-bound EIP-712 typed-data signatures, and the split is deliberate.

The view signature unlocks reading. From it the app derives your viewing and encryption key — which can decrypt note memos addressed to you and read your own note store — and the key that encrypts that store at rest. It can see; it can never spend. The spend signature is requested separately and only when it is needed: to send or withdraw, and once per device to register your public receiving address. From it the app derives your spending key, uses it for that one operation, and drops it. Because the two are separate, unlocking your dashboard never carries the authority to move your funds, and a view signature captured by a lookalike site costs you privacy, not your balance.

The signatures, and every secret derived from them, are bearer secrets held only in the memory of your browser tab. They are never written to disk, never synced, and never transmitted to any server — ours or anyone's. They are dropped when you disconnect or switch account or network.

The derivation is deterministic: the same wallet, signing the same typed data, produces the same identity on any device. That is what lets you reach your notes from a second browser without any account. It is also the reason to be careful where you sign: anyone who obtains your view signature can read your shielded balance, and anyone who obtains your spend signature can move it. Only sign these requests on useprive.app.

Only standard EOA wallet signatures are accepted. Smart-wallet and passkey signatures (ERC-1271 / ERC-6492) are refused, because they are not reproducible across sessions and keys derived from them would be permanently unrecoverable. This is a fund-safety decision that also shapes which wallets can use the shielded features at all.

The dApp keeps data in your browser's localStorage, under keys prefixed "prive:", so your shielded activity survives a page reload. This data stays on your device. It is not synced to us, there is no server-side copy, and no backup of it exists anywhere unless you make one.

The sensitive parts are encrypted at rest with AES-256-GCM under a key derived from your wallet's view signature. The encryption is bound to your specific account and network, so a stored blob cannot be lifted to another account or chain, and the key itself lives only in your tab's memory and never touches disk. A blob that will not open with the right key fails loudly rather than being silently discarded, so a wrong key can never clobber good notes.

Because we hold nothing, there is nothing for us to restore. If your site data for useprive.app is cleared — by you, by a "clear cookies and site data" sweep, by a browser's cleanup of unused sites, by a private-window session ending, or by reinstalling the browser — the shielded note store goes with it.

Some of it can be rebuilt and some of it cannot, and the distinction is the important part. Notes you were paid by someone else are recoverable: the sender published that note's secrets on-chain, encrypted to your viewing key, so with the same wallet you can re-scan the memo channel and find them again. Notes you shielded yourself, and the change outputs of your own private sends, are different — their secrets were generated in your browser and were never published anywhere, in any form. If your store is gone and you kept no backup, those notes cannot be reconstructed by anyone: not by you, not by us, not by the guardian, not by anyone who ever operates this protocol. The value stays in the pool, unspendable, permanently.

The dApp therefore offers an export, which writes your note store to a JSON file on your device. Keep one, keep it somewhere you will still have after a laptop dies, and treat the file as sensitive: it cannot spend your notes on its own — spending still requires a fresh spend signature from your wallet — but anyone who reads it learns your entire private balance and history. Notes without the wallet are not spendable; the wallet without the notes cannot reconstruct what you shielded yourself. Keep both.

Specifically, the following may be stored in your browser:

• Shielded note store ("prive:notes:v1", namespaced per network and address) — your note secrets: value, blinding, asset, commitment, leaf index, and status. Encrypted at rest. This store holds no spending key; spending always requires a fresh spend signature from your wallet.
• Notifications store ("prive:notifs:v1") — per-wallet in-app notices, such as a "payment received" notice that can include an amount. Encrypted at rest under the same wallet-derived key, with its own separate encryption domain.
• Pending note-memo queue ("prive:pendingmemos") — encrypted note payloads waiting to be posted on-chain. Stored as they are, because the payload is already end-to-end encrypted to the recipient and the related commitment is already public, so nothing secret is exposed by keeping it.
• Your public receiving address — cached, encrypted, so that a device does not have to ask for a spend signature every time you unlock. It is public information; caching it is a convenience, not a secret.
• Wallet-connection state (keys prefixed "wagmi.") — standard wallet-library data remembering which connector you last used, so your session survives a reload. It stores connection and account details, never private keys.
• Nothing else. There is no cookie, no server-set identifier, and no cross-site storage of any kind. Site data is per-origin, so only code served from useprive.app can read it — which is why we ship no third-party scripts on the page.

This is the part of the system we cannot fix for you, so it gets its own section. Even with perfect on-chain privacy, the act of using a website reveals things at the network layer, and the most significant observer is not us.

• Your RPC provider is a real privacy boundary. To show balances and submit transactions, the app and your wallet contact blockchain RPC endpoints. Those endpoints see your IP address and the calls you make — and several of those calls name your address directly: reading your $PUSD balance, and scanning transfer logs filtered on your address to build your history. A provider that logs requests can therefore associate your IP with your wallet address. We do not operate these endpoints, we cannot see what they log, and no design choice inside the app closes this gap. If it matters to you, put a VPN, Tor, or your own node in front of it.
• Note discovery is deliberately built the other way. To find notes paid to you, the client downloads every note memo on the channel and trial-decrypts them locally, rather than asking a server which ones are yours. The RPC provider learns that you scanned; it does not learn which memo you could read. This costs bandwidth and buys privacy, on purpose.
• Proving is entirely local. The circuits are served from our own origin as static files and the proof is computed in your browser, on your device. No proving service, relayer, or co-signer acts for you; no witness, note secret, or key is transmitted anywhere. What leaves your device is the finished proof and its public inputs, which is exactly what goes on-chain.
• Your wallet sees everything. It holds your keys, sees every address, amount and signature request, may use its own RPC endpoint rather than ours, and may run its own telemetry. It is the most privileged observer of your activity, and its privacy policy — not ours — governs what it does with that.
• Block-explorer links leak on click. "View on Blockscout" links open the explorer with an address or transaction hash in the URL, so the explorer sees your IP together with the thing you looked up. The Site sends a referrer policy that discloses only our origin, never the page path — but the link itself is the disclosure, and it only happens if you click.
• The page talks to a short, fixed list of hosts: the Robinhood Chain RPC endpoints, the email API used by the support route, and the endpoints the Coinbase Wallet connector requires. There is no analytics host, no advertising host, no font host, and no CDN anywhere on it. We publish a content-security policy enumerating exactly that list; it currently ships in report-only mode, so it records violations rather than blocking them, and until it is enforced the guarantee rests on what the code does not contain rather than on the browser refusing to load anything else.

Using the Site involves a small number of independent third parties. We do not control them, their own privacy policies govern what they receive, and naming them here is factual — it implies no affiliation with, sponsorship by, endorsement from, or partnership with any of them.

We do not sell or rent personal information to anyone, and we share it only where it is necessary to perform a function you asked for.

• Wallet providers (MetaMask, Coinbase Wallet, Phantom). They custody your keys and produce your signatures, and they see your addresses, balances and every request the app makes of them. Coinbase Wallet is configured to allow only standard external accounts, because passkey-based smart-wallet signatures cannot safely derive a recoverable shielded identity.
• RPC providers. The public Robinhood Chain endpoints, a public node service used as failover, and any commercial endpoint configured for the deployment. They see the requesting IP address and the contents of each call, including calls that name your wallet address.
• Hosting platform (Vercel). It serves the Site and runs the two serverless routes, and — like any host — sees request metadata such as IP address, user-agent, and requested path, and keeps its own logs under its own retention policy.
• Email delivery (Resend). When you submit the support form, its contents — your name, email address, topic, message and ticket ID — are relayed through Resend's API to reach our inbox. This is the only path by which anything you type on the Site leaves to a third party.
• Block explorer (Blockscout, robinhoodchain.blockscout.com). Contacted only if you click a link. It then sees your IP and whatever address or transaction you opened.
• The reserve asset issuer. $PUSD is designed to be backed 1:1 by USDG, the Global Dollar, issued by Paxos. Paxos sees the public ledger exactly as any other observer does, and it retains contract-level controls over USDG balances, including the ability to freeze and to wipe them; those are properties of the reserve asset and are described in our Terms. No relationship, endorsement or affiliation is implied by naming the issuer of a token the protocol is designed to hold.
• Community channels (for example Telegram and X). We link to them. If you visit, you leave the Site and their operators' policies apply; the Site sends them nothing programmatically.

Our application sets no cookies. Not a session cookie, not a preference cookie, not a consent cookie, not an analytics or advertising cookie, not a first-party cookie of any kind. There is no consent banner because there is nothing to consent to; if you ever see a cookie banner on this Site, something is wrong and we would like to hear about it.

We embed no analytics, telemetry, session-replay, heatmap, A/B testing or advertising tooling, and no third-party script or tracking pixel of any sort runs on the page. Typefaces are self-hosted from our own origin, so rendering a page contacts no font CDN.

The only client-side persistence our code uses is browser localStorage, listed in "Data stored in your own browser" above. It exists to make the shielded application work across reloads, it is readable only by our own origin, it is never transmitted, and it cannot follow you to another site.

Two honest caveats, outside our application. Our hosting provider may set a strictly necessary cookie of its own to route or protect traffic, and infrastructure providers keep server-side request logs as a normal part of operating their services. And your wallet extension, and any site you navigate to from here, set whatever they set under their own policies.

Because the Site handles so little, both the purposes and the legal analysis are correspondingly narrow.

Where a data-protection regime such as the UK or EU GDPR applies to you, the legal bases are expected to be as follows, subject to counsel's review and to the operating entity being named. We handle the contents of a support message on the basis of our legitimate interest in answering people who write to us — and, in substance, at your request, since the processing happens only because you chose to contact us. We handle the technical request metadata our infrastructure necessarily sees on the basis of our legitimate interest in delivering and securing the Site, including the anti-spam measures described above. We rely on no consent for storage on your device, because we set no cookies and the localStorage described in this policy is strictly necessary to provide the function you asked for. We carry out no automated decision-making that produces legal or similarly significant effects, and we build no profiles.

On-chain activity is not processing we carry out. When you sign a transaction you publish it to a public network yourself; we neither collect it nor determine what becomes of it, and no legal basis of ours could make that record disappear.

In practice, the limited information described in this policy is used only to:

• Answer you. Support-form contents are used to receive, understand and reply to your enquiry, and to reference your ticket ID.
• Operate the interface in your browser. Your connected address and any signature you approve are used client-side to display balances, decrypt and organise your local data, and construct the reads and transactions you initiate.
• Show you whether a withdrawal will go through. A read-only status request reports the root operator's health so the dashboard can say why an unshield is unavailable and when it is expected to become available. It asks for nothing about you.
• Deliver and secure the Site. Request metadata seen by our infrastructure providers is used by them to serve pages, route traffic and resist abuse.
• Stop spam. The hidden honeypot field, the request-size cap, the field-length limits, and a same-origin check on the support route exist to filter automated submissions. Nothing from them is used to profile you.

We do not sell personal information, we do not share it for advertising or profiling, and we do not disclose it to data brokers.

Support-form contents are disclosed to our email delivery provider strictly to deliver your message, as described above. Technical request metadata is inherently visible to the infrastructure providers that serve the Site. Beyond those operational disclosures, we do not routinely share information — and in most cases there is nothing to share, because we hold no accounts, balances, or activity records.

We may disclose the limited information we do hold — in practice, support correspondence — if we reasonably believe disclosure is required to comply with a valid legal obligation, to enforce our terms, or to protect the rights, safety or security of users, the public, or the project. Where we are permitted to tell you about such a request, we will try to.

The practical limit is worth stating for anyone considering asking. We cannot produce what we do not have. A request for a named user's transaction history, balances, keys, note secrets, or shielded activity cannot be answered by us, because no such record exists on our side; the public parts of it are on a public ledger that anyone, including the requester, can read without our help, and the private parts exist only inside a user's own browser. Nothing in this policy affects that public ledger: on-chain data is disclosed to the entire network by the design of the blockchain, not by us.

Support correspondence exists as email in our inbox. We keep it for as long as reasonably needed to handle your request and for ordinary record-keeping, and then delete it. A definite retention period will be stated here as [Support Retention Period] once counsel has fixed it.

We retain nothing else. There is no user record, no activity log, no wallet index, and no analytics store to age out, because none was ever created.

Data in your browser is retained on your device until you or your browser clear it. It is under your control, not ours, and we can neither read it nor delete it for you.

Infrastructure logs are held by the hosting, RPC and email providers under their own retention schedules, which we do not set and cannot shorten on your behalf.

On-chain data is permanent. It is retained by every node on the network, forever, and no retention policy — ours or anyone's — applies to it.

Our security posture starts by minimising what can be lost. The Site holds no accounts, no keys, and no central store of user activity, so there is no trove of personal data for an attacker to reach through us. That is a stronger protection than any promise we could make about how well we guard a database.

What we do run is hardened in the ordinary ways: content is served over TLS with strict transport security; the browser is sent a content-security policy — which currently ships in report-only mode, so it records violations rather than blocking them — along with frame and MIME-type protections, a restrictive permissions policy, and a referrer policy that discloses only our origin; and the support route enforces a same-origin check, a request-size cap, field-length limits and a honeypot before it will relay anything. On your device, note secrets and notifications are sealed with AES-256-GCM under a wallet-derived key that is bound to your account and network and never written to disk.

The limits deserve equal prominence. No method of transmission or storage is perfectly secure. No external audit of this software has been performed, and you should not read any statement here as an assurance that the code is free of defects. The contracts are designed to be immutable, which means a defect in them could not be patched. Your browser is a shared environment: a malicious extension, a compromised device, or a phishing site that captures your view or spend signature can defeat everything described above, and none of it is something we can detect or prevent from our side.

Much of your protection therefore rests with you. Safeguard your wallet, your seed phrase and your device. Never share your seed phrase or note secrets with anyone, including anyone claiming to be from support — we will never ask for them, and anyone who does is impersonating us.

Because we hold very little, most control rests directly with you rather than being something you have to request from us. Before the list, the honest half of the picture.

Rights of erasure and rectification are real rights, and they stop at the edge of a blockchain. If you shield an amount, unshield to an address, or send an ordinary transfer, that record is written to a ledger replicated across every node on the network. It cannot be deleted, corrected, redacted, anonymised, or made to expire — not by us, not by the guardian, not by the network's operators, and not by you. There is no one on whom such a request could be served, because there is no one who could carry it out.

That is not a refusal, and we are not hiding behind it. We would rather say plainly that a request to erase on-chain data is impossible for anyone to satisfy than let you believe it is a request we might grant. The same applies to an access request for on-chain data: the ledger is already public and you can read all of it without us.

The same limit runs in the other direction for what is in your browser. We cannot reach it, so we cannot copy it for you, correct it for you, or delete it for you. You already hold it, and your browser's own controls are the only mechanism. The practical consequence is worth internalising: with a public ledger, privacy is decided before you sign, not afterwards.

Within those limits, here is what you can do and what you can ask of us:

• You can simply not contact us. Providing a name, email and message is entirely voluntary and happens only if you choose to write.
• You can decline the shielded features and use only the public token, in which case no signature is requested and no shielded data is written to your browser at all.
• You can disconnect your wallet at any time, which drops the in-memory shielded identity for that session.
• You can clear the data stored in your browser at any time through your browser's site-data controls. Export a backup first — clearing destroys note secrets that no one can regenerate.
• You can export your note store to a file at any time, which is your portability right exercised directly, without asking anyone.
• For the information we actually hold — your support correspondence — you may ask us for a copy, ask us to correct it, or ask us to delete it, and you may object to our handling of it. Write to support@useprive.app from the address you used, which is in practice how we will verify the request. We will respond within the period required by applicable law and we charge nothing for it.
• If you are in a jurisdiction with a data-protection authority, you may complain to it. The lead supervisory authority will be named here as [Supervisory Authority] once the operating entity and its jurisdiction are fixed.

None of this is legal advice, and none of it is a way to hide anything from anyone entitled to see it. It is the ordinary operational hygiene that decides whether the privacy the protocol is designed to offer actually reaches you.

• Export your note backup, and store it somewhere you will still have after a device fails. Treat the file as sensitive: it reveals your full private balance to anyone who reads it, even though it cannot spend on its own.
• Assume your RPC provider can link your IP address to your wallet address. If that link matters, use a VPN, Tor, or your own node — and remember your wallet may use its own endpoint regardless of what the Site uses.
• Do not unshield to the address you shielded from. Doing so links the two ends yourself, and no proof can undo it.
• Let time pass, and vary amounts. A distinctive amount in and the same distinctive amount out a few minutes later is linkable by anyone with a block explorer, no matter how good the cryptography in between.
• Remember what is already linked. An address funded from a venue that knows your identity is associated with you at that venue, and shielding afterwards does not change what was already recorded.
• Sign only on useprive.app. Your view signature reveals your private balance to whoever holds it; your spend signature can move it. Never approve either on a lookalike domain, and never paste a signature, a note secret, or a seed phrase into a support message or a chat.
• Keep both halves. The wallet alone cannot reconstruct notes you shielded yourself; the backup file alone cannot spend them. Losing either one is recoverable, losing both is not.
• If you hold exactly one note, expect to split it before you can send privately, and plan that step rather than being surprised by it.

The Site is reachable from many countries, and the third-party infrastructure that delivers it — hosting, RPC endpoints and the email relay — may process technical data, and in the case of a support message its contents, in jurisdictions other than your own, including the United States. Data-protection law in those places may differ from the law where you live.

By using the Site you understand that the limited information described in this policy may be processed outside your country. We aim to handle it consistently with the principles described here wherever it is processed. The transfer mechanism will be stated here as [Transfer Mechanism] once the operating entity, its jurisdiction and its processors are fixed.

Blockchain data is a special case, and not one any transfer mechanism addresses. A public ledger is replicated globally by every node that chooses to run one; when you broadcast a transaction it is distributed worldwide within seconds, by design, to parties none of us select or contract with. That is not a transfer we make on your behalf and it is not one we could restrict.

The Site is not directed to children, and it is not intended for anyone under 18 (or the age of majority where you live, if that is higher). We do not knowingly collect information from children, and there is no account creation through which we could.

If you believe a minor has sent us information through the support form, contact us and we will delete the correspondence.

We may update this Privacy Policy to reflect changes in how the Site works or in what the law requires. When we do, we will revise the "Last updated" date at the top of the page, and the first version that takes effect will carry an effective date and name the operating entity.

Where a change is material — a new category of information handled, a new third party receiving it, or a new purpose — we will describe the change rather than quietly restating the document. Your continued use of the Site after an update means you have had the opportunity to review the current version. We would rather you re-read it than assume it still says what it said.

For questions about this Privacy Policy, or about how information is handled in connection with the Site, write to support@useprive.app or use the support form. If you are exercising a data-protection right, say so in the message and write from the address the correspondence relates to.

This section will name [Operating Entity] at [Registered Address], and its data-protection representative or officer if one is required.

One thing that will never change: we will never ask for your seed phrase or your note secrets, and no one from support will ever ask you to sign a message, approve a transaction, or send a signature. The only place a signature is ever requested is the app itself, at useprive.app. Never include a seed phrase, a note secret, or a signature in a message to us or to anyone claiming to be us.