Bug Bounty and Disclosure Policy

Bug Bounty and Disclosure Policy

SnarkSide is a zero-knowledge, intent-based perpetual DEX designed for anonymity, integrity, and cryptographic correctness. Given the sensitive nature of its architecture—encrypted trade intents, non-interactive liquidations, stealth vaults, and off-chain matchers—security is both foundational and non-negotiable.

This policy defines how we handle vulnerability reports, what classes of issues qualify for bounty rewards, and how researchers can disclose findings responsibly and legally.

1. Philosophy

SnarkSide is adversarial by default. Our systems are built under the assumption that:

  • Attackers will attempt to extract or correlate encrypted trading data.

  • Relayers may behave dishonestly unless cryptographically constrained.

  • State leakage, timing attacks, and MEV vectors are persistent threats.

Our mission is to incentivize external scrutiny, and to align responsible disclosure with public safety and protocol integrity.

2. Scope of Eligible Systems

The following components are within scope for the SnarkSide bug bounty program:

Component
Description

Verifier.sol

On-chain Groth16 verification contract

Vault.sol

Encrypted margin account manager (UTXO logic)

Liquidator.circom

ZK circuit for proving solvency failures

IntentMatch.circom

ZK matching proof between user intents

ProofAggregator.ts

NodeJS service for batching proofs and submitting calldata

EncryptedQueue.ts

Secure message queue for relayer-side intent ingestion

WitnessGenerator.ts

Constraint-based input generator for Circom circuits

VaultMerkle.ts

Merkle tree state tracker for UTXO-based vaults

3. Out-of-Scope Targets

We do not currently offer bounties for:

  • Frontend bugs (UI/UX only issues)

  • Non-exploitable gas inefficiencies

  • Issues with third-party ZK libraries (e.g., SnarkJS, Circom itself)

  • Social engineering vulnerabilities

  • Rate limits or DoS against relayer APIs without privacy compromise

4. Examples of Critical Bugs (High Bounty Eligible)

  • Proof Soundness Violations: A user can submit a valid-looking proof that settles or liquidates incorrectly.

  • Vault State Corruption: Exploiting nullifier reuse or Merkle index collision to double-spend.

  • Stealth Leak: Deriving user identity, vault state, or trade directionality from decrypted data or side-channels.

  • Malicious Relayer Bypass: Spoofing batch proofs or tricking the verifier contract into accepting invalid calldata.

  • Liquidation Circumvention: Falsifying oracle price commitments or funding data to block or force liquidation.

  • Intent Replay: Successfully replaying an old encrypted intent to trigger settlement.

5. Submission Guidelines

Please follow these steps to submit a bug:

  1. Email your report to [email protected] using your public PGP key.

  2. Include:

    • Full description of the vulnerability

    • Steps to reproduce the issue

    • A proof-of-concept (PoC) exploit, ideally with local testnet code

    • Your recommended fix or analysis of the root cause

  3. Encrypt all sensitive information.

6. Bounty Rewards

Rewards are evaluated based on:

  • Impact: exploitability, user loss potential, chain impact

  • Quality: depth of analysis, clarity of report

  • Severity: from informational to critical

Severity
Reward Range (USD)

Critical

$25,000 – $250,000

High

$10,000 – $25,000

Medium

$1,000 – $10,000

Low

$500 – $1,000

Informational

Discretionary

All bounties are paid in stablecoins or $SNSD tokens (once launched). We reserve the right to modify reward amounts based on circumstances.

7. Legal Safe Harbor

We support ethical security research. As such:

  • We will not pursue legal action against researchers who adhere to this policy.

  • Do not exploit vulnerabilities beyond proof-of-concept.

  • Do not attempt to access other users' accounts or data.

  • Do not publicly disclose the vulnerability before we fix it.

8. Fix Window & Credit

  • You will be notified of fix timelines.

  • Patches are published with clear changelogs.

  • With your consent, you will be credited in the SECURITY.md, GitHub advisory, and any formal disclosure.

9. Reporting Channels

  • Primary: [email protected] (PGP-encrypted preferred)

  • Backup: Discord security channel (/security)

  • PGP Fingerprint (available on request)

10. Closing Notes

We believe that zero-knowledge protocols demand zero-trust thinking.

That means we treat every verifier, every relayer, and every encrypted message as a potential threat surface.

If you can break our proofs, prove it—then let us prove to the world we fixed it.

Thank you for making SnarkSide safer.

PreviousRunning a Relayer NodeNextData Schemas

Last updated