Skip to content

Privacy model

Reveal only what the task requires.

Three capabilities that are easy to confuse. This page states exactly what each hides, from whom, and what it cannot do.

1. Screen privacy

What it is. A toggle that replaces values on your screen with a mask. Hides from: people looking at your display. Does not hide from: anyone else. The public chain, explorers and this site's own API responses are unchanged. It is labelled "screen privacy" everywhere and is never described as shielding.

2. Shielding through a cryptographic protocol

What it is. A protocol takes custody of tokens in a shared pool and records them as commitments. Spending inside the pool proves ownership without revealing which commitment is spent. Status: not configured. This house does not implement its own cryptography; shielding is enabled only through a reviewed adapter for an existing protocol.

What a pool hides

  • Which balance of a supported asset belongs to which address inside the protocol's pool
  • The amount and counterparty of a transfer made inside the pool

Who can still see it

  • You, through the protocol's client-side notes and viewing keys
  • Anyone you hand a viewing key or proof to
  • The protocol's rules and any compliance screening it applies at entry or exit

What remains observable

  • The public deposit that moves tokens into the pool and the address that sent it
  • The public withdrawal that moves tokens out and the address that receives them
  • Pool-level totals, fees, and timing patterns

Limitations

  • Hiding a number on this screen is not shielding; the public chain still shows the balance
  • Shielding depends on the specific protocol, its audit status and its anonymity set
  • Entry and exit transactions can be correlated by timing and amount

Rules for a real integration

  • Explain what is hidden, from whom, and what stays observable, using the protocol's own documentation.
  • Show fees and the public entry and exit implications before any signature.
  • Simulate every transaction, confirm chain id and contract addresses, request narrowly scoped approvals.
  • Report pending, confirmed, reverted and rejected from chain evidence.
  • Keep notes, viewing keys and proof material out of analytics and logs; follow the protocol's client-side storage and recovery requirements; never store secrets in plaintext localStorage.

3. Selective eligibility proofs

What it is. Proving one requirement, such as not being a U.S. person, to a verifier without handing over the documents behind it. Status: not configured.

  • The verifier learns that the requirement was satisfied, which issuer vouched for it and when the proof expires. That fact is a disclosure the verifier keeps.
  • A credential issuer still performed identity checks to issue the credential. Selective disclosure limits what is re-shared, not what was checked.
  • Unlinkability, revocation and freshness depend on the credential format and proof system. Nothing here implies universal anonymity.
  • Proofs are bound to this application, the session and the requirement, carry a random challenge, and are checked for freshness, expiry, replay and revocation. A wallet connection, a checkbox or a local flag never yields "verified".

Data separation

  • Public catalog data — the registry, served to everyone.
  • Public wallet observations — balances and transfers of an address you supply, fetched on request and not retained.
  • User preferences — watchlist, screen privacy, sample mode, last lookup, in this browser only.
  • Confidential proof material — never handled by this app today; a future adapter must keep it client-side under the protocol's rules.