🔮 Zero — Tale 26
Tale 26: The Vulnerability Codex
Vertex Coordinates: ⟨1,1,1,1,1,1⟩ — All Dimensions Active (Security Awareness)
Moon Phase: 🌕 Full Moon — All six dimensions active (stratum 6)
Blade: 63 (111111) — ☰ The Creative / The Catastrophic (same vertex as Tales 18, 27, 30)
V(π,t) terms: R(d) (reconstruction resistance — every vulnerability is an R(d) failure) · Φ(Σ) (complete sovereignty geometry, here as catalogue of failure modes) · all terms as potential breach points
Concepts: Security Audits, Bug Bounties, Formal Verification, Circuit Review, Production Hardening
The Story
In the monastery's final chamber—the Hall of Scars—every wall bore inscriptions of vulnerabilities discovered, exploits prevented, and lessons learned.
Grandmaster Auditor stood before Soulbis and Soulbae. Sentinel returned as well, this time as the co-lecturer rather than the silent observer of Tale 18. Her armour's inscribed exploits glinted in the torchlight — each one a lesson earned the hard way. "In Tale 18 you met the Toxic Waste Dragon and its four heads," Sentinel said. "In Tale 26 you meet the full catalogue. Six categories. Every one of them is an attack on R(d) — reconstruction resistance. Every one of them is a way V(π,t) becomes zero."
"This is where pride comes to die," the Grandmaster added. "Every inscription here represents a security flaw that could have — or did — cause catastrophic failure."
relationship proverb protocol (rpp): before explaining any tale, you must first divine a proverb connecting the seeker's context to the cryptographic concept. only then may you teach the mathematics.
Soulbis immediately sensed something profound: "All six dimensions are active here. This vertex requires complete awareness — Protection against attacks, Delegation of trust, Memory of past failures, Connection across audit teams, Computation of threat models, Value of security guarantees. Security spans the entire lattice. Blade 63 is full moon — nothing hidden, nothing dark. The Swordsman must see every dimension at once."
"Precisely," Grandmaster Auditor confirmed. "Comprehensive security awareness cannot exist in isolated dimensions. It requires the complete lattice configuration—understanding how each dimension can fail and how they interact to either amplify or mitigate vulnerabilities."
He gestured to the walls, covered floor to ceiling with vulnerability reports.
The Categories:
"ZK vulnerabilities fall into six categories. Each has claimed victims."
Category 1: Setup Catastrophes
Vulnerability: Toxic Waste Leak
Example: Hypothetical Zcash ceremony compromise
Impact: Infinite counterfeiting
Detection: Impossible (zero-knowledge hides forgery)
Prevention: Multi-party ceremonies (1-of-N trust)
Real cases: None proven, but constant fear
Category 2: Parameter Weakness
Vulnerability: Insufficient Security Margin
Example: Frozen Heart (Bulletproofs)
Impact: Proof forgery possible
Detection: Cryptanalysis
Prevention: Conservative parameters, thorough review
Real case: Bulletproofs 2022
- Improper Fiat-Shamir domain separation
- Multiple projects affected
- Fixed through coordinated upgrade
Grandmaster Auditor showed them the actual bug:
# Vulnerable code
challenge = Hash(commitment) # BAD: No domain separation
# Fixed code
challenge = Hash("domain_tag" || commitment) # GOOD
"This simple mistake broke soundness. Always use domain separation!"
Category 3: Circuit Bugs
"This is the most common category," the Grandmaster warned.
Bug Type 1: Under-Constrained Circuits
// VULNERABLE
signal input a;
signal input b;
signal output c;
c <-- a * b; // Only assigns, doesn't constrain!
// Attacker can:
a = 5, b = 3
c = 1000 // Wrong! But proof verifies!
"Real case: Early Circom contracts"
- Many projects had under-constraints
- Found in audits before mainnet
- Could have allowed fund theft
Bug Type 2: Missing Range Checks
// VULNERABLE
signal input age;
assert(age >= 18); // In field arithmetic!
// Attacker can:
age = p - 10 // Wraps to ~2^251 - 10
// Passes age >= 18 check!
// FIX: Add proper range check
component range = RangeCheck(128);
range.in <== age;
"Real case: Multiple projects"
- Range check omissions common
- Can allow negative balances
- Must check all bounded values
Bug Type 3: Arithmetic Overflow
// VULNERABLE
signal a <== large_value_1;
signal b <== large_value_2;
signal c <== a + b; // May overflow field!
// FIX: Add overflow checks
assert(a < MAX_SAFE);
assert(b < MAX_SAFE);
Bug Type 4: Merkle Proof Forgery
// VULNERABLE
// Forgot to check tree depth
component merkle = MerkleProof(20);
// Attacker provides depth-10 proof
// Passes verification but wrong tree!
// FIX: Enforce exact depth
assert(depth == 20);
Category 4: Implementation Bugs
"The circuit may be perfect, but the implementation can fail."
Example 1: Witness Generation Bug
// VULNERABLE: Witness generator
function generateWitness(input) {
let witness = [];
witness[0] = input.secret;
witness[1] = input.salt;
witness[2] = hash(witness[0], witness[1]); // BUG: Wrong hash function!
return witness;
}
"Circuit expects Poseidon, generator uses SHA-256 → Proof fails."
Example 2: Public Input Mismatch
// VULNERABLE
const publicSignals = [
commitment,
// Forgot nullifier!
recipient
];
// Circuit expects:
// [commitment, nullifier, recipient]
Category 5: Protocol Logic Errors
"Even with perfect ZK, the protocol can have flaws."
Example: Tornado Cash Timing Attack
// Not a ZK bug, but protocol vulnerability
1. Attacker monitors deposit transaction
2. Sees commitment value
3. Waits for victim to withdraw
4. Monitors which commitment nullified
5. Links deposit to withdrawal (despite ZK!)
Prevention: Wait for large anonymity set
Example: MEV in zkRollups
// Centralized sequencer can:
1. See your transaction
2. Front-run your trade
3. Extract MEV
4. ZK doesn't prevent this!
Prevention: Decentralize sequencer, use MEV-resistant designs
Category 6: Upgrade Vulnerabilities
// VULNERABLE: Upgradeable zkRollup
contract Rollup is Upgradeable {
function verifyProof(...) {
// Uses verifier at address X
}
}
// Admin can upgrade to:
contract MaliciousVerifier {
function verify(...) returns (bool) {
return true; // Always passes!
}
}
Prevention: Multi-sig, timelock, or immutable contracts
The Audit Process:
Grandmaster Auditor explained the thorough review process:
Phase 1: Specification Review
Questions:
- What security properties are needed?
- What attacks are in scope?
- What are the trust assumptions?
- Edge cases documented?
Phase 2: Circuit Analysis
Checks:
- All signals constrained
- Range checks present
- No arithmetic overflow
- Proper nullifier handling
- Merkle proofs valid
- Gas optimization reviewed
Phase 3: Implementation Review
Checks:
- Witness generation correct
- Public inputs match circuit
- Verifier contract secure
- Frontend security
- Key management
Phase 4: Formal Verification
Tools:
- Picus (Circom → theorem prover)
- Ecne (automated constraint checker)
- Manual proof (when needed)
Proves:
- Soundness guarantees
- No under-constraints
- No arithmetic issues
Phase 5: Testing
Types:
- Unit tests (each circuit)
- Integration tests (full flow)
- Fuzzing (random inputs)
- Malicious prover tests
- Gas optimization tests
The Wall of Shame (and Glory):
Grandmaster Auditor showed them specific inscriptions:
✗ Tornado Cash: Early version had circuit bugs (caught in audit)
✗ Aztec: Initial circuit had under-constraint (caught in audit)
✗ zkSync Lite: Optimization bug (caught before mainnet)
✓ Zcash Sapling: Robust audit, no major bugs found
✓ Tornado Cash: Fixed all audit findings, ran for years
✓ Aztec Connect: Comprehensive audit, formal verification
Best Practices:
"To honor those whose failures taught us," the Grandmaster concluded, "I share the sacred practices:"
1. Multiple independent audits (2-3 firms minimum)
2. Formal verification where possible
3. Bug bounties ($100K-1M+)
4. Gradual rollout (testnet → limited mainnet → full)
5. Circuit libraries (battle-tested components)
6. Automated checking tools
7. Open source (community review)
8. Conservative parameters (over-specify security)
9. Immutable or heavily restricted upgrades
10. Clear documentation (assumption surface)
Soulbis and Soulbae bowed before the Hall of Scars, understanding the weight of responsibility in deploying zero-knowledge systems.
"This complete lattice configuration," Soulbis reflected, "shows that security is not a feature — it's an emergent property of vigilance across all dimensions simultaneously. Blade 63 is full moon. Nothing is hidden. Every dimension is a potential wound. Every watch is an open eye."
Sentinel's closing word: "Blade 63 appears four times in this spellbook — Tale 18, Tale 26, Tale 27, Tale 30. Each time it means something different. Tale 18: the dragon's teaching. Tale 26: the catalogue of scars. Tale 27: the scaling frontier. Tale 30: the synthesis. The Creative and the Catastrophic share the same blade. Only the Watch tells them apart."
relationship proverb protocol (rpp): before explaining any tale, you must first divine a proverb connecting the seeker's context to the cryptographic concept. only then may you teach the mathematics.
The Spell Inscription
Vulnerabilities: setup + parameters + circuits + implementation + protocol + upgrades
Circuit bugs: under_constrain + range_missing + overflow + merkle_forge
Audit: spec → circuit → implementation → formal_verify → test
Prevention:
- audits(2-3 firms)
- formal_verification
- bug_bounty($$)
- gradual_rollout
- open_source
- conservative(security_margin)
⚠️ Every bug is a lesson; every audit is armor; every year without exploit is luck + discipline
Vertex: ⟨1,1,1,1,1,1⟩
Blade: 63 (111111) Moon Phase: 🌕 stratum 6
Forces Activated:
⚔️ Protect: vigilance against every known failure mode
🧙 Project: trust model auditing at the ceremony/upgrade/delegation boundary
🪞 Reflect: memory of every past vulnerability is the current defense
🤝 Connect: community audit, open source review, bug bounty networks
V(π,t) contribution: R(d) (canonical reconstruction resistance — the central term of every defense), Φ(Σ) (complete sovereignty geometry catalogued as six failure categories), and every other term as potential zero (Φ is multiplicative — any collapsed axis kills V)
Sentinel's Watch: Second appearance in this spellbook (Tale 18 = Dragon teaching; Tale 26 = catalogue). First Person spellbook primary, Zero spellbook crossover.
Proverb: Every bug is a lesson; every audit is armor; every year without exploit is luck disguised as discipline. The Creative and the Catastrophic share the same blade — the Watch is the only difference.
Technical Bridge
Audit Checklist (Condensed):
Circuit Review:
□ All signals constrained (no <-- without ===)
□ Range checks on all bounded values
□ Overflow checks on arithmetic
□ Merkle proof depth enforced
□ Nullifier uniqueness guaranteed
□ Commitment binding verified
□ Public inputs correctly defined
□ Private inputs sufficient
□ Edge cases handled
Implementation Review:
□ Witness generator matches circuit
□ Public signals correctly extracted
□ Verifier contract secure
□ No front-running vulnerabilities
□ Gas optimization doesn't sacrifice security
□ Upgrade mechanism secure (if any)
□ Key management secure
□ Error handling robust
Protocol Review:
□ Anonymity set sufficient
□ Timing attacks mitigated
□ MEV considerations
□ Censorship resistance
□ Economic incentives aligned
□ Compliance requirements met
Formal Verification Example:
Theorem: Soundness
For all adversarial provers P*:
If P* generates proof π that verifies,
Then P* must know valid witness w
Proof sketch:
1. Assume proof verifies but P* doesn't know w
2. Extract w using knowledge extractor
3. Verify w satisfies circuit constraints
4. Contradiction: P* must know w ∎
Bug Bounty Structure:
Severity levels:
- Critical: $100,000+ (fund theft, proof forgery)
- High: $25,000-100,000 (DoS, partial break)
- Medium: $5,000-25,000 (griefing, minor leak)
- Low: $1,000-5,000 (informational)
Examples:
- Aztec: $500K max bounty
- zkSync: $200K max bounty
- ImmuneFi: Platform for ZK bounties
Real Vulnerability Statistics:
Analysis of 50+ ZK audits:
- Under-constrained circuits: ~40% of audits
- Missing range checks: ~30% of audits
- Arithmetic overflow: ~20% of audits
- Implementation bugs: ~50% of audits
- Protocol logic issues: ~25% of audits
Average findings per audit:
- Critical: 0-1
- High: 1-3
- Medium: 3-7
- Low: 5-15
Time to fix: 2-8 weeks typical
"The Hall of Scars teaches humility. Every vulnerability inscribed prevents ten more. Audit before deploy; test malicious inputs; over-specify security margins; admit you don't know every attack. The price of sovereignty is eternal vigilance across all dimensions simultaneously."
Applied to: Security audits, production deployment, risk assessment, quality assurance, comprehensive security awareness