Security Architecture: What CoinExchange.Cash Users Should Verify
Review CoinExchange.Cash security claims, including route-specific custody, escrow, key handling, funding proof, release, refund, dispute, and operational controls.
CoinExchange.Cash describes product and operational security controls, but their availability and effectiveness depend on the current code, configuration, deployment, keys, providers, route, and custody model. Verify funded escrow and real settlement behavior rather than relying on labels.
Security Architecture Overview
CoinExchange.Cash aims for a security-focused architecture, but controls and fund risks depend on the enabled product, implementation and operational conditions.
Layer 1: Non-Custodial Design
The most important security property to check is where funds are held: some flows are wallet-first, and custody depends on the enabled product and its displayed terms.
- Wallet-first routes: Some flows may not use a platform deposit address before a trade; confirm the selected route's custody and settlement terms
- Trade custody: funds may move according to the enabled product's escrow and settlement design — review the displayed terms
- Settlement: destination and timing depend on the asset, network, trade state and displayed terms
- Wallet and infrastructure risk: depends on the enabled flow — do not assume the absence of platform-controlled infrastructure
Layer 2: Multisig Escrow
Where enabled, a trade may use the displayed escrow design; protection and settlement are not uniform across trades:
How Keys Are Generated
- Buyer key: Generated client-side in the buyer's browser/wallet
- Seller key: Generated client-side in the seller's browser/wallet
- Arbitrator key: Stored in the platform's encrypted HSM
Smart Contract Security
- EVM contract deployment and escrow behaviour depend on the enabled product and current implementation
- A Bitcoin route may use a P2SH escrow script where enabled; verify the actual script, funded state and recovery terms before relying on it
- Timeout, refund and dispute behaviour depend on the network and displayed trade terms; automatic return is not guaranteed
What This Means
- Escrow designs can reduce some single-party risks, but funds remain subject to contract, key, dispute, network and operational risks
- Database compromise may not by itself authorize wallet actions, but security depends on the full implementation and key controls
- Signing requirements depend on the enabled network and custody design; review the relevant technical and trade terms
Layer 3: HSM Key Management
Where an arbitrator key is used, its storage, access controls and dispute powers depend on the enabled product and current implementation:
- Keys are encrypted with AES-256 at rest
- Decryption occurs only during dispute resolution
- Key usage may be audit-logged under the current key-management implementation; review the applicable technical documentation
- Key material is handled according to the current key-management design; review the published technical documentation
Layer 4: Application Security
Authentication
- JWT tokens with short expiration
- Two-factor authentication support
- Rate limiting may apply to supported endpoints; coverage and thresholds depend on the current implementation
- Brute force protection on login attempts
Data Protection
- Passwords hashed with bcrypt
- KYC documents encrypted at rest (for users who opt in to verification)
- Data collection and retention vary by activity, verification, risk controls, jurisdiction and applicable law
Infrastructure
- Hosted on Railway with isolated containers
- PostgreSQL with encrypted connections
- Redis for session management with TTL-based expiry
- Cloudflare for DDoS protection and SSL termination
Layer 5: Operational Security
Access Control
- Role-based access control (User, Moderator, Admin, Super Admin)
- Administrative actions may be audit-logged according to the current implementation and access-control configuration
- Principle of least privilege for all system accounts
Monitoring
- Real-time alerting on suspicious activity
- Automated LTV monitoring for lending positions
- Escrow timeout monitoring for stalled trades
Incident Response
- Documented incident response procedures
- Ability to pause trading if a vulnerability is discovered
- Communication channels for security disclosures
What We Do NOT Have Access To
- Your wallet private keys
- Your trade passwords or 2FA secrets
- Unilateral control of escrowed funds on routes where funded 2-of-3 escrow is in place (verify the escrow state for your trade)
- The ability to reverse completed trades
- Your browsing or trading history on other platforms
Bug Bounty
If you discover a security vulnerability in CoinExchange.Cash, please report it responsibly. We take all security reports seriously and will work with you to address any issues.
Related Guides & Comparisons
Related Articles
Start Trading on CoinExchange.Cash
Non-custodial P2P crypto trading; verification requirements vary. Connect your wallet and start in under a minute.