Skip to main content
This page covers runtime trust boundaries for integrators. For the user-facing security story — audit status, threat model, and what Cloak cannot do — see Security.

​
Trust boundaries

  • Program: verifies proofs, enforces nullifier uniqueness, validates roots, and applies transfer invariants.
  • Client SDK: derives keys, builds witness/proof inputs, and enforces registration paths by default.

​
Key controls

  • Viewing-key registration uses one-time nonce challenge + Ed25519 signature.
  • Identifier canonicalization prevents mismatched key mapping.

​
Program provenance

  • Deployed bytecode sha256 d0f68613a08d7e0913aea67d95f04598bc070911a0e84fedd43cc6bfa18e6cf6 (239,032 bytes), built from independently audited source.
  • Verifying key from the cloak-transaction-0.2.0 trusted-setup ceremony (sha256 d65073d44064ed3be10d79e52d60a06d6be6d6c01afcd5ce52cdfcfc97c5585d).
  • Upgrade authority: Squads multisig F6HWeX5i2KjYQag6wCtxzQXeGewv6vXZihZR3EWdRL7s (3-of-4, 1-hour time lock).
  • Hashes and the verification recipe: Release notes.

​
On-chain protections

  • Root membership checks against ring-buffered root history.
  • Nullifier PDA checks prevent double spend.
  • Mint-scoped PDA checks for pool/treasury/merkle isolation.
  • Swap state timeout + close paths for stuck settlement handling.

​
Compliance and privacy posture

  • Chain-note scanner flow is chain-native — history is reconstructed directly from on-chain data using the viewing key.
  • Registered viewing keys enable compliance export for authorized admin paths.
  • Client apps should never log raw keys, seed material, or decrypted note payloads.
  • Transaction signatures are public, but only log them when needed for support/debugging.
  • Rotate admin credentials and encryption keys under change control.
  • Monitor swap timeout/close frequency and root-staleness retries.