Security

This document outlines Paraloom's security model, assumptions, and best practices.

Security Model

Cryptographic Assumptions

Paraloom's security relies on:

Assumption	Description
Poseidon Hash	Collision-resistant (128-bit security)
Groth16 zkSNARK	Sound under q-SDH assumption
BLS12-381 Curve	Discrete log hardness (128-bit)
Trusted Setup	Ceremony performed correctly

Byzantine Fault Tolerance

Parameter	Value
Threshold	7/10 (70%)
Max Malicious	3/10 validators
Reputation System	Reduces unreliable validators

Threat Model

Attacks Prevented

Double Spending

Nullifier tracking prevents spending the same note twice.

Inflation

zkSNARK proofs ensure valid amount transitions.

Transaction Linking

Zero-knowledge proofs hide sender, recipient, and amounts.

Malicious Validators

7/10 consensus threshold tolerates 3 malicious validators.

Attacks NOT Fully Prevented

These attacks require additional mitigation at the application level.

Attack	Description	Mitigation
Timing Analysis	Transaction timing may leak information	Use random delays
Amount Analysis	Unique amounts can be traced	Use standard denominations
Network Analysis	IP addresses may be observed	Use Tor/VPN
Front-running	Transactions may be observed in mempool	Use commit-reveal

Privacy Guarantees

What is Hidden

Transaction amounts (except at deposit/withdrawal)
Sender identity
Recipient identity
Transaction graph connections

What is Visible

Deposit events (amount visible)
Withdrawal events (amount visible)
Nullifiers (unlinkable to deposits)
Merkle root updates

Trusted Setup

Current Status: TESTNET ONLY

The current trusted setup is centralized and NOT suitable for production.

Production Requirements

For mainnet deployment:

Multi-Party Computation Ceremony
- 50+ independent participants
- Geographically distributed
- Verifiable participation
Security Guarantees
- Only 1 honest participant needed
- Public verification of ceremony
- Toxic waste destruction proof

Ceremony Process

Participant 1 → Compute → Pass to Participant 2
Participant 2 → Compute → Pass to Participant 3
...
Participant N → Finalize → Publish Keys

Code Security

Audit Status

Component	Status
Privacy Layer	Internal review
Consensus	Internal review
Bridge	Internal review
Solana Program	Internal review

External security audit planned before mainnet launch.

Known Limitations

No Formal Verification
- Circuits not formally verified
- Rust code not formally verified
Limited Testing
- 197 tests, but not exhaustive
- Fuzz testing not complete
Single Implementation
- No alternative implementations to compare

Validator Security

Secure Key Management

# Generate validator keys securely
paraloom-node keygen \
  --output ./validator-key.json \
  --entropy-source /dev/random

# Set restrictive permissions
chmod 600 ./validator-key.json

# Backup securely (offline)
cp ./validator-key.json /secure/backup/

Network Security

# Firewall configuration
ufw allow 9000/tcp  # P2P
ufw deny 9090/tcp   # Metrics (internal only)

# Rate limiting
iptables -A INPUT -p tcp --dport 9000 \
  -m connlimit --connlimit-above 50 -j REJECT

Monitoring

Monitor for:

Unusual verification patterns
Consensus participation drops
Reputation score changes
Memory/CPU spikes

User Security

Wallet Security

Use hardware wallets for large amounts
Never share private keys or seeds
Verify addresses before sending
Test with small amounts first

Note Security

Shielded notes contain:

Commitment
Amount
Randomness
Secret

If you lose your notes, you lose access to your funds!

Backup strategy:

# Encrypt notes before backup
gpg --symmetric --cipher-algo AES256 notes.json

# Store in multiple locations
cp notes.json.gpg /backup1/
cp notes.json.gpg /backup2/

Privacy Best Practices

Use Unique Addresses
- Different deposit address each time
- Different withdrawal address each time
Avoid Unique Amounts
- Use standard denominations (1, 10, 100 SOL)
- Split large amounts into smaller transactions
Timing Obfuscation
- Wait random intervals between operations
- Don't deposit and withdraw same amount quickly
Network Privacy
- Use Tor for transaction submission
- Use VPN as additional layer