FHE-OTC implements privacy-preserving token swaps using Fully Homomorphic Encryption. This document outlines the security model and potential risks.

• All sensitive data (amounts, prices) is encrypted client-side using TFHE
• Encrypted data remains encrypted on-chain and during computation
• Only data owners with valid permits can decrypt their data

• Users must sign permits to access their encrypted data
• Permits have time-based expiration
• Permits can be restricted to specific contract functions

• Only order makers can cancel their own orders
• Only authorized matchers can trigger order matching
• Settlement requires valid permits from both parties

• All external functions use nonReentrant modifier
• State changes occur before external calls

• Token addresses must be valid (non-zero)
• Token pairs must be different
• Expiry must be within valid range (5 min - 30 days)
• Amounts must be non-zero

• FHE operations have higher gas costs
• Some operations may not complete if gas is insufficient
• Mitigation: Estimate gas generously for FHE operations

• Permits expire after a set time
• Users may need to re-create permits for long operations
• Mitigation: Frontend should handle permit renewal automatically

• Client-side encryption requires secure frontend environment
• Compromised frontend could leak plaintext data
• Mitigation: Open source code, audits, secure deployment

• As with any smart contract, bugs could lead to fund loss
• Mitigation: Comprehensive testing, audits, bug bounties

1. Formal Verification - Verify key invariants (solvency, access control)
2. Fuzz Testing - Extensive fuzzing of order creation and matching
3. Integration Tests - Test full flow with CoFHE coprocessor
4. External Audit - Professional security audit before mainnet

If you discover a security vulnerability, please report it to:

• Email: security@fhe-otc.io
• Telegram: @fhe_otc_security

Please do not publicly disclose vulnerabilities until we have had time to address them.

MIT License - See LICENSE file for details.