Security

This page outlines Zylith's security model, trust assumptions, and threat analysis.

Trust Model

Fully Trustless Components

Component	Why Trustless
Smart Contracts	Code is law, verified on-chain
ZK Proofs	Mathematical guarantees
Garaga Verifier	On-chain verification
Poseidon Hash	Cryptographic security

Semi-Trusted Components

Component	Trust Level	What They Can Do	What They Cannot Do
Relay Server	Semi-trusted	Censor transactions, exclude from association set	Steal funds, forge proofs
Browser	User-trusted	Store secrets	Spend without user action

Cryptographic Assumptions

Groth16 Security

Relies on:

• Discrete Logarithm Problem in BN254
• Knowledge of Exponent Assumption
• Trusted Setup integrity (at least one honest participant)

Poseidon Security

• Preimage Resistance: Cannot find input from output
• Collision Resistance: Cannot find two inputs with same output
• Second Preimage Resistance: Given one input, cannot find another with same output

BN254 Curve

• 254-bit security level
• Pairing-friendly for Groth16
• Widely used and analyzed

Threat Analysis

Threat: Double-Spending

Attack: Spend the same commitment twice

Prevention:

• Nullifier hash revealed on spend
• Contract tracks all used nullifiers
• Attempting reuse fails

Threat: Amount Manipulation

Attack: Claim more tokens than deposited

Prevention:

• Amount bound to commitment: H(H(secret, nullifier), amount)
• Different amount = different commitment = not in tree
• Verified solvency via ZK proof

Threat: Proof Forgery

Attack: Create valid proof without knowing secrets

Prevention:

• Groth16 soundness guarantees
• Would require solving discrete log
• Computationally infeasible (2^128 operations)

Threat: Front-Running

Attack: See pending transaction and exploit

Prevention:

• ZK proof hides trade details
• Min amount out bound in proof
• Recipient bound in proof

Threat: Sandwich Attack

Attack: Place orders before and after victim's trade

Prevention:

• Trade amount hidden until execution
• Slippage protection in proof
• Cannot observe pending shielded swaps

Threat: Relay Censorship

Attack: Relay refuses to submit transactions

Prevention:

• Users can run own relay
• Multiple relays can compete
• Direct submission possible (loses some privacy)

Threat: Key Extraction

Attack: Extract secrets from browser

Prevention:

• Secrets encrypted with AES-GCM
• Key derived from wallet signature
• Never stored in plaintext

Threat: Trusted Setup Compromise

Attack: Retain toxic waste to forge proofs

Prevention:

• Using established Hermez ceremony
• 54+ participants
• Only one honest participant needed

Security Properties

Privacy Guarantees

What's Hidden	From Whom
Sender identity	Everyone
Amount	Everyone (until revealed in proof)
Trade intent	Observers (until execution)
LP ownership	Everyone

What's Revealed

Information	When	To Whom
Nullifier hash	On spend	Public
Merkle root	On spend	Public
Trade execution	On-chain	Public
Output commitment	On-chain	Public

Smart Contract Security

Access Control

// No admin functions for user operations
// Only upgradability controls (if applicable)

Reentrancy Protection

// State changes before external calls
// Nullifier marked spent before creating output

Integer Overflow

// Cairo's built-in overflow checks
// Explicit bounds checking on inputs

Flash Loan Resistance

// Commitment must exist in Merkle tree
// Cannot create and use in same transaction

Incident Response

If Vulnerability Found

1. Do not exploit
2. Report to team privately
3. Allow time for fix
4. Coordinate disclosure

If Funds at Risk

1. Pause contract (if pausable)
2. Investigate scope
3. Communicate with users
4. Implement fix
5. Resume operations

Audit Status

Component	Status
Smart Contracts	Under development
ZK Circuits	Under development
Frontend	Under development
Relay Server	Under development

Security Best Practices

For Users

1. Backup secrets before clearing browser data
2. Verify contract addresses before interacting
3. Use secure networks (avoid public WiFi)
4. Keep wallet secure (hardware wallet recommended)

For Developers

1. Review all changes carefully
2. Test on testnet before mainnet
3. Monitor for anomalies after deployment
4. Update dependencies regularly

Bug Bounty

Details to be announced. Expected scope:

• Smart contract vulnerabilities
• ZK circuit soundness issues
• Critical frontend security bugs

Limitations

Known Constraints

Constraint	Impact
Merkle tree capacity	Max ~1M deposits
Proof generation time	15-25 seconds
Browser memory	May fail on low-end devices

Not Protected Against

Threat	Why
User key compromise	Outside protocol scope
Phishing attacks	User security
Malicious wallet	Trust in wallet software