This document outlines the security architecture, threat model, and areas of focus for security auditors reviewing zRonin.

zRonin is a privacy-preserving smart contract system for QRL Zond, using:

• STARK proofs for zero-knowledge privacy
• Dilithium5 signatures for post-quantum authentication
• Poseidon hash for efficient in-circuit hashing
• Merkle trees for commitment tracking

TokenVault (Main Entry Point)
├── StarkVerifier (Proof Verification)
├── MerkleAccumulator (Commitment Tracking)
├── RelayAdapt (Relay Integration)
└── ZronToken (Governance Token)

1. Shield (Deposit):

   • User deposits tokens to TokenVault
   • TokenVault creates commitment (hash of note)
   • MerkleAccumulator inserts commitment
   • User receives encrypted note

2. Transfer (Private):

   • User creates STARK proof of note ownership
   • Proof includes nullifiers (to prevent double-spend)
   • New commitments added for outputs
   • Old nullifiers marked as spent

3. Unshield (Withdraw):

   • User creates STARK proof with withdrawal request
   • TokenVault verifies proof
   • Tokens released to recipient

• Field: Goldilocks prime (2^64 - 2^32 + 1)
• Hash: SHA3-256 for Merkle trees, Poseidon for circuits
• FRI: Folding factor 2, 128-bit security target
• Fiat-Shamir: Transcript-based challenge derivation

• Public Key: 2592 bytes
• Secret Key: 4864 bytes
• Signature: 4595 bytes
• Security: NIST Level 5 (256-bit classical, 128-bit quantum)

• Parameters: t=3, rounds based on security level
• Field: SNARK-friendly prime
• Security: 128-bit collision resistance

1. Double-Spending

   • Threat: Spending same note twice
   • Mitigation: Nullifier tracking on-chain

2. Privacy Leakage

   • Threat: Transaction linkability
   • Mitigation: STARK zero-knowledge proofs

3. Proof Forgery

   • Threat: Creating valid proofs without valid inputs
   • Mitigation: Soundness of STARK system

4. Front-Running

   • Threat: MEV extraction from privacy transactions
   • Mitigation: RelayAdapt integration

5. Key Extraction

   • Threat: Recovering spending keys from public data
   • Mitigation: Dilithium5 post-quantum security

1. Physical side-channel attacks
2. Social engineering
3. Zond network consensus attacks
4. Key management by end users

1. Nullifier Uniqueness: Can two different notes produce the same nullifier?
2. Commitment Binding: Is the commitment scheme binding?
3. Proof Soundness: What is the concrete soundness error of the STARK system?
4. Merkle Security: Are Merkle proofs validated correctly?
5. Gas Griefing: Can users cause excessive gas consumption?
6. Reentrancy: Are there reentrancy vulnerabilities in deposit/withdraw?
7. Integer Overflow: Are arithmetic operations safe?

• Dilithium: 23 tests (key gen, sign/verify, address derivation)
• STARK: 24 tests (field arithmetic, FRI, prover/verifier)
• Merkle: 26 tests (tree operations, proofs)
• Poseidon: 17+ tests (hash operations)
• Notes: 27 tests (encryption, selection)
• Circuits: 23 tests (AIR constraints)

• Contract deployment verification
• Token operations
• Shield/unshield flow simulation

1. Proof Size: STARK proofs are larger than SNARKs (~100KB vs ~200B)
2. Verification Cost: On-chain verification is more expensive
3. Testnet: Not yet deployed to testnet

1. Focus on cryptographic correctness - particularly FRI and Fiat-Shamir
2. Review nullifier derivation - critical for double-spend prevention
3. Analyze gas consumption - look for DoS vectors
4. Check access controls - admin functions, pause mechanisms
5. Verify Poseidon parameters - round numbers, constants

For security-related inquiries during the audit, contact the zRonin team through secure channels.

Document Version: 1.0 Last Updated: 2025-12-14