Trust, verified — not assumed.
A documented threat model, honest audit status, and cryptographic boundaries that hold even if every server is compromised.
Verification, in progress.
There is no completed third-party audit yet. Here is exactly what has been verified internally — and what still needs review.
No external audit — yet
No production mainnet funds should rely on un-audited code. Priority order: L1 contracts → Plonky3 circuits → TEE coprocessor → ICP canisters → scanner rules. Independent review happens before any mainnet value.
Foundry unit tests
- ComplianceRegistry state machines & holding periods
- DepositManager gate & token allowlist
- CoW settlement path with mock contract
- Merkle note helpers
End-to-end scripts
- Mix + TEE epoch proof flow (canister, L1, TEE)
- Epoch auto-close, proof upload, verify/finalize
- Negative epoch cases (desync, bad proofs)
- WASM size reports
Cryptographic self-checks
- Verifier runs the same Plonky3 UniConfig as the prover
- Golden tests pin the domain-hashed root encoding
- Desync paths halt instead of settling incorrectly
What is never trusted.
The single most important boundary: plaintext amounts exist only inside the TEE enclave. The canister never decrypts; L1 never sees amounts.
Amounts
Plaintext amounts exist only inside the TEE enclave, transiently. On-chain you see only opaque Poseidon commitments.
Note secrets
Secrets live only on your device (IndexedDB, encrypted). Loss of the keystore means permanent loss — no recovery.
Proof verification
Verifier canister checks every proof before any L1 call. Nullifiers are locked on canister and L1 — one transition only.
Root authenticity
Roots are domain-hashed (keccak256 over the Plonky3 root), golden-tested, and reconciled between indexer and L1.
Adversaries, anticipated.
External attackers, malicious relayer operators, TEE host adversaries, surveillance, and MEV — each with its mitigation.
Ciphertexts are only useful for protocol ops; the enclave is HTTP-only with no secret export; relayer pins the expected TEE identity. Trusted-party assumption today.
Replicated state, admin functions sign with canister ECDSA, L1 enforces onlyExecutor guards on lock → finalize → settle ordering.
Nullifiers locked on the canister and on L1 (lockPrivateIntent). A nullifier can only transition once.
Domain-hashed root encoding with golden tests; L1 addRoot callable only by the indexer canister; commitment count reconciliation.
9×31-bit limb encoding with strict tags, binding digests computed in-circuit, TEE verifies binding before returning results.
DepositManager gates on ComplianceRegistry; holding periods per source (KYC 1h, manual 24h, flagged 7d, frozen never).
CoW settlement via EIP-1271 (solver must fill at quote); vault methods execute state transitions that leak no amount info.
Secrets live in the user's encrypted store; no protocol-level recovery. Documented operational risk.
Responsible disclosure
Found a vulnerability? Tell us before anyone else.
How to report
- • Open an issue against the repository, or contact the maintainers directly
- • Include the affected component, impact, and a minimal reproduction
- • Give maintainers time to respond before any public disclosure
Scope
- • L1 contracts, Plonky3 circuits, TEE coprocessor, ICP canisters
- • Scanner rules and frontend wallet (WASM, keystore handling)
- • Proof soundness, state transitions, lock semantics, upgrade safety
Privacy you can verify.
Read the docs, inspect the code, check the threat model — then decide.