> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/p2pdotme/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Model
> Threat model, adversaries, and security mitigations
## Assumptions & Adversaries
### Network Assumptions
**Core Infrastructure Assumptions:**
* **Network liveness on Base** (Solana planned): Assumes Base L2 remains operational with reasonable finality times
* **Oracle availability**: Pricing oracles remain accessible with acceptable latency
* **Honest-majority not required** for fiat rails: Protocol security doesn't depend on honest majority assumptions for off-chain payment rails
The protocol is designed to function under realistic adversarial conditions without requiring overly optimistic trust assumptions.
### Adversary Types
The protocol anticipates and mitigates various adversarial actors:
Users who make legitimate-appearing payments via reversible rails, then initiate chargebacks after receiving crypto.
**Mitigation:** Rail risk classification, extended dispute windows, higher bonds for risky rails
Attackers attempting to forge ZK-KYC proofs or fabricate payment evidence.
**Mitigation:** Cryptographic verification, multiple verifier types, on-chain attestation validation
Adversaries seeking to manipulate price feeds for profitable trades.
**Mitigation:** Multi-source aggregation, median calculation, deviation guards, circuit breakers
Malicious actors filing false disputes or disrupting protocol operations.
**Mitigation:** Dispute bonds, reputation penalties, escalating sanctions, eventual bans
Adversaries creating multiple identities to game reputation or exploit limits.
**Mitigation:** ZK-KYC uniqueness checks, diminishing returns, pattern detection, device fingerprinting
Groups of merchants coordinating to manipulate markets or extract rents.
**Mitigation:** Protocol-level pricing, transparent matching, merchant concentration limits
## Mitigations
### On-Chain Security Measures
**Mechanism:**
* Users and merchants post bonds before trades
* Bonds locked during order lifecycle
* Slashed for fraudulent behavior or failures
* Returned on successful completion
**Implementation:**
* Bond amounts scale with order size and reputation
* Multi-tier slashing based on violation severity
* Automated slashing via smart contract logic
* Appeal mechanism for disputed slashing
**Security Properties:**
* Economic disincentive for fraud
* Compensation pool for victims
* Skin-in-the-game alignment
**Mechanism:**
* Different payment rails assigned risk classes
* Time windows adjusted based on risk
* Higher-risk rails require longer settlement and dispute periods
**Examples:**
* UPI (low-risk): 1-hour dispute window
* SEPA (medium-risk): 6-hour dispute window
* Credit card (high-risk): 48-hour dispute window
**Security Properties:**
* Time for chargeback detection
* Appropriate risk-adjusted protection
* Flexible response to rail characteristics
**Mechanism:**
* All ZK proofs verified on-chain or by trusted verifiers
* Multiple verification methods required for higher limits
* Proof freshness requirements prevent replay
* Verifier diversity prevents single-point compromise
**Implementation:**
* On-chain verifier registry
* Proof expiry timestamps
* Nonce-based replay protection
* Verifier rotation and sunsetting
**Security Properties:**
* Cryptographic identity assurance
* Resistance to forgery
* Defense in depth through multiple verifiers
**Mechanism:**
* Continuous monitoring of price source deviations
* Automatic rejection of outlier sources
* Circuit breakers trigger on excessive deviation
* TWAP smoothing prevents flash manipulation
**Parameters:**
* Normal operation: ±2% deviation allowed
* Warning level: 3.5% deviation
* Circuit breaker: 5% deviation
* Recovery requires governance approval
**Security Properties:**
* Protection against price manipulation
* Graceful degradation under attack
* User protection during market anomalies
**Mechanism:**
* Per-user transaction limits based on reputation
* Velocity limits prevent rapid fund movement
* Cooldown periods between large transactions
* Suspicious pattern detection triggers reviews
**Enforcement:**
* Smart contract enforcement
* Real-time monitoring
* Automatic temporary restrictions
* Manual review for pattern violations
**Security Properties:**
* AML compliance through design
* Fraud limitation
* Sybil resistance
* Time for anomaly detection
## Audits & Bounty
**Security Assurance Programs:**
Core contracts, verifiers, and circuits will undergo independent audits; a public bounty program will operate pre- and post-TGE.
### Audit Strategy
**Pre-Launch Audits:**
* Multiple independent audit firms
* Smart contract security specialists
* Cryptographic circuit review
* Economic mechanism analysis
**Audit Scope:**
* Base L2 contracts (order lifecycle, matching, settlement)
* Reputation registry and scoring logic
* Oracle adapters and price aggregation
* ZK-KYC verifier integrations
* Governance and upgrade mechanisms
**Continuous Audits:**
* Re-audit after major upgrades
* Periodic security reviews
* Incident response retainer with audit firms
### Bug Bounty Program
**Bounty Structure:**
**Critical (Protocol-Breaking):**
* Fund theft or loss
* Oracle manipulation enabling profit
* Reputation system bypass
* **Reward:** $100,000 - $500,000
**High (Significant Impact):**
* Fraud mechanism not caught by safeguards
* Privacy leak of PII
* Dispute resolution bypass
* **Reward:** $25,000 - $100,000
**Medium (Moderate Impact):**
* Gas optimization exploits
* Front-running vulnerabilities
* Denial of service vectors
* **Reward:** $5,000 - $25,000
**Low (Minor Impact):**
* UI/UX exploits
* Information disclosure (non-PII)
* Edge case handling issues
* **Reward:** $1,000 - $5,000
### Responsible Disclosure
**Process:**
1. Report via secure channel ([security@p2p.me](mailto:security@p2p.me))
2. Acknowledgment within 24 hours
3. Initial assessment within 72 hours
4. Fix development and deployment
5. Public disclosure (coordinated timing)
6. Bounty payment
**Commitments:**
* No legal action against good-faith researchers
* Prompt response and resolution
* Public credit (unless anonymity requested)
* Fair bounty assessment by independent panel
## Attack Scenarios & Responses
### Scenario 1: Oracle Manipulation
**Attacker's Goal:** Manipulate price feeds to execute trades at unfavorable rates.
**Method:**
1. Compromise or manipulate a subset of oracle sources
2. Create artificial price spike or crash
3. Execute large orders at manipulated price
4. Profit from price difference
1. **Multi-source aggregation:** Requires compromising majority of sources
2. **Median calculation:** Resistant to outlier manipulation
3. **Deviation monitoring:** Triggers circuit breaker at 5% deviation
4. **TWAP smoothing:** Prevents flash manipulation
5. **Quote expiry:** Limits exposure window to 60 seconds
6. **Post-trade monitoring:** Suspicious trades reviewed
* Automatic circuit breaker halts trading
* Compromised sources identified and removed
* Affected trades reviewed for reversal
* Oracle provider notified and replaced if necessary
* Post-mortem published and safeguards updated
### Scenario 2: Reputation Farming
**Attacker's Goal:** Artificially inflate reputation to access higher limits, then commit fraud.
**Method:**
1. Create multiple accounts or use legitimate account
2. Execute many small legitimate trades
3. Build reputation over time
4. Once limits are high, commit large-scale fraud
5. Disappear with funds
1. **Reputation decay:** Requires continuous activity
2. **Diminishing returns:** Later trades earn less reputation
3. **Rail diversity requirement:** Can't farm single method
4. **Bond scaling:** Higher limits require more capital at risk
5. **Pattern detection:** Wash trading and artificial activity flagged
6. **Sybil resistance:** ZK-KYC uniqueness prevents multiple accounts
* Suspicious accounts flagged for enhanced monitoring
* Large withdrawals from newly-high-reputation accounts delayed
* Fraud detected and prevented before completion
* Bonds slashed and reputation destroyed
* Pattern analysis updated to catch similar attempts
### Scenario 3: Smart Contract Exploit
**Attacker's Goal:** Exploit contract vulnerability to steal funds or disrupt operations.
**Method:**
1. Discover vulnerability in smart contract logic
2. Craft exploit transaction
3. Execute to steal funds or break protocol state
1. **Pre-deployment audits:** Professional security review
2. **Formal verification:** Mathematical proof of key properties
3. **Bug bounty:** Incentivize discovery before exploitation
4. **Upgrade controls:** Timelocked upgrades with review period
5. **Emergency pause:** Admin can pause contracts if exploit detected
6. **Limited scope:** Modular design limits blast radius
* Emergency pause activated immediately
* Vulnerability analyzed and patch developed
* Audit firm engaged for emergency review
* Fix deployed through expedited governance
* Affected users compensated from insurance pool
* Public post-mortem and prevention measures
## Security Roadmap
### Near-Term (0-6 months)
* Complete comprehensive smart contract audit
* Launch public bug bounty program
* Implement automated monitoring and alerting
* Deploy circuit breaker testing regime
* Establish incident response procedures
### Medium-Term (6-12 months)
* Formal verification of critical contract components
* Decentralized oracle infrastructure
* Insurance pool for user protection
* Advanced fraud detection ML models
* Security operations center (SOC) establishment
### Long-Term (12+ months)
* Fully decentralized security governance
* Autonomous threat response systems
* Zero-knowledge proof of solvency
* Quantum-resistant cryptography migration plan
* Cross-chain security coordination
Security is an ongoing process, not a destination. The protocol commits to continuous improvement, transparent communication about risks, and rapid response to emerging threats.