Privacy
SEAL hides private balances and the asset and amount of internal private transfers. It does not make every blockchain action invisible or guarantee anonymity. This page defines the user-facing privacy boundary; the Security Model covers technical assumptions.
Privacy by action
| Action | Private | Public or potentially observable |
|---|---|---|
| Deposit | Spending keys and private record openings | Submitting wallet, token, amount, timing, public commitments and record hashes |
| Hold and earn | Individual SEAL balances, ownership and private records | Aggregate backing, lending market activity, public token and reserve data |
| Send and receive | Transferred asset, amount and private ownership information | Sender submitting address, timing, proof metadata, commitments, nullifiers and grouping; delivery-service metadata |
| Swap | Private input ownership and the returned SEAL record openings | DEX assets and amounts, route/call data, execution, public funded outputs, submitter and timing |
| Margin trade | SEAL note ownership and funding wallet connection that private funding aims to obscure | Margin/controller account addresses, collateral, debt, amounts, trades, health factors, liquidation and account reuse |
| Withdraw | Remaining SEAL balance and input record openings | Destination, withdrawn assets and amounts, submitter, timing and grouped payouts |
Deposits, withdrawals and timing
The public entry and exit can give observers clues about internal activity. Distinctive amounts, rare assets, short delays and a small number of plausible participants can make correlation easier.
An observer can compare timing and public metadata even without reading the private balance. More transactions do not automatically create more anonymity: repeated activity by the same party or activity known to a cooperating operator may add little uncertainty. SEAL does not report a guaranteed anonymity-set size.
Intent services and service metadata
An intent service can submit an authorized action without receiving your spending keys. This can avoid using your wallet as the onchain submitter, but does not guarantee anonymity. Intent services, archives, Google Drive and RPC providers can observe request timing, IP addresses, sizes and other service-specific metadata.
Direct wallet submission publicly associates that wallet with the action. Encrypted storage protects contents, not traffic metadata or availability.
Swaps
A swap interacts with public Uniswap markets and publicly funds returned assets. Keeping the result in SEAL does not conceal the swap execution. The amount, assets and route may help correlate inputs, outputs and other activity. See Swap for the user flow.
Margin trading
The current margin implementation uses public Aave accounts. Private funding aims to obscure the relationship between a funding wallet and a margin account; it does not hide that account's holdings, borrowed amounts, direction, adjustments or liquidation activity.
The controller and margin account are public identifiers. Reusing the account links its trades. Returning proceeds to private notes does not erase the position history. Public-wallet funding explicitly links the funding wallet.
No additional private position-state circuit exists in this version. Hiding positions or financial strategy would require a different architecture, not a change in website wording. See Margin Architecture.
Local proofs and trusted devices
New local passkey accounts generate their account keys randomly, independently of a wallet signature. WebAuthn PRF unlocks an encrypted copy of the account's encryption key after user verification, using the app's hostname as the relying-party ID. No assertion, PRF output or account backup is sent to a SEAL backup service. Passkey providers may synchronize the credential through their own services; that does not upload SEAL account state. Users who want a device-bound credential can use a compatible security key. A downloaded file also has an independent recovery-key path: possession of both the file and recovery key grants access.
This protection applies while the account is locked. It does not protect plaintext from a compromised device, extension or app script after unlock. Legacy wallet accounts retain their signature-derived keys; creating a separate passkey account does not automatically migrate their funds.
Privacy proofs and their private inputs are computed locally in the browser. A proving server does not need the private witness. The genuine app build, your device, browser access and cryptographic assumptions still matter. Anyone with access to the unlocked private account can read its accessible records.
The account app does not load analytics. The sandbox does not contact real relayers; service discovery runs only for the selected real deployment. Its response headers block framing, isolate it from sites that open it in a popup, and restrict resource embedding to the same origin. Authenticated session requests reject other origins, including sibling subdomains. These controls complement the browser's same-origin policy; they do not protect against malicious extensions, a compromised app build or scripts deliberately trusted by the app. Optional Google authorization loads Google's identity script and trusts that code. Custom RPC settings allow network access to the selected provider; the provider can observe those requests.
Save a backup, confirm recipient addresses independently, and read Risks & Security. Privacy does not guarantee financial or physical safety.