Security & trust
A concrete threat model matters more than an absolute privacy claim.
Protocol behavior is proposed. This release is an interface preview; no funds or wallet signatures are accepted.
Security objectives
Only a valid wallet-authorized action should change spendable state. Proofs should enforce conservation of value, correct recipient binding, note membership, and both forms of replay protection. Viewing material alone must not authorize a transfer.
These are intended invariants. Jammer has no published protocol audit or deployed cryptographic implementation in this preview.
Visibility matrix
| Operation | Public boundary | Privacy objective |
|---|---|---|
| Deposit | Funding address, asset, amount | Subsequent private ownership transitions |
| Internal transfer | Proof, nullifiers, commitments | Sender–recipient relationship and value |
| Withdrawal | Destination, asset, amount | Relationship to prior private notes |
| External swap | Venue, assets, amounts | Ownership of private inputs and outputs |
| Hosted proxy | Potentially viewing data and metadata | Spending remains wallet-authorized |
Residual risks
- Timing and amount correlation at pool entry and exit.
- Small or fragmented anonymity sets.
- Metadata captured by RPCs, relayers, browsers, or network providers.
- Compromised wallets, devices, signing prompts, or viewing keys.
- Circuit defects, verifier mismatch, token behavior, and contract vulnerabilities.
- Upgrade authority, screening censorship, and infrastructure downtime.
Release requirements
A production release needs independent audits, public findings and remediation, reproducible artifacts, recovery procedures, deployment verification, and a defined vulnerability-reporting channel. Until those exist, no statement here should be read as a security certification.