Contracts
The core privacy account and its backing vaults are separate from swap and margin integrations. Interfaces and execution rules are defined in the specification; deployment addresses must come from a verified deployment record, not a demo configuration.
Core account and verification
| Contract | Role |
|---|---|
PrivacyPool |
Commitments, nullifiers, independent asset shares, proof-authorized state transitions |
VerifierRegistry |
Immutable settlement, transfer and withdrawal verifier routes |
PlonkVerifierAdapter |
Canonical statement and proof format checks, with raw-verifier code identity |
ProtocolFees |
Capped rates, delayed increases and canonical swap adapter creation |
SealDepositAdapter |
Authorized token funding and deposit execution |
The pool is not a proxy. SEAL verification is fixed at deployment; a different proof system requires a new pool version and reviewed client release. See Security Model.
Aave and custody
AaveV3VaultFactory creates per-asset vaults with permanent backing selection. AaveV3Vault supplies eligible assets to Aave; IdleVault holds custody assets without lending. Asset shares do not authorize a margin account to borrow against pool backing.
Uniswap
SealSwapAdapter executes proof-bound approved canonical Uniswap V3 routes and atomically redeposits output and input change. SwapAdapterFactory participates in canonical adapter admission. Ordinary swaps allow up to three hops; native margin has a narrower direct-market requirement. See Native DeFi.
Margin extension
SealMarginAccount, SealMarginAdapter, SealPublicMarginAdapter and MarginFees are separately deployed and qualified extension contracts. Public and private adapters use different funding and controller identities. All supported actions are typed; the account does not expose arbitrary execution or an administrative sweep.
See Margin Architecture, Deployments and the deployment runbook. The extension is outside the frozen production source tree; its existence does not establish a production release.