Design a P2P Fiat-Crypto Escrow Marketplace

Problem statement

Design a peer-to-peer marketplace where individuals post buy and sell offers for crypto against local fiat, agree on a price, and settle through an escrow that holds the seller's crypto until the buyer's fiat payment is verified. The platform must support offer creation with payment-method details, escrow custody of the seller's crypto, a bounded communication channel for coordinating the transfer, dispute resolution with partial mediation, reputation, multi-currency and multi-rail support, and KYC thresholds that scale with volume.

The defining engineering fact is asymmetric verifiability. The crypto leg settles on a public chain: funding, release, and refund are cryptographically verifiable, globally observable, and eventually final. The fiat leg settles inside bank ledgers and payment rails the platform cannot read: a SEPA Instant transfer settles in under ten seconds 24/7/365 [[55]], a standard SEPA credit transfer can take one to two business days, and a PayPal or card-funded transfer can be reversed weeks later as a chargeback. The platform therefore never observes fiat settlement directly; it observes claims, receipts, rail SLAs, counterparty behavior, and reputation, and it must convert weak off-chain evidence into a safe release decision for strong on-chain value.

Why this is not a generic marketplace

A goods marketplace can refund money after a bad delivery. Here the escrowed asset is bearer value: a wrong release is irreversible. A centralized exchange can net both legs inside one ledger; here the fiat leg leaves the platform's control entirely. The design must therefore treat every trade as a small protocol between strangers with three enforcement points: reserve the crypto in escrow before the fiat window opens, bound every waiting state with timers and evidence rules, and make every release or refund decision reproducible from an append-only event history.

Public operating baseline

Public figures establish that this category runs at real scale. Paxful reported 4.5 million registered wallets and 4.6 billion USD of volume by mid-2020 [[11]], later six million users and five billion dollars of volume [[12]], and a 2025 enforcement resolution described more than 26.7 million facilitated trades [[13]]. Binance P2P advertises 800+ payment methods and 100+ fiat currencies [[18]]. Bisq moved to a 2-of-2 multisig escrow in which mediators and arbitrators hold no keys [[31]]. HodlHodl publishes a 2-of-3 multisig escrow split between buyer, seller, and platform [[37]]. These are cited public claims, not requirements for our fictional system.

The four architectural planes

1. Market plane: offers, price and spread, FX quotes, search and matching, limits and reservation.
2. Custody plane: escrow construction (custodial ledger, multisig, or smart contract), funding verification, release, partial release, refund, fees.
3. Settlement plane: per-asset chain watchers, confirmation and finality policy, reorg handling, fiat payment claims, rail SLAs, chargeback windows.
4. Trust plane: reputation, dispute mediation, compliance tiers, sanctions screening, evidence and audit.

A strong interview answer keeps these planes separate: the market plane may degrade to cached quotes while the custody plane must never double-release, and the trust plane may queue disputes while the settlement plane keeps counting confirmations.

Design assumptions

Unless tied to a citation, every number in this answer is an explicit assumption: 6,000,000 registered traders, 900,000 monthly active, 60,000 concurrent at peak, 250,000 trade attempts per day, a 5x event peak, 45,000 live offers, and 15,000 simultaneous chat sessions.