Security Model
SEAL is for demonstration funds only. There is no independent security audit. Read the current security review before using the sandbox.
Keep control of your account
Your browser needs the private note openings and account keys to spend. Export an encrypted backup, keep its recovery method separately, and test a restore on another device. Public onchain commitments cannot reconstruct missing openings. An unlocked device and the genuine app site remain trusted.
A seal. checksum detects accidental address changes, but anyone can create a checksummed address. Confirm the recipient's full address through a trusted channel before sending. A private transfer cannot be reversed after confirmation.
Local passkey encryption boundary
The browser requests a credential with mandatory user verification and PRF support, using the exact current hostname as the relying-party ID. Each unlock has a fresh challenge. The client validates the returned origin, challenge, credential ID, relying-party hash and presence/verification flags before deriving a nonextractable AES-GCM wrapping key through domain-separated HKDF-SHA256. Authenticated key wrapping, rather than a server-side login session, controls decryption. The trusted browser/authenticator implements WebAuthn; SEAL does not send assertions to a server or use them to authorize onchain spending.
Random account keys and fresh encryption nonces remain independent of PRF output. Both a passkey wrapper and a separately generated 256-bit recovery-code wrapper protect the vault key. Header identity and unlock parameters are authenticated. The self-contained file contains encrypted multichain state; local IndexedDB holds encrypted state and access metadata, without a remembered unwrapped key for passkey accounts. The recovery code must be stored separately by the user. Legacy wallet and Google modes retain their existing recovery mechanisms.
WebAuthn relying-party IDs permit eligible subdomains to request credentials for their parent domain. Host the private app on a stable dedicated hostname and never delegate any hostname beneath that relying-party ID to untrusted content or users. Client-side origin checks do not stop a malicious eligible subdomain from making its own WebAuthn requests. Exact-host selection avoids unnecessarily broad parent-domain scope but does not alter this WebAuthn rule. A domain migration needs the portable file and recovery key, or access to the original origin. WebAuthn relying-party scope and PRF
Replacing a passkey does not revoke old exported copies or rotate account spending keys. Protecting locked storage does not protect secrets from app-origin script compromise, malicious extensions or device compromise during unlock. Native passkey providers and real hardware/browser combinations require release qualification separately from virtual-authenticator tests.
What remains visible
Deposits, withdrawals, swaps, public margin positions, transaction senders and transaction timing are visible onchain. Private proofs publish input kinds, roots, nullifiers, output commitments and the number of notes grouped in a transaction. An intent service or archive may observe request timing and network information. These observations can link activity even when note values and owners are hidden.
Proofs may include a Unix expiration time. A nonzero value stops the proof at that block timestamp; zero means no proof expiration. Transaction deadlines, quote expiry, chain confirmation and available liquidity are separate limits. A successful proof does not ensure a withdrawal can redeem an impaired asset.
Contract and backing risks
Configured lending assets depend on Aave reserves, liquidity, oracle behavior and token issuers. The guardian can register assets, manage swap routes, schedule fees within caps and spend earned fees. The guardian is the immutable fee recipient. It cannot pause pool assets, force recovery or transfer user backing. External token and lending restrictions can still affect withdrawals.
The proof verifier is fixed when a pool is deployed. A faulty verifier could allow an invalid spend or prevent valid exits. The exact proof system and production authorities still need independent review. Fees explains capped rates and notice periods; legal and risk information covers additional limits.
Margin trust model
The extension trusts Aave reserve configuration, oracle prices, debt accrual and liquidation behavior, plus canonical Uniswap pool execution and external liquidity. Controllers sign typed, nonce- and deadline-bound actions. Every private action also requires an owner-bound account checkpoint transition, whose hash is covered by the signature. Funded actions include that transition in the withdrawal proof; unfunded management actions use the standalone account proof. Execution and checkpoint advancement are atomic.
Flash and swap callbacks must authenticate the active request and canonical pool. Amount/debt/slippage/fee bounds and signed post-action health minimums limit authorized execution. They do not prevent future liquidation, MEV within bounds, delayed inclusion or lack of liquidity. Rescue add-collateral and repay actions do not enforce the action health floor.
The pool and backing vaults delegate no borrowing power to margin accounts. Account-level isolation is covered by regression checks, but does not constitute a formal proof or prevent systemic Aave supplier loss. Shared-account collateral remains exposed to that account's liquidation.
Private funding aims to obscure the funding-wallet relationship. Account/controller addresses, position state, debt, health, execution and liquidation remain public; account reuse links trades. Controller keys are random encrypted account records, not recoverable from wallet seed alone.
See Margin Architecture and the specification security properties.
Canonical user guidance
The Privacy guide contains the user action table and service/timing limits. Risks & Security, Margin Risk and Backup & Recovery cover the corresponding user decisions. Audits is the canonical review-status page.