{
  "type": "failure-mode",
  "name": "Ignoring proof malleability in application logic",
  "slug": "ignoring-proof-malleability-in-application-logic",
  "section": {
    "id": "proof-systems",
    "number": "01",
    "title": "Choosing a proof system",
    "url": "https://zkpick.com/proof-systems/"
  },
  "url": "https://zkpick.com/proof-systems/failure-modes/ignoring-proof-malleability-in-application-logic/",
  "markdown": "https://zkpick.com/md/proof-systems/failure-modes/ignoring-proof-malleability-in-application-logic.md",
  "detail": "The application treats a proof or its hash as a unique identifier for deduplication, nonces or replay protection. Several deployed systems produce re-randomisable proofs, so a second valid proof of the same statement is trivially obtainable.",
  "mitigation": "Never derive uniqueness from proof bytes. Bind it to constrained in-circuit values such as nullifiers, and canonicalise encodings on deserialisation.",
  "relatedOptions": [],
  "updated": "2026-09-12",
  "version": "1.3",
  "canonical": "https://zkpick.com/proof-systems/failure-modes/ignoring-proof-malleability-in-application-logic/",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "authors": [
    "MarketComp"
  ]
}