Security model
Murk is designed so that your funds are safe even if everything except the chain and your keys is hostile.
The two invariants
- Solvency — for every token, the pool's vault balance always equals the sum of the outstanding private notes. The pool can pay out exactly what's owed, no more, no less. It's enforced at every step: deposits add value and a note together; spends conserve value inside the ZK proof; withdrawals debit exactly the proof-bound amount.
- Exclusive control — a note can only be spent by whoever knows the secret behind its owner key, and only once (the nullifier is recorded on first spend).
What stops the obvious attacks
| Attack | Why it fails |
|---|---|
| Double-spend a note | The nullifier record can only be created once; a second spend reverts. |
| Forge value from nothing | The ZK proof enforces conservation; the on-chain verifier rejects malformed public inputs. |
| Spend someone else's note | Spending requires the secret behind the owner key — a hash pre-image you can't fake. |
| Relayer steals or redirects | Destination, amount, and fee are fixed inside the verified proof; the relayer only submits. |
| Forge a note ciphertext | The wallet decrypts and re-commits — a garbage blob fails the commitment check and is ignored. |
| Read another user's balance | Notes decrypt only under their owner's viewing key; nothing cross-reads. |
Residual, non-custodial levers
Some powers exist but cannot take your funds:
- An admin pause switch can halt new activity (a liveness control), but can't spend your notes or drain the vault.
- Fees are bounded on-chain, so a misbehaving fee authority can't set a fee near your balance to strand you.
- The program upgrade authority is the ultimate trust root — it is held by a Squads multisig.
Your part
The strongest protocol can't protect against leaked keys or careless habits. Keep your wallet secure, use auto-lock on shared machines, verify the site domain before signing, and follow the privacy hygiene in How privacy works.