This page describes how wallet connection, escrow eligibility, settlement, and disputes are implemented in the CoinExchange.Cash product. Details vary by asset, chain, and live route — verify the in-app state before funding.
General information only, not financial advice; consider your circumstances and seek independent advice.
Step 1
Browse many public pages without signing in. To trade or use account features, connect a supported wallet (for example via WalletConnect-compatible flows) or use email/password sign-in. Wallet sign-in uses a one-time nonce from GET /auth/wallet-nonce and a signature verified server-side; signup, login, wallet-connect, password reset, and related auth routes require Cloudflare Turnstile and Redis-backed rate limits.
Step 2
For eligible 2-of-3 escrow routes, each trading party generates escrow key material in the browser and registers only the public key with POST /escrow/register-key. The API server does not receive or store party private keys for normal trades, loans, or user-to-user flows.
Step 3
P2P trades, P2P loans, CryptoMart orders, and CryptoGigs can attach escrow when the selected cryptocurrency’s chain is marked escrowSupported in platform configuration (derived from engine capability reports, not a static marketing list). Prediction markets use a platform escrow user as counterparty where configured; that party’s key may be generated server-side because the platform is a named counterparty, not because user wallet keys are held.
Step 4
When escrow is active for your route, deposit to the multisig address or contract shown in the trade UI. For Bitcoin, Litecoin, and Dogecoin, native P2WSH-style 2-of-3 engines are implemented in @coinexchange/escrow. EVM token escrow requires a configured Escrow2of3Factory and productionVerified custody approval in code; a factory address alone does not enable advertising or capability flags.
Step 5
Fiat and other off-chain payments happen between users outside blockchain escrow. Confirm payment or delivery using your own checks; chat and uploaded proofs may be used if a dispute is opened.
Step 6
Happy-path release combines signatures from two of the three escrow roles (buyer, seller, platform arbitrator). If parties disagree, either side can open a dispute; an arbitrator may be assigned from the arbitrator pool to review in-platform evidence and choose buyer, seller, or split release. The arbitrator co-signs releases but cannot move funds alone — two of three signatures are still required on supported engines.
CoinExchange.Cash groups several wallet-oriented products: P2P crypto trading, P2P lending, CryptoMart goods auctions, CryptoGigs freelance orders, prediction markets, optional chance/slots experiences, token swap/send flows, and CXCASH-related tools. Each product has its own UI route; escrow, verification, fees, and availability depend on the live configuration for that route.
Escrow is not universal. The API exposes escrowSupported per approved cryptocurrency by calling describeDefaultEscrowCapabilities() / isEscrowCapableChain(). As of the current codebase, native on-chain 2-of-3 creation and release is advertised only for Bitcoin, Litecoin, and Dogecoin without extra deploy flags. Chains such as Monero, Solana, TRON, XRP, Cardano, and Aztec have placeholder or client-side-only engines and are not advertised as escrow-capable. EVM chains stay disabled until a factory is configured and productionVerified is true in engine configuration.
Always confirm escrowSupported, the funded state, and the displayed address in the app before sending funds. Marketing labels or chain lists alone do not prove escrow is active for your trade.
The product is wallet-based: you connect your own wallet for many flows and authorize actions with your keys. Depending on configuration, eligible escrow may lock crypto in a multisig address or contract according to the engine for that chain; the platform does not pool user funds in a single hot wallet for those routes.
Server-side custody does apply to the arbitrator signing key, encrypted payment proofs and dispute evidence storage, session/JWT handling, and any flow where the platform is an explicit counterparty (for example prediction-market escrow user). Third-party on-ramps, identity providers, and wallet apps have their own custody and privacy models.
Disputes are created via the API with structured reason codes (payment not received, fraud suspected, gift-card-specific codes, and others). SLA timestamps (for example 48-hour response and 120-hour decision windows) are informational and do not auto-resolve cases. Arbitrators review timelines, chat, and uploaded evidence; resolution triggers escrow release logic when applicable. Appeals (L2) may require elevated admin roles per disputes.service rules.
Wallet-based browsing does not guarantee reduced verification. Identity, volume, payment-method, risk, and eligibility checks may apply depending on activity and configuration; see the Verification Policy and in-app prompts for the route you use.
For security architecture, arbitrator key storage, deployment evidence, and abuse protections, see the Security page. For vulnerability reporting, see the Security Policy. For market risks, see the Risk Disclosure.
Deeper, product-specific pages for search and onboarding. Each links to the live app route and help articles.
Wallet-based offers and multisig escrow overview.
Trades, CryptoMart, and CryptoGigs escrow model.
Token conversion routes, fees, and slippage.
P2P collateral, liquidation, and loan terms.
Event markets, settlement, and eligibility.
CryptoGigs hiring, delivery, and disputes.
USD bidding and crypto settlement with escrow.
Private send limits and metadata risks.
Goods marketplace with escrow where eligible.
Mint shielded basket stablecoin to your Aztec address.
Fixed-weight FX peg mechanics for CXCASH.
Category comparison table for wallet-based venues.
Product pages for CXCASH pricing, privacy design, buying, and security documentation.
General information only, not financial advice; consider your circumstances and seek independent advice.