seal. Docs Try the sandbox ↗
Mainnet is not yet live. Explore with demo funds or test tokens. Review status ↗

Architecture

SEAL separates private note ownership from public asset custody. One PrivacyPool contract records commitments, roots and nullifiers for all registered assets. Each asset has an immutable vault and independent share accounting. Configured Ethereum and Base lending assets use Aave V3; IdleVault supports custody assets.

flowchart LR
    W[Wallet and local prover] --> P[PrivacyPool]
    W <--> A[Encrypted archive]
    W --> R[Optional relayer]
    R --> P
    P --> V[VerifierRegistry]
    V --> A1[IProofVerifier adapters]
    A1 --> G[Current PLONK verifiers]
    P <--> B[Per-asset vault]
    B <--> L[Aave V3]

The private account model

Holding and earning use private asset-share notes. Transfers change note ownership without moving backing. Swaps execute a proof-bound public Uniswap action and create private output notes. Margin funding exits to a separate public Aave account with a signed controller action, then can settle proceeds back into notes.

Private balance ownership is distinct from public DeFi execution. See Native DeFi, Margin Architecture and the Security Model.

Components

Component Responsibility
PrivacyPool Note transitions, nullifiers, asset shares, fees and recovery state
VerifierRegistry Immutable operation routes fixed at deployment
PlonkVerifierAdapter Current proof-format boundary between the pool and PLONK verifier
AaveV3VaultFactory Creation of immutable Aave or custody vaults
SealSwapAdapter Proof-authorized Uniswap V3 execution with at most three hops
SDK and browser prover Keys, encrypted records, indexing, witnesses and local proofs
Archive and intent service Encrypted record availability and optional transaction submission

State and accounting

The encrypted account file stores the active monetary notes, saved positions and a private account checkpoint. The frontend renders this state immediately after decryption. A background query checks whether the checkpoint nullifier is spent. An unexpected spend stops private actions and asks the user to restore the latest account file or synchronize Google Drive. Incoming notes, live prices, yield and liquidations have separate discovery and refresh paths.

Every owner-authorized private action spends one account checkpoint and inserts one successor atomically with its financial effects. A checkpoint commits to the account owner, a private revision and fresh randomness. Its proof hides which earlier commitment it consumes. A one-use initialization marker prevents duplicate account histories. No account JSON or encrypted account snapshot is stored on-chain.

The immutable registry has four circuits: settlement, transfer, withdrawal and an account-only action. Monetary proofs have 71 public fields; account-only proofs have 11. Self-deposits and unfunded private margin use the account-only proof. Public margin exposes a controller revision counter. The SDK binds the checkpoint update into signed deposit and private-margin authorizations.

The append only Merkle forest supports depth 32. The pool reserves space for an entire output batch before insertion. If the active epoch lacks room, a new epoch begins; earlier roots remain valid. Each input carries its own membership path.

A proof consumes up to eight notes across assets and epochs. Settlement and transfer change private ownership without moving backing. Withdrawal redeems each selected asset and creates private change. Per-asset conservation prevents one token's shares from paying another token's obligation.

Aave yield changes redemption value without rewriting notes. Performance fees apply to eligible gains above the adjusted loss-recovery baseline and start at zero, with an immutable 10% cap. Custody assets have no lending fee. The specification defines exact accounting and public signals.

A fixed ProtocolFees controller manages a default yield rate, individual asset overrides, deposit, withdrawal and two swap rates. Increases require fourteen days of notice; decreases apply immediately. Fees defines caps, guardian accounting and the launch commitment.

Authority and recovery

The pool and asset vaults are not proxy-upgradeable. One immutable guardian Safe administers the protocol and receives its fees. The pool has no administrative pause. No governance account can replace verification. An error in the fixed verifier can still compromise funds or exits. Exits also depend on token restrictions and liquidity.

The guardian cannot force asset recovery or transfer user backing. Lending pauses and insufficient upstream liquidity can still prevent withdrawals.

The fixed verifier uses PLONK and the tree uses Poseidon. The current construction is not post quantum secure. Guardian signers can change through the Safe’s existing quorum, while its address remains fixed. Assets can be added but cannot be removed or assigned a replacement vault.