Bug Bounty Program

ZKMix operates a bug bounty program to incentivize the responsible disclosure of security vulnerabilities. We believe that the security research community plays a vital role in keeping the protocol safe, and we reward researchers who help us identify and fix issues before they can be exploited.

Scope

The bug bounty program covers the following components of the ZKMix protocol:

In Scope

Smart Contracts (Critical Priority)

• Mixer Program (Rust/Anchor) -- deposit, withdrawal, and administrative logic
• Verifier Program (Rust/Anchor) -- Groth16 proof verification and verification key management
• All deployed on-chain accounts and PDAs
• Cross-program invocation (CPI) logic between programs

Zero-Knowledge Circuits (Critical Priority)

• Withdrawal circuit (circom) -- constraint system, signal assignments, public input binding
• Poseidon hash implementation
• Merkle tree membership proof circuit
• Proving and verification key integrity

Relayer Server (High Priority)

• HTTP API endpoints and request handling
• Transaction construction and submission logic
• Rate limiting and denial-of-service protections
• Input validation and sanitization

SDK (Medium Priority)

• Proof generation pipeline
• Commitment and nullifier generation
• Note serialization and deserialization
• Cryptographic operations (hashing, key derivation)
• Merkle tree reconstruction logic

Frontend Application (Lower Priority)

• Cross-site scripting (XSS) that could leak deposit notes
• Dependency vulnerabilities that could compromise proof generation
• Content injection that could redirect funds

Smart Contract Vulnerabilities of Interest

The following categories of smart contract vulnerabilities are of particular interest:

• Fund theft -- Any mechanism to withdraw funds without a valid deposit or to drain the vault
• Double-spending -- Circumventing the nullifier check to withdraw the same deposit multiple times
• Proof forgery -- Creating valid proofs without knowing the corresponding secret and nullifier
• Merkle tree corruption -- Manipulating the tree state to invalidate existing deposits or create phantom deposits
• Privilege escalation -- Gaining unauthorized access to administrative functions
• Denial of service -- Preventing legitimate deposits or withdrawals from being processed
• Economic exploits -- Manipulating fees, pool state, or relayer economics for profit

Reward Tiers

Rewards are determined based on the severity of the vulnerability and the quality of the report. Severity is assessed using a framework that considers the impact on user funds, protocol availability, and privacy guarantees.

Severity Classification

Reward Amounts

Rewards within each range are determined based on:

• Exploitability -- How easy is it to exploit the vulnerability? Does it require specific conditions?
• Impact scope -- How many users are affected? Is the impact permanent or temporary?
• Report quality -- Does the report include a clear description, proof of concept, and suggested fix?
• Novelty -- Is this a known class of vulnerability, or a novel attack vector?

Exceptional reports that identify critical vulnerabilities with clear, working proof-of-concept exploits may receive rewards above the stated maximums at the team's discretion.

Responsible Disclosure Process

We ask that all vulnerability reports follow this responsible disclosure process:

Step 1: Identify the Vulnerability

Verify that the vulnerability is real and reproducible. If possible, create a minimal proof of concept that demonstrates the issue without causing harm to mainnet users or funds.

Step 2: Report the Vulnerability

Submit your report through one of these channels:

• Email: security@zkmix.dev (PGP key available at https://zkmix.dev/.well-known/security-pgp.asc)
• Bug bounty platform: https://immunefi.com/bounty/zkmix (preferred for tracking and payment)

Step 3: Include Required Information

Your report should include:

1. Summary -- A brief description of the vulnerability.
2. Severity assessment -- Your assessment of the impact and severity.
3. Affected component -- Which program, contract, circuit, or code is affected.
4. Reproduction steps -- Detailed steps to reproduce the vulnerability.
5. Proof of concept -- Code, scripts, or transactions that demonstrate the issue. For smart contract vulnerabilities, a test case using the Anchor testing framework is ideal.
6. Impact analysis -- What an attacker could achieve by exploiting this vulnerability.
7. Suggested fix -- If you have ideas for how to fix the issue, include them.

Step 4: Response Timeline

For critical vulnerabilities that pose an immediate risk to user funds, the team will initiate emergency response procedures, which may include pausing affected pools while a fix is developed.

Step 5: Coordinated Disclosure

After the vulnerability is fixed and deployed, the researcher and the ZKMix team will coordinate a public disclosure. The researcher is credited (by name or pseudonym, their choice) in the disclosure report and any related communications.

We ask that researchers refrain from public disclosure until the fix is deployed and users have had reasonable time to update. The standard disclosure window is 30 days after the fix is deployed on mainnet.

Out of Scope

The following are explicitly out of scope for the bug bounty program:

Not Eligible

• Issues already known -- Vulnerabilities documented in existing audit reports or this threat model page.
• Theoretical attacks without proof of concept -- Claims of vulnerability without demonstration.
• Social engineering -- Phishing, pretexting, or other social engineering attacks against team members or users.
• Physical attacks -- Attacks requiring physical access to servers or hardware.
• Third-party service vulnerabilities -- Issues in Solana itself, RPC providers, wallet software, or other external dependencies (though we appreciate being notified so we can coordinate with the upstream maintainers).
• Self-XSS -- Cross-site scripting that requires the victim to paste code into their own browser console.
• Rate limiting issues on public endpoints -- Unless they can be used to cause significant harm.
• Missing best practices without security impact -- Missing HTTP headers, suboptimal configurations, etc., unless they directly enable an attack.
• Spam or abuse of the relayer API -- Unless it can cause fund loss or permanent denial of service.
• Issues only exploitable on devnet -- Devnet is a testing environment; only mainnet vulnerabilities are eligible. However, if a devnet finding also applies to mainnet, it is eligible.

Conditional Eligibility

• Privacy leaks -- Information leaks that reduce the effective anonymity set are eligible if they are caused by a bug in ZKMix code. Privacy limitations inherent to the design (documented in the Threat Model) are not eligible.
• Front-end vulnerabilities -- Only eligible if they can directly lead to fund loss (e.g., XSS that exfiltrates deposit notes) or material privacy harm.

How to Submit

Via Email

Encrypt your report using our PGP key and send it to security@zkmix.dev:

# Download the PGP key
curl -o zkmix-security.asc https://zkmix.dev/.well-known/security-pgp.asc

# Import the key
gpg --import zkmix-security.asc

# Encrypt your report
gpg --encrypt --recipient security@zkmix.dev report.md

# Send report.md.gpg to security@zkmix.dev

Via Immunefi

For the most streamlined experience, submit through our Immunefi bounty page at https://immunefi.com/bounty/zkmix. Immunefi handles secure communication, payment processing, and dispute resolution.

Via GitHub Security Advisory

For lower-severity issues, you can create a private security advisory on the ZKMix GitHub repository:

1. Go to https://github.com/zkmix/zkmix-protocol/security/advisories
2. Click "New draft security advisory"
3. Fill in the details and submit

Safe Harbor

ZKMix provides safe harbor for security researchers who:

• Act in good faith to identify and report vulnerabilities
• Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue
• Do not access, modify, or delete data belonging to other users
• Do not perform denial-of-service attacks against production systems
• Do not publicly disclose the vulnerability before the coordinated disclosure window

Researchers who follow these guidelines will not face legal action from the ZKMix team, regardless of the nature of the vulnerability discovered.

Contact

For any questions about the bug bounty program, scope, or eligibility, contact:

• Email: security@zkmix.dev
• Discord: #security channel in the ZKMix Discord server
• Immunefi: Message through the Immunefi platform